Kubernetes 1.24 は、Docker を組み込みコンテナーランタイムとしてサポートしなくなりました。Dockershim コンポーネントも Kubernetes 1.24 で非推奨になりました。そのため、kubelet を使用して Docker と対話してコンテナーを作成または管理することはできなくなりました。この更新により、Kubernetes 1.24 以降を実行する ACK クラスタは、Docker を組み込みコンテナーランタイムとしてサポートしなくなりました。ACK クラスタの Kubernetes バージョンを 1.24 以降に更新するには、コンテナーランタイムを Docker から containerd にアップグレードする必要があります。
containerd は、Kubernetes でサポートされている標準のコンテナーランタイムです。起動速度、リソース節約、セキュリティの面で Docker を上回っています。
Docker から containerd へのアップグレードのソリューション
開始する前に、ワークロードが Docker に依存してコンテナーイメージをビルドしていないことを確認してください。ほとんどの場合、Kubernetes ワークロードはコンテナーランタイムに依存しておらず、Docker バックエンドは依然として containerd です。そのため、containerd にアップグレードした後も、ワークロードは通常どおり実行を継続できます。
アップグレードを開始する前に環境をテストし、この操作はオフピーク時に実行することをお勧めします。
次のソリューションを使用して、Docker から containerd にアップグレードできます。
ソリューション 1：Docker を使用するノードプールをアップグレードする（推奨）
ACK コンソールの [ノードプール] ページで [Kubelet の更新] をクリックして、Docker から containerd にアップグレードできます。このソリューションは、ノードプールのノードのシステムディスクを自動的に置き換えます。重要なデータをシステムディスクに保存したり、事前にシステムディスクをバックアップしたりしないでください。データディスクはアップグレードの影響を受けません。
ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスタ] をクリックします。
[クラスタ] ページで、管理するクラスタを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[ノードプール] ページで、ターゲットノードプールを見つけ、
Kubelet 更新[アクション] 列で > を選択します。更新の構成を確認し、[事前チェック] をクリックします。ノードプールが事前チェックに合格したら、画面の指示に従ってランタイムの更新を完了します。
ノードプールの構成の詳細については、「ノードプールを更新する」をご参照ください。
ソリューション 2：containerd を使用するノードプールを作成し、ノードをノードプールに移行する（オプション）
このソリューションでは、containerd を使用するノードプールを作成し、ノードプールをスケールアウトする必要があります。次に、元のノードプールから containerd を使用するノードプールにノードを徐々に移行し、元のノードプールを削除する必要があります。これを行うには、元のノードプールのノードをスケジューリング不可の状態に設定するか、ラベルベースのスケジューリングなど、元のノードプールのスケジューリング方法を変更します。
ノードプールの作成方法の詳細については、「ノードプールを作成および管理する」をご参照ください。ノードをスケジューリング不可の状態に設定する方法の詳細については、「ノード」をご参照ください。
アップグレード後の考慮事項
Docker から containerd にアップグレードした後も、Dockerfile の構文は変更されません。ベースイメージの互換性、環境変数の設定、ランタイムコマンドの定義など、ランタイム環境に関連する構成に細心の注意を払ってください。コンテナーイメージが containerd 環境で正常にビルドおよび実行できることを確認してください。
containerd はイメージのビルドをサポートしていません。ランタイムを containerd に変更した後、Docker build コマンドを実行してイメージをビルドすることはできませんが、イメージをプルすることはできます。
コンテナーランタイムを Docker から containerd に変更した後、Docker はコンテナーライフサイクルの管理者ではなくなります。Docker コマンドを実行したり、Docker API を呼び出してコンテナーのステータスをクエリしたり、コンテナーを管理したりすることはできなくなります。ただし、代わりに containerd コマンドを実行できます。containerd コマンドと Docker コマンドのマッピングの詳細については、「Docker、containerd、および Sandboxed-Container の比較」をご参照ください。
システムディスクの置き換え方法
ACK は、次の手順を自動的に実行してノードのシステムディスクを置き換え、Docker から containerd にアップグレードします。
ノードをドレインし、スケジューリング不可の状態に設定します。
ECS インスタンスを停止します。
各ノードのシステムディスクを置き換え、ディスクの ID を変更します。システムディスクのカテゴリ、ECS インスタンスの IP アドレス、ECS インスタンスにバインドされている ENI の MAC アドレスは変更されません。
ノードを再初期化し、containerd をインストールします。
ノードを再起動し、スケジューリング可能の状態に設定します。
FAQ
バッチでノードをアップグレードするにはどれくらいの時間がかかりますか？
ACK コンソールの [ノードプール] ページから Docker から containerd にアップグレードすることを選択した場合、ACK はノードのシステムディスクを置き換えることによってノードをアップグレードします。スナップショットが関係しない場合、アップグレードには通常 8 分未満かかります。[更新前にスナップショットを作成] チェックボックスをオンにすると、ACK はスナップショットが作成された後にノードのアップグレードを開始します。スナップショット作成のタイムアウト期間は 40 分です。スナップショットの作成がタイムアウトした場合、ノードのアップグレードは失敗します。システムディスクにビジネスデータが保存されていない場合は、[更新前にスナップショットを作成] チェックボックスをオフにすることをお勧めします。
バッチごとにアップグレードされるノードの数は、1、2、4、8… の順序でバッチごとに増加します。最大同時実行数に達すると、後続のバッチのそれぞれでアップグレードされるノードの最大数は最大同時実行数と等しくなります。たとえば、最大同時実行数が 4 の場合、最初のバッチでは 1 つのノードがアップグレードされ、2 番目のバッチでは 2 つのノードが同時にアップグレードされ、3 番目のバッチ以降では 4 つのノードが同時にアップグレードされます。
アップグレードはビジネスに悪影響を及ぼしますか？
ACK コンソールの [ノードプール] ページから Docker から containerd にアップグレードすることを選択した場合、ACK はノードのシステムディスクを置き換えることによってノードをアップグレードします。ACK は、ノードのシステムディスクを置き換えるときに、ノードを自動的にドレインします。アプリケーションのポッドで安全停止が有効になっており、ポッドが複数のノードに分散されている場合、アップグレードはアプリケーションに影響を与えません。安全停止の詳細については、「Kubernetes での安全停止とゼロダウンタイムデプロイ」をご参照ください。ACK がアプリケーションのすべてのポッドを 1 つのバッチでアップグレードしないようにするには、最大同時実行数をポッドの総数よりも小さい値に手動で調整できます。
Docker から containerd にアップグレードした後、ロールバックできますか？
いいえ、Docker から containerd にアップグレードしたら、ロールバックすることはできません。
Docker から containerd にアップグレードすると、ノードデータは失われますか？
ACK コンソールの [ノードプール] ページから Docker から containerd にアップグレードすることを選択した場合、ACK はノードのシステムディスクを置き換えることによってノードをアップグレードします。したがって、重要なデータをノードのシステムディスクに保存したり、事前にシステムディスクをバックアップしたりしないでください。データディスクはアップグレードの影響を受けません。
システムディスクの置き換え後、ノードの IP アドレスは変更されますか？
ノードのシステムディスクが置き換えられた後、ディスク ID は変更されますが、システムディスクのカテゴリ、ECS インスタンスの IP アドレス、ECS インスタンスにバインドされている ENI の MAC アドレスは変更されません。詳細については、「インスタンスのシステムディスク（オペレーティングシステム）を置き換える」をご参照ください。
containerd と Docker の互換性はどのようになっていますか？
ほとんどの場合、Kubernetes ワークロードはコンテナーランタイムに依存しておらず、Docker バックエンドは依然として containerd です。そのため、containerd にアップグレードした後も、ワークロードは通常どおり実行を継続できます。
containerd はイメージのビルドをサポートしていません。ランタイムを containerd に変更した後、Docker build コマンドを実行してイメージをビルドすることはできませんが、イメージをプルすることはできます。
コンテナーランタイムを Docker から containerd に変更した後、Docker はコンテナーライフサイクルの管理者ではなくなります。Docker コマンドを実行したり、Docker API を呼び出してコンテナーのステータスをクエリしたり、コンテナーを管理したりすることはできなくなります。
ノードが containerd にアップグレードされる前に Docker に依存してイメージをビルドしている場合はどうすればよいですか？
Container Registry を使用してイメージをビルドするか、containerd にアップグレードした後に手動でイメージをビルドできます。
Container Registry を使用する（推奨）：Container Registry は、Docker が提供する BuildKit ツールを使用してイメージをビルドできます。Container Registry インスタンスを作成し、Dockerfile に基づいてイメージを自動的にビルドし、イメージをリポジトリにプッシュするように Container Registry をトリガーできます。詳細については、「Container Registry Enterprise Edition インスタンスを使用してイメージをビルドする」をご参照ください。
手動でイメージをビルドする：ノードの最適なパフォーマンスを確保するために、追加の ECS インスタンスを作成し、Docker をインストールしてから、Docker build コマンドを実行してイメージをビルドすることをお勧めします。詳細については、「Docker をインストールする」をご参照ください。
ノードのコンテナーランタイムを Docker から containerd に変更した後、Docker ディレクトリがまだ存在し、ディスク容量を占有している場合はどうすればよいですか？
クラスタ関連のコンテナー、イメージ、ログに加えて、作成したファイルパスが Docker ディレクトリに含まれています。Docker ディレクトリのデータが不要になった場合は、手動でディレクトリを削除できます。