このページの情報の一部またはすべては、S3NS の Trusted Cloud には適用されない場合があります。

ノードを 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 構成プロパティ、registry.auths、registry.configs、registry.mirrors は非推奨であり、containerd 2.2 で削除されます。GKE バージョンはまだ発表されていません。

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

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

分析情報と推奨事項を表示するの説明に従ってください。分析情報は Trusted 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 スキーマ 1 イメージを使用するクラスタを見つけることができます。また、Cloud Logging で次のクエリを使用して containerd ログを確認し、クラスタ内の Docker スキーマ 1 イメージを見つけることもできます。

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

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

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

特定のノードに対してクエリを実行し、スキーマ 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 を使用するクラスタを見つけることができます。詳細については、影響を受けるクラスタを特定するをご覧ください。

Trusted Cloud コンソールで分析情報を表示する場合は、サイドバーパネル [非推奨の CRI v1alpha2 API からワークロードを移行する] を確認してください。このパネルの [確認するワークロード] テーブルには、影響を受ける可能性があるワークロードが一覧表示されます。このリストには、containerd ソケットパス（/var/run/containerd/containerd.sock や /run/containerd/containerd.sock など）を含む hostPath ボリュームがある GKE で管理されていないワークロードが含まれます。

次の点を理解することが重要です。

このリストには誤検出が含まれている可能性があります。このリストにワークロードが表示されていても、非推奨の API を使用しているとは限りません。これは、ワークロードが containerd ソケットを含む hostPath ボリュームを参照していることを示しているだけです。たとえば、モニタリングエージェントは、指標を収集するためにノードのルートファイルシステム（/）を含める場合があります。ノードのルートファイルシステムを含めると、技術的にはソケットのパスも含まれますが、指標エージェントが実際に CRI v1alpha2 API を呼び出さない可能性があります。
このリストは空であるか、不完全である可能性があります。非推奨の API を使用するワークロードが短期間で終了し、GKE が定期的なチェックを実行したときに実行されていなかった場合、リストが空または不完全である可能性があります。推奨事項自体が存在するということは、クラスタ内の少なくとも 1 つのノードで CRI v1alpha2 API の使用が検出されたことを意味します。

そのため、次の方法で実際の API 使用状況を確認し、さらに調査することをおすすめします。

影響を受けるサードパーティワークロードを確認する

クラスタにデプロイされたサードパーティソフトウェアについて、それらのワークロードが CRI v1alpha2 API を使用していないことを確認します。必要に応じて各ベンダーに問い合わせて、それらのソフトウェアの互換性があるバージョンを確認してください。

kubectl を使用する

次のコマンドは、containerd ソケットにアクセスするワークロードを検索して、影響を受ける可能性のあるワークロードを見つける際に役立ちます。これは、 Trusted Cloud コンソールの推奨事項の [確認するワークロード] テーブルで使用されるロジックと同様のロジックを使用します。ソケットのパスを含む hostPath ボリュームがある、GKE で管理されていないワークロードを返します。このクエリは、推奨事項と同様に、誤検出を返すか、有効期間の短いワークロードを見逃す可能性があります。

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

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/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"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'

eBPF トレースを使用して API 呼び出し元を特定する

CRI v1alpha2 API を呼び出しているワークロードをより確実に特定するには、containerd-socket-tracer と cri-v1alpha2-api-deprecation-reporter の 2 つの専用 DaemonSet をデプロイします。これらのツールは、Extended Berkeley Packet Filter（eBPF）を使用して containerd ソケットへの接続をトレースし、接続と実際の非推奨 API 呼び出しを関連付けます。

containerd-socket-tracer は、containerd ソケットへの接続を開くプロセスを、Pod とコンテナの詳細とともにログに記録します。
cri-v1alpha2-api-deprecation-reporter は、CRI v1alpha2 API が最後に呼び出された日時を記録します。

これらの 2 つのツールのタイムスタンプを関連付けることで、非推奨の API 呼び出しを行っているワークロードを正確に特定できます。この方法は、実際のソケット接続と API 使用状況を監視するため、hostPath ボリュームのみを確認するよりも信頼性が高くなります。

これらのツールのデプロイと使用の方法、ログの解釈方法の詳細については、containerd ソケット接続のトレースをご覧ください。

これらのツールを使用しても非推奨の API 呼び出しのソースを特定できず、推奨事項がアクティブなままの場合は、サポートを受けるをご覧ください。

上記の方法またはコードベースの検査によって、CRI v1alpha2 API を使用しているワークロードを特定したら、v1 API を使用するようにコードを更新する必要があります。

アプリケーションコードを更新する

アプリケーションを更新するには、アプリケーションが k8s.io/cri-api/pkg/apis/runtime/v1alpha2 クライアントライブラリをインポートしている箇所を削除し、API の v1 バージョンを使用するようにコードを変更します。このステップでは、インポートパスを変更し、コードが 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 はクラスタの自動アップグレードを一時停止します。

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

次のコマンドを実行して v1alpha2 インポートパスを検索し、問題のある golang アプリケーションを特定します。
```
  grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
このコマンドの出力で、ファイルで v1alpha2 ライブラリが使用されていることが示されている場合は、ファイルを更新する必要があります。

たとえば、次のアプリケーションコードを置き換えます。
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
v1 を使用するようにコードを更新します。
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"
```

サポートを受ける

eBPF トレースを使用して API 呼び出し元を特定するの手順に沿って操作しても、非推奨の API 呼び出しのソースを特定できず、推奨事項がアクティブなままの場合は、次の手順を検討してください。

このドキュメントに問題の解決策が見当たらない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。
- Cloud カスタマーケアに問い合わせて、サポートケースを登録する。
- StackOverflow で質問する、google-kubernetes-engine タグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。#kubernetes-engine Slack チャンネルに参加して、コミュニティサポートを利用することもできます。
- 公開バグトラッカーを使用して、バグの報告や機能リクエストの登録を行う。