Kubernetes 1.24は、組み込みのコンテナランタイムとしてDockerを使用しなくなりました。 Container Service for Kubernetes (ACK) クラスターのKubernetesバージョンを1.24以降に更新する場合は、コンテナランタイムをDockerからクラスターのcontainerdに移行する必要があります。 このトピックでは、ACKコンソールでACKクラスターのコンテナランタイムをDockerからcontainerdに移行する方法について説明します。
前提条件
ACKクラスターが作成されます。 詳細については、「ACK管理クラスターの作成」をご参照ください。
Dockerを使用するノードは、ACKクラスターにデプロイされます。
Dockerからcontainerdへの移行の概要
アップグレード計画
Dockerからcontainerdへのコンテナランタイムの移行には、次の2つのノードプール更新プランが使用されます。
計画1: 新しいノードプールを作成し、新しいノードプールにワークロードを移行することで更新します。 新しいノードプールを作成し、ノードプールの作成時にcontainerdをコンテナランタイムとして選択します。 次に、ワークロードを再デプロイし、アプリケーションポッドを新しいノードプールにスケジュールし、レガシーノードプールを削除してワークロードを新しいノードプールに移行します。
計画2: システムディスクを交換して更新します。 この計画では、ノードのシステムディスクを交換する必要があります。 次のセクションでは、この更新プランのスキームと設定方法について説明します。
システムディスクを交換してノードプールを更新する方法
事前チェック: バックグラウンドプログラムは、クラスターと依存コンポーネントのバージョンがcontainerdのランタイム要件を満たしているかどうかを自動的にチェックします。 それ以外の場合は、更新前に失敗したチェックを処理します。
ノードプールの更新: バッチで同時に更新できるノードの最大数を指定できます。 最大同時実行性は、ノードの総数の10% を超えません。 バッチごとに更新されるノードの数は、次の順序でバッチごとに増加します。1、2、4、8... 最大同時実行性に達した後、次の各バッチで更新されるノードの最大数は、最大同時実行性に等しくなります。 最大同時実行性を4に設定すると、最初のバッチで1つのノードが更新され、2番目のバッチで2つのノードが同時に更新され、3番目以降のバッチで4つのノードが同時に更新されます。
システムディスクの交換によるノードの更新方法
ノードはドレインされます。 ノードがドレインされると、スケジュール不可に設定されます。
Elastic Compute Service (ECS) インスタンスが停止しています。
システムディスクが交換され、ディスクIDが変更されます。 システムディスクのカテゴリ、ECSインスタンスのIPアドレス、およびECSインスタンスにバインドされているelastic network Interface (ENI) のMACアドレスは変更されません。
ノードを再初期化します。
ノードが再起動され、準備が整いました。 ノードの準備が整うと、ノードはスケジューリング可能に設定される。
注意事項
ほとんどの場合、ワークロードはコンテナランタイムに依存しません。 Dockerはcontainerdを実装します。 理論的には、コンテナランタイムをDockerからcontainerdに変更しても、ワークロードは影響を受けません。
運用環境でランタイムを変更したときに発生する可能性のある例外を回避するために、テスト環境でのワークロードに対するランタイム置換の影響をテストすることをお勧めします。
containerdは画像構築をサポートしていません。 ランタイムをcontainerdに変更した後、docker buildコマンドを実行してイメージをビルドすることはできません。 通常どおり画像をプルできます。
コンテナランタイムをDockerからcontainerdに変更した後は、クラスター内のノードでイメージをビルドしないことを推奨します。
コンテナランタイムをDockerからcontainerdに移行すると、Dockerはコンテナライフサイクルの管理者ではなくなります。 Dockerコマンドを実行したり、Docker APIを呼び出してコンテナのステータスを照会したり、コンテナを管理したりすることはできません。
背景情報
Kubernetes 1.24は、組み込みのコンテナランタイムとしてDockerを使用しなくなりました。 DockershimはKubernetes 1.24で削除され、kubeletはDockershimを使用してDockerと対話したりコンテナーを管理したりできなくなります。
この更新により、Kubernetes 1.24以降を実行するACKクラスターは、組み込みコンテナランタイムとしてDockerを使用しません。 クラスターがコンテナーランタイムとしてDockerを使用している場合、クラスターのKubernetesバージョンを1.24以降に更新する前に、コンテナーランタイムをcontainerdに変更する必要があります。
containerdは、コスト効率とセキュリティの点でDockerを上回る業界標準のコンテナランタイムです。 containerdの詳細については、「containerd」をご参照ください。
手順
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
ノードプールページで、管理するノードプールを選択し、もっと>アップグレード.
ランタイム更新を選択し、事前チェックをクリックしmす
クラスターが事前チェックに合格したら、ランタイム更新を選択し、アップデートの開始をクリックします。
ノードプールの更新方法の詳細については、「ノードプールの更新」をご参照ください。
よくある質問
バッチでノードを更新するにはどのくらいの時間が必要ですか?
ノードプールの更新ページを介したDockerからcontainerdへの移行は、システムディスクを置き換えることによって実行されます。 スナップショットが作成されていない場合、移行は8分以内に完了します。 [更新前にスナップショットを作成] を選択した場合、スナップショットの作成後にACKがノードの更新を開始します。 スナップショット作成のタイムアウト時間は40分です。 スナップショットの作成がタイムアウトすると、ノードの更新は失敗します。 システムディスクにビジネスデータが保存されていない場合は、更新前にスナップショットの作成をクリアすることを推奨します。
更新中にアプリケーションは影響を受けますか?
ノードプールの更新ページを介してDockerをcontainerdに移行するには、システムディスクを交換します。 ノードは更新中にドレインされます。 アプリケーションが複数のノードにまたがる複数のポッドで実行され、そのポッドに対してグレースフルシャットダウンが有効になっている場合、アプリケーションは影響を受けません。 グレースフルシャットダウンの詳細については、「Kubernetesでのグレースフルシャットダウンとゼロダウンタイムのデプロイ」をご参照ください。 アプリケーションのポッドを実行するすべてのノードが同じバッチで更新されないようにするには、最大同時実行性をアプリケーションが実行されるポッドの数よりも少ない値に設定することをお勧めします。
Dockerをcontainerdに移行した後にロールバックできますか?
更新後にコンテナーランタイムをロールバックすることはできません。
データ損失が発生しますかDockerからcontainerdに移行するとき?
ノードプールの更新ページを介したDockerからcontainerdへの移行は、システムディスクを置き換えることによって実行されます。 更新前にノードのシステムディスクのデータをバックアップし、重要なデータをシステムディスクに保存しないでください。 データディスクは更新の影響を受けません。
ノードのシステムディスクが交換された後、ノードのIPアドレスは変更されますか?
システムディスクが交換された後、ディスクIDは変更されますが、システムディスクのカテゴリ、ECSインスタンスのIPアドレス、およびECSインスタンスにバインドされているENIのMACアドレスは変更されません。
containerdはDockerとどのように互換性がありますか?
ほとんどの場合、ワークロードはコンテナランタイムに依存しません。 Dockerはcontainerdを実装します。 理論的には、コンテナランタイムをDockerからcontainerdに変更しても、ワークロードは影響を受けません。
containerdは画像構築をサポートしていません。 ランタイムをcontainerdに変更した後、docker buildコマンドを実行してイメージをビルドすることはできません。 通常どおり画像をプルできます。
コンテナランタイムをDockerからcontainerdに変更すると、Dockerはコンテナライフサイクルの管理者ではなくなります。 Dockerコマンドを実行したり、Docker APIを呼び出してコンテナのステータスを照会したり、コンテナを管理したりすることはできません。
以前にDockerに基づいてクラスターノードにイメージを構築した場合、コンテナランタイムをcontainerdに更新した後はどうすればよいですか?
Container Registryに基づいてイメージをビルドするか、手動でイメージをビルドできます。
Container Registryを使用してビルドする (推奨): Container Registryは、Dockerの公式イメージ構築ツールBuildKitに基づいています。 Container Registryインスタンスを作成すると、Dockerfilesに基づいて、ソースコードリポジトリからContainer Registryリポジトリへのイメージのビルドと配信が自動化されます。 ソースコードが更新されると、Container RegistryはDockerfileを使用してイメージを自動的に構築し、そのイメージをContainer Registryリポジトリにアップロードします。 詳細については、「Container Registry Enterprise Editionインスタンスを使用したイメージの構築」をご参照ください。
手動ビルド: ノードのパフォーマンスを確保するために、追加のECSインスタンスを作成することを推奨します。 Dockerを手動でインストールした後、Dockerコマンドを使用してイメージをビルドします。 詳細については、「LinuxインスタンスへのDockerのインストールと使用」をご参照ください。
ノードのコンテナランタイムをDockerからcontainerdに変更した後、Dockerディレクトリがまだ存在し、ディスク領域を占有している場合はどうすればよいですか?
クラスター関連のコンテナー、イメージ、およびログに加えて、作成したファイルパスもDockerディレクトリに含まれます。 Dockerディレクトリのデータが不要になった場合は、手動でディレクトリを削除できます。