Kubernetes 1.24 以降では、Docker が組み込みコンテナランタイムとしてサポートされなくなりました。Dockershim コンポーネントもバージョン 1.24 で削除されました。これは、kubelet が Docker と対話してコンテナを作成および管理できないことを意味します。このため、Alibaba Cloud Container Service for Kubernetes (ACK) は、バージョン 1.24 以降、コンテナランタイムとして Docker をサポートしていません。ACK クラスターをバージョン 1.24 以降にアップグレードするには、ノードコンテナランタイムを Docker から containerd に移行する必要があります。
Containerd は、Kubernetes によってサポートされている業界標準のコンテナランタイムです。Docker ランタイムと比較して、containerd は起動が速く、使用するリソースが少なく、より安全です。
Docker から containerd への移行とアップグレード計画
アップグレードする前に、ワークロードがノード上でイメージをビルドするために Docker に依存していないことを確認してください。ほとんどの場合、ワークロードはコンテナランタイムに依存しません。Docker のバックエンドも containerd を呼び出します。したがって、移行後にワークロードが影響を受けることはありません。
まず、ステージング環境を移行してください。次に、閑散期に本番環境を移行してください。
ノードコンテナランタイムを Docker から containerd に移行するには、次のいずれかの方法を使用します。
オプション 1: 既存のノードプールのアップグレード (推奨)
[Kubelet の更新] 機能を使用して、[ノードプール] ページから Docker から containerd への移行を行います。この方法では、ノードのシステムディスクが自動的に置き換えられます。システムディスクに重要データを保存しないでください。または、事前にデータをバックアップしてください。アップグレード中はデータディスクには影響ありません。
Container Service 管理コンソールにログインします。Container Service 管理コンソール 。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、クラスターの名前をクリックします。左側のナビゲーションウィンドウで、 をクリックします。
-
対象のノードプールの アクション 列で、
> Kubelet の更新 を選択します。 -
ランタイムのアップグレードに関する情報を確認し、事前チェック をクリックします。事前チェックが正常に完了したら、画面上の指示に従ってランタイムのアップグレードを完了します。
注意事項とパラメーター構成の詳細については、「ノードプールのアップグレード」をご参照ください。
オプション 2: ローテーション移行用の新しい containerd ノードプールの作成（オプション）
ノードプールを作成し、ランタイムを containerd に設定します。次に、ノードをスケールアウトします。古いノードプールをノードの隔離状態にするか、ラベルなどの方法を使用してアプリケーションワークロードを更新し、新しいノードプールにスケジュールします。すべてのアプリケーションを新しいノードプールに徐々に移行します。その後、古いノードプールを廃止します。
ノードプールの作成方法の詳細については、「ノードプールの作成と管理」をご参照ください。ノードをスケジュール不可に設定する方法の詳細については、「ノードのドレインとスケジュール可能性の管理」をご参照ください。
移行後の考慮事項
-
移行後も Dockerfile の主要な構文は変更されません。ただし、ランタイム環境に関連する構成に注意してください。これには、ベースイメージの互換性、環境変数設定、およびランタイムコマンド定義が含まれます。これにより、containerd 環境でイメージをスムーズにビルドおよび実行できます。
-
containerd には組み込みのイメージビルド機能がないため、アップグレード後にクラスターノードで Docker Build を使用することはできません。ただし、イメージのプルは影響を受けません。
-
コンテナランタイムを containerd に移行した後、Docker はコンテナライフサイクルを管理しなくなります。したがって、ノードで Docker コマンドまたは Docker API を使用してコンテナステータスを表示したり、コンテナと対話したりすることはできません。ただし、Docker コマンドの代わりに containerd コマンドを使用できます。containerd コマンドと Docker コマンドのマッピングの詳細については、「containerd、サンドボックスコンテナ、および Docker ランタイムの比較」をご参照ください。
ディスク交換アップグレードの仕組み
ACK は、Docker から containerd に移行するためにディスク交換アップグレードを自動的に実行します。プロセスは次のとおりです。
-
ノードをドレインし、スケジュール不可に設定します。
-
ECS インスタンスをシャットダウンしてノードを停止します。
-
システムディスクを交換します。システムディスク ID は変更されますが、ディスクタイプ、インスタンス IP アドレス、および Elastic Network Interface (ENI) MAC アドレスは変更されません。
-
ノードを再初期化し、containerd ランタイムをインストールします。
-
ノードを再起動します。ノードの準備ができたら、スケジュール可能に設定します。
よくある質問
各バッチアップグレードにはどのくらいの時間がかかりますか?
ノードプールアップグレードページから Docker から containerd に移行する場合、ディスク交換アップグレードが使用されます。スナップショットが作成されない場合、アップグレードは通常 8 分未満で完了します。アップグレード中にスナップショットを作成することを選択した場合、アップグレードはスナップショットの作成後に開始されます。実行時間はスナップショットの作成にかかる時間によって異なります。ノードプールアップグレードでは、スナップショット作成に 40 分が許可されます。スナップショットが 40 分以内に作成されない場合、ノードアップグレードはタイムアウトし、失敗します。アップグレード操作は失敗したノードでは開始されません。システムディスクにビジネスデータを保存しない場合、長いアップグレード時間を避けるためにスナップショットを作成しないことを選択できます。
各バッチでアップグレードされるノード数は 1、2、4、8 などで、同時アップグレードの最大数に達するまで続きます。最大数に達した後、その後の各バッチでその数のノードがアップグレードされます。たとえば、バッチあたりの最大ノード数を 4 に設定した場合、最初のバッチでは 1 つのノードがアップグレードされ、2 番目のバッチでは 2 つのノードがアップグレードされ、3 番目のバッチでは 4 つのノードがアップグレードされます。その後のすべてのバッチでは 4 つのノードがアップグレードされます。
アップグレード中にサービスは影響を受けますか?
ノードプールアップグレードページから Docker から containerd に移行する場合、ディスク交換アップグレードが使用されます。アップグレード中、ノードはドレインされます。Pod がグレースフルシャットダウンロジック (Kubernetes におけるグレースフルシャットダウンとゼロダウンタイムデプロイメント) を実装しており、異なるノードに複数のレプリカがデプロイされている場合、サービスは影響を受けません。同じアプリケーションの複数のレプリカが同じバッチでアップグレードされるのを防ぐには、同時アップグレード数を Pod レプリカ数よりも少なく手動で設定できます。
Docker から containerd に移行した後、ロールバックできますか?
ロールバックはサポートされていません。
Docker から containerd への移行中にノードデータは失われますか?
ノードプールアップグレードページから Docker から containerd に移行する場合、ディスク交換アップグレードが使用されます。この方法では、ノードのシステムディスクが交換されます。重要なデータをシステムディスクに保存しないでください。または、事前にデータをバックアップしてください。データディスクはアップグレード中に影響を受けません。
ノードのシステムディスクが交換された後、ノードの IP アドレスは変更されますか?
システムディスクが交換されると、システムディスク ID は変更されます。ただし、ディスクタイプ、インスタンス IP アドレス、および ENI MAC アドレスは変更されません。詳細については、「インスタンスのシステムディスクの交換 (OS の変更)」をご参照ください。
containerd は Docker とどの程度互換性がありますか?
ほとんどの場合、ワークロードはコンテナランタイムに依存しません。Docker のバックエンドも containerd を呼び出します。したがって、移行後にワークロードが影響を受けることはありません。
containerd には組み込みのイメージビルド機能がないため、アップグレード後にクラスターノードで Docker Build を使用することはできません。ただし、イメージのプルは影響を受けません。
コンテナランタイムを containerd に移行した後、Docker はコンテナライフサイクルを管理しなくなります。したがって、ノードで Docker コマンドまたは Docker API を使用してコンテナステータスを表示したり、コンテナと対話したりすることはできません。
以前に Docker を使用してクラスターノードでイメージをビルドしていて、ランタイムを containerd にアップグレードした場合はどうすればよいですか?
Alibaba Cloud Container Registry (ACR) を使用してイメージをビルドするか、手動でイメージをビルドできます。
-
ACR を使用してビルド (推奨): ACR イメージビルドは、Docker の公式イメージビルドツールである BuildKit に基づいています。ACR インスタンスを作成し、Dockerfile に基づいてビルドルールを構成することで、イメージビルドを自動的にトリガーできます。その後、Dockerfile が実行されてビルドが実行されます。ビルドが完了した後、イメージは自動的にイメージリポジトリにコミットされます。詳細については、「Enterprise Edition インスタンスを使用したイメージのビルド」をご参照ください。
-
手動でビルド: 最適なノードパフォーマンスを確保するために、別の Elastic Compute Service (ECS) インスタンスを作成します。インスタンスに Docker を手動でインストールし、その後 Docker コマンドを使用してイメージをビルドします。詳細については、「Docker および Docker Compose のインストールと使用」をご参照ください。
ノードランタイムが Docker から containerd に切り替わった後、Docker ディレクトリがクリーンアップされず、ディスク領域を占有している場合はどうすればよいですか?
Kubernetes クラスターによって管理されるコンテナ、イメージ、およびログファイルに加えて、Docker ディレクトリには自分で作成したファイルパスも含まれています。不要な場合は、ランタイム切り替え後にデータディスク内の Docker ディレクトリを手動で削除してください。