ノードを containerd 2 に移行する

Autopilot Standard

---

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 の呼び出しが失敗します。

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

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

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

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

移行するイメージを探す

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

Cloud Logging を使用する

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 を使用するようにこれらのアプリケーションを更新する必要があります。

ワークロードを特定する

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

kubectl を使用する

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

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

kubectl get pods --all-namespaces -o json | jq -r '.items[] |
select(.spec.volumes[]? | select(.hostPath.path? and (.hostPath.path |
startswith("/run") or startswith("/var/run") or . == "/"))) |
.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"