すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:containerd 2.1

最終更新日:Mar 27, 2026

デフォルトで、Kubernetes 1.33 を実行する Container Service for Kubernetes (ACK) クラスターでは containerd 2.1 が使用されます。containerd 2.1 は、イメージのセキュリティ、パフォーマンス、および安定性を向上させます。本トピックでは、containerd 2.1 のリリースノートについて説明します。内容には、新機能、非推奨となった機能、および非推奨となった API が含まれます。

特徴

本セクションでは、containerd 2.1 の主な特徴のみを説明します。詳細については、「containerd のリリースノート」をご参照ください。
  • Node Resource Interface (NRI) 機能がサポートされています。この機能はデフォルトで有効です。

  • Container Device Interface (CDI) 機能がサポートされています。この機能はデフォルトで有効です。

  • Sandbox API がサポートされています。

非推奨となった機能および API

本セクションでは、containerd 2.1 で非推奨となった主な機能および API について説明します。詳細については、「containerd のリリースノート」をご参照ください。
  • 以下のパラメーターが非推奨となりました:`registry.auths`、`registry.configs`、および `registry.mirrors`。Container Service for Kubernetes (ACK) コンソールでノードプールの containerd パラメーターをカスタマイズする方法については、「ノードプールの containerd パラメーターのカスタマイズ」をご参照ください。

  • Docker Schema 1 イメージはサポートされなくなりました。マニフェストタイプが `application/vnd.docker.distribution.manifest.v1+json` または `application/vnd.docker.distribution.manifest.v1+prettyjws` のイメージに対するプルリクエストは拒否されます。これらのイメージを特定するには、「Docker Schema 1 イメージの特定」をご参照ください。

  • `io_uring_*` システムコール (syscall) が、containerd のデフォルト seccomp プロファイルから削除されました。デフォルトでは、コンテナは `io_uring_*` システムコールを実行できません。

  • CRI v1alpha2 API が非推奨となりました。CRI v1alpha2 API は Kubernetes 1.26 以降で非推奨となっています。

  • AUFS スナップショッターが非推奨となりました。

  • `[plugins."io.containerd.internal.v1".tracing]` パラメーターが削除されました。

アップグレードに関する注意事項

  • containerd 2.1 では CRI v1alpha2 API がサポートされません。業務でこの API に依存している場合は、CRI v1 API への移行を実施してください。

  • アップグレードを実行する前に、「非推奨 API の特定」に記載されている手順に従って、非推奨 API の有無を確認してください。また、コンソールから自動チェックも可能です。クラスターの詳細ページで、左側のナビゲーションウィンドウより 操作 > クラスターのアップグレード を選択し、事前チェック を実行します。

  • アップグレード中に、システムは非推奨 API の有無を自動的にチェックします。非推奨 API が検出された場合、アップグレードは一時停止されます。

非推奨 API の特定

kubectl を使用する方法

以下のコマンドを実行して、クラスター内の Pod に containerd 関連ディレクトリがマウントされているかを確認します:

まず、クラスターに kubectl および jq をインストールする必要があります。jq のインストールには、`yum install jq` コマンドを実行します。
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'

ctr を使用する方法

containerd が非推奨 API を使用している場合、`ctr deprecations list` コマンドを実行することで、非推奨 API の一覧を表示できます:

ctr deprecations list

Docker Schema 1 形式のイメージの特定

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

アップグレード方法

まず、「ACK クラスターの手動アップグレード」を参照し、クラスターのコントロールプレーンの Kubernetes バージョンを 1.33 以降にアップグレードしてください。その後、「ノードプールの更新」を参照して containerd をアップグレードしてください。

よくある質問

アップグレードは業務に影響を与えますか?

containerd のアップグレードには、「ノードプールの更新」をご参照ください。ノードプールのアップグレードによる containerd のアップグレードでは、デフォルトでインプレースアップグレードが実行されます。インプレースアップグレードではコンテナを再起動しないため、業務は通常通り継続して実行されます。

containerd を V1.6 から V2.1 にアップグレードした後、ロールバックは可能ですか?

いいえ、containerd を V2.1 から V1.6 へロールバックすることはできません。containerd V2.1 では shim-v3 API が導入されており、shim-v3 API は containerd 1.6 の shim-v2 API へロールバックできません。

containerd を V1.6 から V2.1 にアップグレードすると、データ損失は発生しますか?

ノードプールの更新」に記載された手順に従って containerd をアップグレードする場合、デフォルトでインプレースアップグレードが実行されます。この場合、containerd 2.1 は既存のデータディレクトリを使用するため、データ損失は発生しません。

参考情報