ノードを containerd 2 に移行する

Google Kubernetes Engine（GKE）クラスタは、バージョン 1.24 以降を実行するすべてのワーカーノードで containerd ノードイメージを使用します。ワーカーノードは、GKE バージョンに基づいて特定のバージョンの containerd を使用します。

  • containerd ノードイメージを使用して GKE 1.32 以前を実行するノードは、containerd 1.7 以前のバージョンを使用します。
  • GKE 1.33 を実行するノードは containerd 2.0 を使用します。

GKE ノードが 1.32 から 1.33 にアップグレードされると、ノードは containerd 1.7 から新しいメジャー バージョンの containerd 2.0 に移行します。GKE バージョンで使用する containerd バージョンを変更することはできません。

ワークロードが containerd 2 で想定どおりに実行されていることがわかっている場合、このページを読む必要はありません。

GKE が containerd 2 に移行する仕組み

次のタイムラインを確認して、containerd 2 を使用するために GKE が既存のクラスタを移行する過程を確認してください。

  • マイナー バージョン 1.32 では、GKE は containerd 1.7 を使用します。containerd 1.7 では、Docker スキーマ 1 イメージと Container Runtime Interface（CRI）v1alpha2 API の両方が非推奨になりました。以前のバージョンで非推奨になったその他の機能については、非推奨の構成プロパティをご覧ください。
  • マイナー バージョン 1.33 では、GKE は containerd 2.0 を使用します。これにより、Docker スキーマ 1 イメージと CRI v1alpha2 API のサポートが終了します。
  • CRI プラグイン内の次の containerd 構成プロパティは非推奨であり、containerd 2.1 で削除されます。GKE バージョンはまだ発表されていません。registry.auths、registry.configs、registry.mirrors.

1.33 などの新しいマイナー バージョンへの自動アップグレードのおおよそのタイミングについては、リリース チャンネルのおおよそのスケジュールをご覧ください。

containerd 2 への移行の影響

containerd 2 へのこの移行の影響については、次のセクションをご覧ください。

自動アップグレードが一時停止されている

クラスタで非推奨の機能が使用されていることを検出すると、GKE は 1.33 への自動アップグレードを一時停止します。ただし、クラスタノードでこれらの機能を使用する場合は、メンテナンスの除外を作成してノードのアップグレードを防ぐことをおすすめします。メンテナンスの除外を使用すると、GKE で使用が検出されない場合、ノードがアップグレードされなくなります。

これらの機能の使用から移行した後、1.33 がクラスタノードの自動アップグレードのターゲットであり、自動アップグレードをブロックする他の要因がない場合、GKE は 1.33 への自動マイナー アップグレードを再開します。Standard クラスタのノードプールの場合は、ノードプールを手動でアップグレードすることもできます。

サポート終了と移行の準備ができていない場合の影響

GKE は、標準サポートの終了まで自動アップグレードを一時停止します。クラスタが Extended チャンネルに登録されている場合、ノードは拡張サポートの終了まで同じバージョンを維持できます。サポート終了時のノードの自動アップグレードの詳細については、サポート終了時の自動アップグレードをご覧ください。

これらの機能から移行しない場合、1.32 がサポート終了になり、クラスタノードが 1.33 に自動的にアップグレードされると、クラスタで次の問題が発生する可能性があります。

  • Docker スキーマ 1 イメージを使用するワークロードが失敗します。
  • CRI v1alpha2 API を呼び出すアプリケーションで、API の呼び出しが失敗します。

影響を受けるクラスタを特定する

GKE はクラスタをモニタリングし、Recommender サービスを使用して分析情報と推奨事項という形式でガイダンスを提供します。これにより、非推奨の機能を使用するクラスタノードを特定できます。

バージョン要件

クラスタは、次のバージョン以降を実行している場合に、これらの分析情報と推奨事項を受け取ります。

  • 1.28.15-gke.1159000
  • 1.29.9-gke.1541000
  • 1.30.5-gke.1355000
  • 1.31.1-gke.1621000

分析情報と推奨事項を取得する

手順に沿って分析情報と推奨事項を表示する。分析情報は Google Cloud コンソールを使用して取得できます。Google Cloud CLI または Recommender API を使用して、次のサブタイプでフィルタリングすることもできます。

  • DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: Docker スキーマ 1 イメージ
  • DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: CRI v1alpha2 API

非推奨の機能から移行する

containerd 2 で非推奨になった機能から移行する方法については、次の内容をご覧ください。

Docker スキーマ 1 イメージから移行する

移行が必要なイメージを使用するワークロードを特定し、それらのワークロードを移行します。

移行するイメージを探す

