Kubernetes V1.24では、Dockerは組み込みコンテナランタイムとして使用されなくなり、Dockershimコンポーネントは削除されました。 つまり、kubeletはこのコンポーネントを介してDockerと対話してコンテナを作成および管理しなくなります。 そのため、Alibaba Cloud Container Service for Kubernetes (ACK) は、Kubernetesバージョン1.24以降での組み込みコンテナランタイムとしてのDockerの使用のサポートも終了しました。 KubernetesバージョンのACKクラスターを1.24以降にアップグレードするには、コンテナランタイムをDockerからクラスター用のcontainerdに移行する必要があります。
コンテナランタイムcontainerdは、Kubernetesでサポートされている業界標準のランタイムです。 費用対効果とセキュリティの点でDockerを過大評価しています。 containerdの詳細については、「containerd」をご参照ください。
前提条件
ACKクラスターが作成され、Dockerを使用するノードがクラスターにデプロイされます。 詳細については、「クラスターの作成」をご参照ください。
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を呼び出してコンテナのステータスを照会したり、コンテナを管理したりすることはできません。
手順
オフピーク時にコンソールでランタイムを変更および更新することを推奨します。 次のセクションでは、ノードのランタイムを更新する方法を紹介します。 ノードプールの更新方法の詳細については、「ノードプールの更新」をご参照ください。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
On theノードプールページで、管理するノードプールを選択し、もっと>Kubeletアップデート.
[Container Runtime Update] を選択し、[Precheck] をクリックします。 クラスターが事前チェックに合格した後、プロンプトに従ってランタイムを更新します。
よくある質問
バッチでノードを更新するにはどのくらいの時間が必要ですか?
ノードプールの更新ページを介した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コマンドを使用してイメージをビルドします。 詳細については、「Dockerのインストール」をご参照ください。
ノードのコンテナランタイムをDockerからcontainerdに変更した後、Dockerディレクトリがまだ存在し、ディスク領域を占有している場合はどうすればよいですか?
クラスター関連のコンテナー、イメージ、およびログに加えて、作成したファイルパスもDockerディレクトリに含まれます。 Dockerディレクトリのデータが不要になった場合は、手動でディレクトリを削除できます。