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

Container Service for Kubernetes:ACK Kubernetes 1.33 リリースノート

最終更新日:Dec 09, 2025

Alibaba Cloud の Container Service for Kubernetes (ACK) は、コミュニティの適合性認定に完全に準拠しています。このトピックでは、ACK の Kubernetes 1.33 リリースにおける主な変更点について説明します。これには、アップグレード時の考慮事項、主な変更点、新機能、非推奨の機能と API が含まれます。

コンポーネントのバージョン

次の表に、ACK クラスターのコアコンポーネントのバージョンを示します。

コアコンポーネント

バージョン番号

Kubernetes

1.33.1-aliyun.1 および 1.33.3-aliyun.1

etcd

v3.5.21

containerd

2.1.1

CoreDNS

v1.11.3.5-5321daf49-aliyun

CSI

CNI

Flannel v0.15.1.22-20a397e6-aliyun

Terway および TerwayControlplane v1.14.0 以降

アップグレード時の考慮事項

ご利用のクラスターに Kubernetes 1.20 以前で作成され、コンテナが一度も再起動または更新されていない Pod が含まれている場合、クラスターを Kubernetes 1.33 にアップグレードすると、それらの Pod は再起動されます。

主な変更点

機能の変更点

  • Pod のインプレースリサイズ機能がベータ版に昇格し、デフォルトで有効になりました。この機能により、Pod を再起動することなく、コンテナの CPU およびメモリリソース構成を動的に変更できます。

  • kubectl は、--subresources コマンドを使用して特定のサブリソースを調整することをサポートします。例えば、kubectl edit pod <pod-name> --subresource resize を実行することで、Pod のリソースサイズを動的に調整できます。Kubernetes 1.33 でサポートされているサブリソースには、statusscaleresize があります。

  • EndpointSlice の TopologyAwareHints が一般提供 (GA) に昇格しました。ベータ版のアノテーション service.kubernetes.io/topology-mode は非推奨になりました。代わりに spec.trafficDistribution フィールドを使用してトポロジーポリシーを定義します。例えば、trafficDistributionPreferClose に設定すると、クライアントと同じゾーンにあるエンドポイントにトラフィックをルーティングできます。詳細については、「トラフィック分散」をご参照ください。

  • Pod の .status.resize フィールドは非推奨となり、設定できなくなりました。代わりに、PodResizeInProgressPodResizePending という 2 つの新しい条件フィールドが追加されました。

  • DisableNodeKubeProxyVersion はデフォルトで有効になり、無効にすることはできません。kubelet はノードの status.kubeProxyVersion フィールドを設定しなくなりました。

  • StatefulSet の .spec.serviceName フィールドがオプションになりました。このフィールドの検証が強化され、DNS-1123 標準に準拠することが保証されます。既存の StatefulSet の .spec.serviceName フィールドが検証に失敗した場合、手動でフィールドを削除するまで新しい Pod を作成できません。この更新により、DNS 検証が Pod 作成フェーズから StatefulSet リソース構成フェーズに移動します。これにより、StatefulSet コントローラーによる失敗した再試行が削減されます。

  • Git-Repo ボリュームプラグインはデフォルトで無効になっています。このプラグインを使用するには、GitRepoVolumeDriver フィーチャーゲートを手動で有効にする必要があります。

  • バージョン 1.33.3-aliyun.1 では、脆弱性 CVE-2025-4563 が修正されています。