移行が必要なイメージは、さまざまなツールを使用して見つけることができます。

分析情報と推奨事項、または Cloud Logging を使用する

影響を受けるクラスタを特定するセクションで説明したように、クラスタが最小バージョン以降を実行している場合は、分析情報と推奨事項を使用して、Docker Schema 1 イメージを使用するクラスタを見つけることができます。また、Cloud Logging で次のクエリを使用して containerd ログを確認し、クラスタ内の Docker Schema 1 イメージを見つけることもできます。

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

画像の取得から 30 日以上経過している場合、画像のログが表示されないことがあります。

ノードで ctr コマンドを直接使用する

特定のノードに対してクエリを実行して、Schema 1 として pull された削除されていないすべてのイメージを返すには、ノードで次のコマンドを実行します。

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

このコマンドは、特定のノードのトラブルシューティングを行っていて、イメージの pull から 30 日以上経過しているため、Cloud Logging にログエントリが表示されない場合に便利です。

crane オープンソース ツールを使用する

crane などのオープンソース ツールを使用して画像を確認することもできます。

次の crane コマンドを実行して、イメージのスキーマ バージョンを確認します。

crane manifest $tagged_image | jq .schemaVersion

ワークロードを準備する

Docker スキーマ 1 イメージを実行するワークロードを準備するには、それらのワークロードをスキーマ 2 Docker イメージまたは Open Container Initiative（OCI）イメージに移行する必要があります。移行には、次のオプションを検討してください。

  • 交換用イメージを探す: 一般公開されているオープンソース イメージやベンダー提供のイメージを見つけることができます。
  • 既存のイメージを変換する: 置き換えイメージが見つからない場合は、次の手順で既存の Docker スキーマ 1 イメージを OCI イメージに変換できます。
    1. Docker イメージを containerd に pull します。これにより、イメージは自動的に OCI イメージに変換されます。
    2. 新しい OCI イメージをレジストリに push します。

CRI v1alpha2 API から移行する

CRI v1alpha2 API は Kubernetes 1.26 で削除されました。containerd ソケットにアクセスするワークロードを特定し、v1 API を使用するようにこれらのアプリケーションを更新する必要があります。

ワークロードを特定する

移行が必要なワークロードを特定するには、さまざまな手法を使用できます。

分析情報と推奨事項を使用する

クラスタが最小バージョン以降を実行している場合は、分析情報と推奨事項を使用して、v1alpha2 API を使用するクラスタを見つけることができます。詳細については、影響を受けるクラスタを特定するをご覧ください。

Google Cloud コンソールで分析情報を表示する場合は、サイドバー パネルの 非推奨の CRI v1alpha2 API からワークロードを移行するをご覧ください。containerd ソケットにアクセスするワークロードを確認するには、確認するワークロードのセクションを確認します。

kubectl を使用する

次のコマンドは、containerd ソケットにアクセスするワークロードを見つけるのに役立ちます。このコマンドは、ソケットを含む hostPath ディレクトリをマウントするワークロードを返します。一部のワークロードは、これらのディレクトリまたは他の子ディレクトリをマウントしますが、containerd ソケットにはアクセスしないため、このクエリで誤検出が発生する可能性があります。

次のコマンドを実行します。

kubectl get pods --all-namespaces -o json |
jq -r '.items[] |
  select(.spec.volumes[]?.hostPath.path as $p |
    ["/", "/var", "/var/","/var/run", "/var/run/",
     "/var/run/containerd", "/var/run/containerd/",
     "/var/run/containerd/containerd.sock",
     "/run", "/run/", "/run/containerd", "/run/containerd/",
     "/run/containerd/containerd.sock"] | index($p)) |
  .metadata.namespace + "/" + .metadata.name'
アプリケーション コードを確認する

アプリケーション コードを確認して、CRI v1alpha2 API クライアント ライブラリがインポートされているかどうかを確認できます。

たとえば、次の golang コードをご覧ください。

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

ここで、アプリケーションは v1alpha2 ライブラリをインポートし、RPC の発行に使用します。RPC が containerd ソケットへの接続を使用する場合、このアプリケーションにより GKE がクラスタの自動アップグレードを一時停止します。

アプリケーション コードを検索して更新する手順は次のとおりです。

  1. 次のコマンドを実行して v1alpha2 インポートパスを検索し、問題のある golang アプリケーションを特定します。

      grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

    このコマンドの出力で、ファイルで v1alpha2 ライブラリが使用されていることが示されている場合は、ファイルを更新する必要があります。

    たとえば、次のアプリコードを置き換えます。

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

  2. v1 を使用するようにコードを更新します。

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"