デフォルトでは、containerd 2.1 は Kubernetes 1.33 を実行する Container Service for Kubernetes(ACK)クラスタによって使用されます。 containerd 2.1 は、強化されたイメージセキュリティ、パフォーマンス、および安定性を提供します。 このトピックでは、機能の更新、非推奨の機能、および非推奨の API を含む、containerd 2.1 のリリースノートについて説明します。
機能
このセクションでは、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 パラメーターをカスタマイズする」をご参照ください。
application/vnd.docker.distribution.manifest.v1+jsonやapplication/vnd.docker.distribution.manifest.v1+prettyjwsなどのスキーマ 1 形式の Docker イメージは、サポートされなくなりました。 このようなイメージをプルするリクエストは拒否されます。 スキーマ 1 形式の Docker イメージを識別する方法の詳細については、「スキーマ 1 形式の Docker イメージを識別する」をご参照ください。io_uring_*システムコール(syscall)は、containerd のデフォルトの seccomp プロファイルから削除されました。 デフォルトでは、コンテナーはio_uring_*syscall を実行できません。CRI v1alpha2 API は非推奨です。 CRI v1alpha2 API は、Kubernetes 1.26 以降、非推奨になっています。
AUFS スナップショッターは非推奨です。
[plugins."io.containerd.internal.v1".tracing]パラメーターは削除されました。
アップグレードに関する注意事項
CRI v1alpha2 API は、container 2.1 ではサポートされなくなりました。 ビジネスでこの API に依存している場合は、CRI v1 API に移行できます。
containerd をアップグレードする前に、「非推奨の API を識別する」を参照して、ビジネスで非推奨の API が使用されているかどうかを確認することをお勧めします。 ACK コンソールで自動チェックを実行することもできます。 これを行うには、ACK コンソールのクラスタ詳細ページに移動し、左側のナビゲーションウィンドウで [操作] > [クラスタのアップグレード] を選択し、[事前チェック] をクリックします。
アップグレード中に、システムは非推奨の API を自動的にチェックします。 非推奨の API が検出されると、システムはアップグレードを一時停止します。
非推奨の API を識別する
kubectl を使用する
次のコマンドを実行して、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スキーマ 1 形式の Docker イメージを識別する
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 にロールバックすることはできません。 shim-v3 API は containerd V2.1 で導入されています。 shim-v3 API は、containerd 1.6 の shim-v2 API にロールバックできません。
containerd を V1.6 から V2.1 にアップグレードすると、データが失われますか?
「ノードプールを更新する」の手順に従って containerd をアップグレードすると、デフォルトではインプレースアップグレードが実行されます。 この場合、containerd 2.1 は元のデータディレクトリを使用するため、データの損失は発生しません。