機能

  • サイドカーコンテナが一般提供 (GA) に昇格し、デフォルトで有効になりました。サイドカーコンテナは特殊な種類の init コンテナです。restartPolicy: Always を使用して、Pod のライフサイクル全体で実行されることを保証できます。また、プローブ設定もサポートしています。

  • OrderedNamespaceDeletion がベータ版に昇格しました。この機能は、名前空間のリソース解放プロセスを最適化します。名前空間が削除されると、まずワークロード Pod が削除され、次に NetworkPolicy やストレージリソースなどの依存関係が削除されます。これにより、重要なセキュリティリソースが削除された後に Pod が残ってしまうのを防ぎます。

  • SupplementalGroupsPolicy がベータ版に昇格し、デフォルトで有効になりました。.spec.securityContext.supplementalGroupsPolicy フィールドを通じて Pod の補助グループを詳細に制御できます。これにより、永続ボリュームへのアクセス権限をより正確に制御できます。詳細については、「Pod の補助グループの詳細な制御を設定する」をご参照ください。

  • MultiCIDRServiceAllocator が一般提供 (GA) に昇格し、デフォルトで有効になりました。ServiceCIDR と IPAddress リソースを導入して、サービスの ClusterIP 割り当てを記録します。また、ServiceCIDR を通じて ClusterIP の割り当て可能な範囲を動的に拡張することもサポートしています。

  • JobBackoffLimitPerIndex が一般提供 (GA) に昇格しました。インデックス付きジョブの各インデックスに対して、Pod の最大再試行回数を指定できます。

  • JobSuccessPolicy が一般提供 (GA) に昇格しました。ジョブのカスタム成功ポリシーを定義できます。例えば、成功したインデックスと成功したインデックスの数に基づいてジョブの完了を判断できます。詳細については、「Job の SuccessPolicy が GA に」をご参照ください。

  • ImageVolume がベータ版に昇格しましたが、デフォルトでは無効です。apiserver と kubelet でフィーチャーゲートを手動で有効にする必要があります。これにより、Pod で image ボリュームソースを使用して、コンテナイメージを読み取り専用ボリュームとしてマウントできます。

  • UserNamespacesSupport がベータ版に昇格し、デフォルトで有効になりました。Pod が Linux ユーザー名前空間を使用してコンテナのセキュリティを向上させることができます。この機能は既存の Pod には影響しません。この機能を使用するには、pod.spec.hostUsers を手動で指定する必要があります。詳細については、「ユーザー名前空間がデフォルトで有効に」をご参照ください。

  • RelaxedDNSSearchValidation がベータ版に昇格し、デフォルトで有効になりました。Pod の .spec.dnsConfig.searches フィールドで ._ などの特殊文字を使用できるようになります。これにより、DNS 構成の柔軟性が向上します。

  • kube-apiserver は、デフォルトで WatchList メカニズムを無効にします。代わりに、StreamingCollectionEncodingToJSON や StreamingCollectionEncodingToProtobuf などのストリーミングエンコーディングメカニズムを使用します。この変更により、大規模なリソースリストリクエストに対して応答をストリーミングすることで、リスト操作のパフォーマンスが向上します。多くのリソースを含むリストリクエストの場合、これによりメモリ使用量が大幅に削減され、システムの安定性が向上します。詳細については、「リスト応答のストリーミング」をご参照ください。

    kube-controller-manager は、WatchListClient 機能を積極的に有効にしなくなりました。

  • CPUManagerPolicyOptions が一般提供 (GA) に昇格し、デフォルトで有効になりました。CPU マネージャーのリソース割り当てポリシーを詳細に調整できます。

  • MatchLabelKeysInPodAffinity が一般提供 (GA) に昇格し、デフォルトで有効になりました。Pod アフィニティルールに matchLabelKeysmismatchLabelKeys を追加して、Pod のコロケーションをより正確に制御できます。

  • NodeInclusionPolicyInPodTopologySpread が一般提供 (GA) に昇格し、デフォルトで有効になりました。Pod トポロジースプレッド制約nodeAffinityPolicynodeTaintsPolicy を使用して、スケジューリング可能なノードを動的にフィルタリングできます。

    • nodeAffinityPolicy:デフォルト値は Honor です。Pod の nodeSelector または nodeAffinity に一致するノードのみがトポロジースプレッド計算に含まれます。

    • nodeTaintsPolicy:デフォルト値は Ignore です。nodeAffinitynodeSelector ルールは無視され、すべてのノードがトポロジースプレッド計算に含まれます。

  • HonorPVReclaimPolicy が一般提供 (GA) に昇格し、デフォルトで有効になりました。PV の reclaimPolicyDelete に設定されている場合、PV または PVC の削除順序に関係なく、基盤となるストレージリソースがポリシーに従って削除されることを保証します。これにより、ストレージリソースのリークを防ぎます。

  • ProcMountType がベータ版に昇格しました。Pod の securityContext.procMount フィールドを使用して、コンテナ内の /proc ファイルシステムのマウントタイプをカスタマイズできます。これにより、/proc ファイルシステムへのアクセスを詳細に制御し、Pod のセキュリティと分離を向上させます。この機能は、ユーザー名前空間で非特権コンテナを実行する必要があるシナリオで役立ちます。/proc に対する制限を緩和することで、互換性と柔軟性が向上します。

  • PodLifecycleSleepActionAllowZero がベータ版に昇格しました。preStop コンテナライフサイクルコールバックで、sleep 操作の待機時間を 0 に設定できます。

  • ResourceQuota を使用して、特定の Volume Attributes Class に関連付けられた PVC の数を制限できます。

  • スケジューラのパフォーマンス最適化:

    • SchedulerPopFromBackoffQ 機能が追加され、デフォルトで有効になりました。activeQ が空の場合に backoffQ から直接 Pod をポップできるようにすることで、スケジューリングキューの処理ロジックを最適化します。これにより、Pod スケジューリングのレイテンシが大幅に削減されます。

    • SchedulerAsyncPreemption がベータ版に昇格し、デフォルトで有効になりました。プリエンプティブスケジューリングを非同期実行に変換できます。プリエンプションはコストのかかる操作です。この操作を非同期にすることで、スケジューリングのレイテンシを効果的に削減できます。

    • トポロジースプレッド制約を使用する Pod のスケジューリングパフォーマンスが最適化されました。

非推奨の API

  • Kubernetes 1.33 はデフォルトで containerd 2.1 を使用します。containerd 2.1 は CRI v1alpha2 API をサポートしなくなりました。この API バージョンに依存している場合は、互換性を確保するために CRI v1 API に移行する必要があります。

  • v1 Endpoints API は正式に非推奨になりました。代わりに EndpointSlice API を使用してください。EndpointSlice API は Kubernetes 1.21 以降安定しており、デュアルスタックネットワークのサポートなどの機能が導入されています。ただし、v1 Endpoints API は現時点では削除されません。詳細については、「Endpoints から EndpointSlices への移行の継続」をご参照ください。

  • apidiscovery.k8s.io/v2beta1 API グループは無効になりました。クライアントはこの API を使用して、クラスターに登録されているすべての API リソースに関する情報をクエリします。安定版の v2 バージョンに移行する必要があります。古いクライアントは、フォールバックメカニズムを使用して、集約されていない v1 API を自動的にサービスディスカバリに使用できるため、クライアントはすぐにはエラーを報告しません。ただし、クライアントが v2 バージョン用に更新されていない場合、完全な非集約データを取得するために複数の API 呼び出しを行う必要があります。これにより、リクエスト数とレイテンシが増加する可能性があります。

関連ドキュメント

Kubernetes 1.33 の完全な変更履歴については、「CHANGELOG-1.33」および「Kubernetes v1.33: Octarine」をご参照ください。