このページでは、containerd コンテナ ランタイム、Google Kubernetes Engine（GKE）における Docker のサポート、および containerd を使用するノードイメージへの移行が必要な理由の概要について説明します。containerd ノードイメージへの移行方法については、Docker から containerd ノードイメージに移行するをご覧ください。
概要
Kubernetes ノードでは、コンテナ ランタイムを使用して、Pod で実行されるコンテナの起動、管理、停止を行います。Kubernetes プロジェクトでは、Kubernetes バージョン 1.24 以降で Docker ランタイムの組み込みサポートを廃止します。これを行うために、Kubernetes では、Docker が kubelet のような Kubernetes コンポーネントと通信できるようにする dockershim と呼ばれるコンポーネントが削除されます。
新しいデフォルトのライタイムである containerd は、業界標準のコンテナ ランタイムで、Kubernetes でサポートされ、他の多くのプロジェクトで使用されています。containerd ランタイムは、gVisor やイメージ ストリーミングなどの豊富な機能を実装して GKE の機能を拡張できるようにするレイヤ抽象化の機能を備えています。また、このランタイムは、Docker ランタイムよりもリソース効率が高く安全であると考えられています。
この変更のため、GKE バージョン 1.24 以降、ランタイムとして Docker を使用するノードイメージはサポートされません。クラスタは、いずれかのノードプールが Docker ベースのノードイメージを使用しているか、Docker ベースのデフォルトのノードイメージ タイプでノードの自動プロビジョニングを使用している場合に影響を受けます。
2023 年 7 月 31 日（GKE バージョン 1.23 のサポート終了日）までは、GKE が自動アップグレードを一時停止し、バージョン 1.24 への手動アップグレードを防止します。この日付より前にクラスタのコントロール プレーンを GKE バージョン 1.24 以降にアップグレードするには、ノードの自動プロビジョニング構成を更新し、すべてのノードを containerd ランタイムに更新する必要があります。ノードプールをアップグレードするには、containerd ランタイムを使用するノードイメージに移行する必要があります。
1.23 のサポート終了後、GKE はまだ移行を完了していないクラスタに対して、1.24 への手動によるコントロール プレーン アップグレードのブロックを解除し、セキュリティと互換性を目的としてクラスタの段階的アップグレードを開始します。GKE がクラスタを 1.24 にアップグレードする方法と、Docker ノードイメージからクラスタを移行する場合に推奨される方法については、バージョン 1.23 のサポート終了時の自動移行をご覧ください。
Docker ノードイメージと containerd ノードイメージ
containerd は、Linux ではバージョン 1.19、Windows ではバージョン 1.21 から、すべての新しい GKE ノードでデフォルトのランタイムとなっています。しかし、GKE Standard クラスタでは、Docker をランタイムとして使用するノードイメージもサポートし続けていました。次の表では、GKE バージョン 1.24 以降でサポートされない Docker ベースのノードイメージと、それに対応する containerd を示します。
| Docker ランタイム | containerd ランタイム |
|---|---|
Docker を含む Container-Optimized OS（cos） |
containerdを含む Container-Optimized OS（cos_containerd） |
Docker を含む Ubuntu（ubuntu） |
containerdを含む Ubuntu（ubuntu_containerd） |
Docker を含む Windows Server LTSC（windows_ltsc） |
containerd を含む Windows Server LTSC（windows_ltsc_containerd） |
Docker を含む Windows Server SAC（ |
containerd を含む Windows Server SAC（ |
タイムラインとマイルストーン
GKE バージョン 1.23 では、以下のことができなくなりました。
- Docker ベースのノードイメージを使用する新しいクラスタを作成する。
- Docker ベースのノードイメージを含む新しいノードプールを既存のクラスタに追加する。
--autoprovisioning-image-typeフラグを Docker ベースのノードイメージに設定して、ノードの自動プロビジョニングを有効にする。
GKE バージョン 1.23 にアップグレードする場合は、以下のことを引き続き使用できます。
- アップグレード前に作成された Docker ベースのノードイメージを含む既存のノードプール。
- Docker ノードイメージを含むノードプール上のクラスタ オートスケーラー。
--autoprovisioning-image-typeフラグが Docker ベースのノードイメージに設定されたノードの自動プロビジョニング（アップグレード前に有効になっている場合）。
GKE バージョン 1.24 では、以下ことができなくなりました。
- コントロール プレーンでバージョン 1.24 が実行されている場合、
--autoprovisioning-image-typeフラグを Docker ベースのノードイメージに設定してノードの自動プロビジョニングを使用することはできません。 - ノードプールでバージョン 1.24 が実行されている場合、ノードでは Docker ベースのノードイメージを使用できません。
次の表に、今後リリースされる GKE バージョンを操作する際に想定される変更点の概要を示します。
| アクション | GKE バージョン 1.23 | GKE バージョン 1.24 |
|---|---|---|
| Docker で新しいクラスタを作成する | × | × |
| Docker で新しいノードプールを作成する | × | × |
| Docker でノードの自動プロビジョニングを有効にする | × | × |
| 既存の Docker ノードの自動プロビジョニング構成で以前のバージョンからアップグレードする | はい | × |
| Docker ベースのノードイメージを使用する | はい | × |
バージョン 1.23 のサポートが終了したときの自動移行
2023 年 7 月 31 日でバージョン 1.23 のサポートが終了する前に、バージョン 1.24 にアップグレードせず containerd ノードイメージに移行すると、GKE では時間の経過とともに以下の処理が行われます。
クラスタに、Docker ベースのデフォルト ノードイメージ タイプを使用してノードの自動プロビジョニングが設定されている場合、GKE は containerd ランタイムを使用する同等のノードイメージを使うように構成を更新します。このオペレーションをメンテナンスの除外でブロックすることはできません。ワークロードに悪影響がないことを確認するには、GKE が構成を自動で更新する前に、ノードの自動プロビジョニングのデフォルト イメージタイプを containerd ベースのイメージに手動で更新することをおすすめします。
GKE によって、クラスタのコントロール プレーンがバージョン 1.24 にアップグレードされます。
2023 年 9 月 1 日からは、GKE によって、Docker を使用し続けているノードプールが containerd ノードイメージに移行され始めます。ノードイメージは、この日より前に手動で移行することをおすすめします。他の方法としては、containerd イメージを使用するようにクラスタを移行するオペレーションの開始を、GKE へリクエストすることもできます。このリクエストを行うには、Cloud カスタマーケアまでお問い合わせください。
自動移行を一時的にブロックするには、クラスタをバージョン 1.24 以降にアップグレードして、メンテナンスの除外を構成します。このメンテナンスの除外の詳細については、containerd ノードイメージへの自動移行を一時的に遅らせるをご覧ください。
GKE によって、バージョン 1.23 のノードプールが 1.24 にアップグレードされます。これは、オープンソースのバージョン スキュー ポリシーに従ってクラスタの健全性を確保するために、サポートされていないバージョンで行われるものです。詳細については、GKE マイナー バージョンのライフサイクルをご覧ください。このアップグレードは、メンテナンスの除外を使用して一時的にブロックできます。
containerd ノードイメージへの自動移行を一時的に遅らせる
クラスタのコントロール プレーンが 1.24 以降にアップグレードされた後は、メンテナンスの除外を構成して、バージョン 1.25 のサポートが終了する 2024 年 2 月 29 日まで、ノードの移行を一時的に防ぐことができます。このメンテナンスの除外を適用するには、クラスタがリリース チャンネルに登録されている必要があります。メンテナンスの除外は、「マイナーまたはノードのアップグレードなし」のスコープを使用して構成し、--add-maintenance-exclusion-end フラグを 2024-02-29T00:00:00Z 以前に設定します。できるだけ早く移行のブロックを解除して、ノードをバージョン 1.24 にアップグレードできるようにすることをおすすめします。サポートが終了したマイナー バージョンでは、セキュリティ パッチやバグの修正を受け取れなくなります。
Docker から containerd ノードイメージに移行する
Docker ベースのノードイメージを使用しているクラスタとノードプールを特定し、これらのノードプールを containerd ノードイメージに移行するには、Docker から containerd ノードイメージに移行するをご覧ください。
GKE の共有責任モデルの一環として、ワークロードの健全性を維持することはお客様の責任の一部であり、クラスタが機能し続けること（サポート対象のバージョンの実行を含む）を保証することは Google の責任の一部です。GKE が自動で移行を行う前に、ワークロードをテストしてクラスタを移行することを強くおすすめします。
1.23 がサポート終了になる前に、GKE は Docker ノードイメージを使用するノードプールを持つクラスタでの 1.24 への自動アップグレードや手動アップグレードを禁止します。containerd イメージのみを使用するようにクラスタを移行した後は、GKE リリース スケジュールに従って、自動アップグレードを 1 日以内に再開できます。また、クラスタを手動でアップグレードすることもできます。
1.23 がサポート終了になると、GKE は 1.24 への自動アップグレードや手動アップグレードのブロックを解除し、自動移行プロセスに従います。
移行による影響
containerd ノードイメージに移行する場合の主な変更点は、Docker がコンテナのライフサイクル（コンテナの起動や停止など）を管理しなくなることです。そのため、Docker コマンドや Docker API を使用して、containerd イメージを使用するノード上で実行される GKE コンテナの表示や操作を行うことはできません。
ほとんどのユーザー ワークロードは、コンテナ ランタイムに依存しません。Docker ランタイムには containerd も実装されているため、ワークロードは containerd ノードイメージでも同様に動作します。
以下の状況では、影響を受ける可能性があります。
- Docker コマンドを実行する特権 Pod を実行する。
- Kubernetes インフラストラクチャの外部から、ノードでスクリプトを実行する（SSH を使用して問題のトラブルシューティングを行うなど）。
- 同様の特権オペレーションを実行するサードパーティ製ツールを実行する。
- 一部のツールが、モニタリング システム内の Docker 固有のログに応答する。
- 外部ベンダーが提供するロギング、モニタリング、セキュリティ、または継続的インテグレーションのツールを GKE クラスタにデプロイする。影響については、各ベンダーにお問い合わせください。
次の場合には影響はありません。
- GKE クラスタの外部に、Docker を使用してコンテナ イメージをビルドして push するビルド パイプラインがある。
- GKE クラスタで
docker buildコマンドとdocker pushコマンドを使用する。containerd を使用した Linux ノードイメージに Docker バイナリが含まれており、これらのコマンドがサポートされています。
特権 Pod を使用して Docker にアクセスする
ユーザーが特権 Pod を使用してノード上の Docker Engine にアクセスする場合は、Docker に直接依存しないようにそれらのワークロードを更新する必要があります。たとえば、ロギングとモニタリングの抽出プロセスを Docker Engine から GKE システム アドオンに移行することを検討してください。
containerd を使用してコンテナ イメージをビルドする
containerd を使用してコンテナ イメージをビルドすることはできません。containerd 使用した Linux イメージには Docker バイナリが含まれているため、Docker でイメージをビルドして push できます。しかし、個々のコンテナやローカルノードを使用して、イメージをビルドするコマンドを実行することはおすすめしません。
Kubernetes は自身のスコープ外のローカル プロセスで使用されるシステム リソースを認識しないので、Kubernetes コントロール プレーンはリソースを割り当てる際にそれらのプロセスを考慮することができません。その結果、リソース関係の GKE ワークロードが枯渇する可能性があります。また、ノードが不安定になる可能性もあります。
このようなタスクを実施する場合は、個々のコンテナのスコープ外で他のサービス（Cloud Build など）を利用するか、kaniko などのツールを使用して Kubernetes ワークロードの形でイメージをビルドすることを検討してください。
これらの推奨事項を採用できない場合は、リスクを理解したうえで、ローカルノードで Docker によるイメージのビルドを進めてください。イメージは、GKE クラスタで使用する前にレジストリへ push しておく必要があります。containerd を使用する Kubernetes では、Docker を使用してローカルにビルドされたイメージは認識されません。
containerd ノード上のコンテナをデバッグする
Linux ノードでのデバッグやトラブルシューティングのため、Kubernetes コンテナ ランタイム用にビルドされたポータブル コマンドライン ツール crictl を使用して、containerd と対話できます。crictl は、コンテナやイメージの表示、ログの読み取り、コンテナでのコマンドの実行などの一般的な機能をサポートします。サポートされている全機能と使用方法については、crictl ユーザーガイドをご覧ください。
Windows Server ノードの場合、containerd デーモンは containerd という名前の Windows サービスとして実行されます。
ログへのアクセス方法は、次のとおりです。
- Windows:
C:\etc\kubernetes\logs\containerd.log - Linux:
journalctl -u containerdを実行
LOG NAME: "container-runtime" のログ エクスプローラで Windows ノードと Linux ノードのログを表示することもできます。
トラブルシューティング
トラブルシューティングについては、containerd ランタイムのトラブルシューティングをご覧ください。