Container Compute Service:Kubernetes 1.33 リリースノート

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

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

重要な注意事項

ACK の製品最適化により、バージョン 1.33.3-aliyun.1 以降のクラスターを作成する際は、必要な サービスリンクロール を Container Service for Kubernetes (ACK) に付与する必要があります。

破壊的変更

NAS の永続ボリューム要求を作成する際、割り当てモード は マウントターゲットのドメイン名を使用 をサポートしなくなりました。代わりに、既存ボリューム または ボリュームの作成 を選択できるようになりました。

機能の変更

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

• kubectl は、特定のサブリソースを変更するための --subresources フラグをサポートするようになりました。たとえば、kubectl edit pod <pod-name> --subresource resize を使用して、Pod のリソースを動的にリサイズできます。バージョン 1.33 でサポートされるサブリソースは、status、scale、resize です。

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

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

• StatefulSet の .spec.serviceName フィールドはオプションになりました。このフィールドの検証はより厳格になり、DNS-1123 標準に準拠する必要があります。既存の StatefulSet にこの検証に失敗する .spec.serviceName がある場合、フィールドを手動で削除するまで新しい Pod は作成できません。この更新により、DNS 検証が Pod 作成ステージから StatefulSet 設定ステージに移動し、StatefulSet コントローラーによる失敗した再試行が削減されます。

• Git-Repo ボリュームプラグインはデフォルトで無効になっています。引き続き使用するには、GitRepoVolumeDriver フィーチャーゲートを有効にしてください。

• バージョン 1.33.3-aliyun.1 には、CVE-2024-4563 の修正が含まれています。

新機能

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

• OrderedNamespaceDeletion がベータ版に昇格しました。この機能は、名前空間のリソースクリーンアッププロセスを最適化します。名前空間が削除されると、まずワークロード Pod が終了し、その後に NetworkPolicies やストレージリソースなどの依存リソースが削除されます。これにより、重要なセキュリティリソースが削除された後も Pod がアクティブなままになることを防ぎます。

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

• MultiCIDRServiceAllocator が一般提供 (GA) に昇格し、デフォルトで有効になりました。この機能では、ServiceCIDR および IPAddress リソースを導入して、サービスの ClusterIP 割り当てを追跡します。また、ServiceCIDR を使用して割り当て可能な ClusterIP 範囲を動的に拡張できます。

• JobBackoffLimitPerIndex が一般提供 (GA) に昇格しました。この機能により、インデックス付き Job の各インデックスに対して Pod の最大リトライ回数を指定できます。

• JobSuccessPolicy が一般提供 (GA) に昇格しました。これにより、特定のインデックスの成功状況や成功したインデックスの合計数に基づいて Job の完了を判定するなど、Job のカスタム成功ポリシーを定義できます。詳細については、「Job's SuccessPolicy Goes GA」をご参照ください。

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

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

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

• kube-apiserver は、WatchList メカニズムをデフォルトで無効にし、代わりにストリーミングエンコーディングメカニズム (StreamingCollectionEncodingToJSON および StreamingCollectionEncodingToProtobuf を含む) を使用するようになりました。これにより、大規模なリソース一覧リクエストをストリーミング処理することで List 操作のパフォーマンスが向上します。多数のリソースを含む List リクエストでは、この変更によりメモリ消費を大幅に削減し、システムの安定性を向上できます。詳細については、「Streaming List responses」をご参照ください。

  kube-controller-manager は、WatchListClient フィーチャーをデフォルトで有効にしなくなりました。

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

  • Pod が排他 CPU を必要とする場合、割り当てられた CPU が完全な物理コアを占有するように SMT アラインメントが強制されます。詳細については、「cpu manager extension to reject non SMT-aligned workload」をご参照ください。

  • NUMA ノード間で CPU を割り当てる必要がある場合、CPU リソースが NUMA ノード間で均等に分散されるようにできます。詳細については、「Add CPUManager policy option to distribute CPUs across NUMA nodes instead of packing them」をご参照ください。

• MatchLabelKeysInPodAffinity が GA に昇格し、デフォルトで有効になります。これにより、Pod アフィニティルールに matchLabelKeys および mismatchLabelKeys フィールドが追加され、Pod のコロケーションをより詳細に制御できます。

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

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

  • nodeTaintsPolicy: デフォルトは Ignore です。 Pod の nodeAffinity および nodeSelector ルールに関係なく、すべてのノードがトポロジースプレッド計算に含まれます。

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

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

• PodLifecycleSleepActionAllowZero がベータ版に昇格しました。これにより、コンテナの preStop ライフサイクルフックにおける sleep アクションの待機時間を 0 に設定できるようになります。

• ResourceQuota を使用して、特定の Volume Attributes Class に関連付けられた永続ボリュームクレームの数を制限できるようになりました。

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

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

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

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

非推奨 API

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

• v1 Endpoints API は正式に非推奨になりました。代わりに EndpointSlice API の使用を推奨します。EndpointSlice API はバージョン 1.21 以降で安定版となっており、デュアルスタックネットワークのサポートなどの機能を導入しています。ただし、現時点では v1 Endpoints API は削除されません。詳細については、「Continuing the transition from Endpoints to EndpointSlices」をご参照ください。

• apidiscovery.k8s.io/v2beta1 API グループは無効になりました。この API は、クライアントがクラスター内の登録済み API リソースをすべて検出するために使用されます。v2 の安定版への移行を推奨します。古いクライアントは、サービス検出に unaggregated v1 API を使用するよう自動的にフォールバックできるため、直ちに失敗することはありません。ただし、v2 バージョンをサポートしないクライアントは、完全な unaggregated データを取得するために複数回の API 呼び出しが必要となり、リクエスト数とレイテンシーが増加する可能性があります。

関連ドキュメント

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