デフォルトで、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 listDocker 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 は既存のデータディレクトリを使用するため、データ損失は発生しません。