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

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

最終更新日:Dec 26, 2024

Container Service for Kubernetes (ACK) は、Certified Kubernetes Conformance Program の条件を厳守しています。このトピックでは、更新ノート、主な変更点、新機能、非推奨の機能と API、およびフィーチャーゲートなど、Kubernetes 1.30 の更新内容について説明します。

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

Kubernetes 1.30 をサポートするために、Alibaba Cloud Container Compute Service (ACS) によって以下の主要コンポーネントが更新および最適化されています。

主要コンポーネント

API バージョン

Kubernetes

1.30.1-aliyunacs.1

etcd

v3.5.9

containerd

1.6.28

CoreDNS

v1.9.3.10-7dfca203-aliyun

CSI

v1.30.1-98960d8-aliyun

CNI

Flannel v0.15.1.22-20a397e6-aliyun

Terway および TerwayControlplane 1.9.0 以後

説明

Kubernetes 1.30 以降、クラスターを作成し、ネットワークプラグインとして Terway を選択してネットワークポリシーのサポートを有効にすると、ネットワークポリシーの実装は Extended Berkeley Packet Filter (eBPF) に基づきます。クラスターとコンポーネントの更新によって、既存の動作は変更されません。詳細については、ACS クラスターでのネットワークポリシーの使用 を参照してください。

機能

Kubernetes 1.29

  • PreStop フックにスリープモードが追加されました。このモードでは、コンテナが終了する前に指定された時間一時停止できます。詳細については、KEP-3960: Introducing Sleep Action for PreStop Hook を参照してください。

  • SidecarContainers 機能がベータ版に達し、デフォルトで有効になっています。この機能を使用すると、restartPolicyAlways に設定することで、init コンテナをサイドカーコンテナとして実行できます。サイドカーコンテナは、メインアプリケーションコンテナや他の init コンテナに影響を与えることなく、独立して起動、停止、再起動できます。詳細については、サイドカーコンテナ を参照してください。

  • ClusterIP サービスの IP アドレス範囲を動的に指定するために、サービス CIDR がサポートされています。この機能はアルファ版に達しており、デフォルトでは無効になっています。サービスで使用可能な IP アドレス数を動的に増やす方法の詳細については、KEP-1880: Multiple Service CIDRs を参照してください。

  • 永続ボリュームクレーム (PVC) API とコンテナ API は、同じ ResourceRequirements 構造を使用してリソースの requestslimits を定義します。その結果、コンテナ API の resources 構造が変更された場合、たとえば、claims フィールドが追加された場合、PVC API のリソース構造も変更されます。この問題を防ぐために、PVC API は désormais 独立した VolumeResourceRequirements 構造を使用します。これは requestslimits のみで構成されます。この構造には claims は含まれません。詳細については、ボリュームリソース要件 を参照してください。

  • PodReadyToStartContainers 機能がベータ版に達し、デフォルトで有効になっています。この機能は、ポッドのサンドボックス化されたランタイム環境が作成され (ランタイム環境の準備が完了)、ネットワークが構成されていることを示します。これにより、kubelet はポッドのステータスを学習できます。詳細については、ポッドの条件 を参照してください。

  • ポッドアフィニティとポッドアンチアフィニティは、Deployment のローリングアップデート中にスケジューラーが古いポッドと新しいポッドを区別できないという問題を解決するために、matchLabelKeys と mismatchLabelKeys をサポートしています。この問題が発生すると、ポッドアフィニティまたはポッドアンチアフィニティルールに基づいてポッドのスケジュールが失敗します。ポッドアフィニティに matchLabelKeys を構成すると、Deployment は ReplicaSet に pod-template-hash ラベルを追加します。このようにして、Deployment の各ポッドは同じハッシュ文字列を持ちます。これにより、スケジューラーは同じ更新バッチ内のポッドを区別するために、同じ pod-template-hash 値を持つポッドを評価できます。詳細については、KEP-3633 を参照してください。

  • コア Kubernetes API リソースに加えて、ValidatingAdmissionPoliy タイプチェックは CustomResourceDefinitions (CRD) と API 拡張もサポートしています。これは、ポリシーの信頼性とクラスター構成の有効性を確保するのに役立ちます。詳細については、タイプチェック を参照してください。

  • UserNamespacesPodSecurityStandards フィーチャーゲートが追加され、ユーザー名前空間が Pod Security Standards をサポートできるようになりました。このフィーチャーゲートが有効になっている場合、ルート以外のユーザー ID またはポッドセキュリティコンテキストで指定されたユーザー ID でコンテナを実行できます。このフィーチャーゲートはアルファ版に達しており、デフォルトでは false に設定されています。このフィーチャーゲートは、後のバージョンでも false のままになる可能性があります。詳細については、KEP-127: Update PSS based on feature gate を参照してください。

  • ノードオブジェクトに DisableNodeKubeProxyVersion フィーチャーゲートが追加されました。status.nodeInfo.kubeProxyVersion フィールドは非推奨です。これは、Kubernetes のノードで kubeProxyVersion フィールドが無効になっていることを意味します。 kubelet は正しい kube-proxy バージョンを認識できない場合があります。したがって、このフィールドの値は不正確です。このフィーチャーゲートはアルファ版に達しており、デフォルトでは false に設定されています。

  • JobBackoffLimitPerIndex フィーチャーゲートがベータ版に達し、デフォルトで true に設定されています。このフィーチャーゲートを使用すると、インデックス付きジョブの各インデックスの再試行の最大試行回数を指定できます。インデックス付きジョブの詳細については、静的作業割り当てによる並列処理のためのインデックス付きジョブ を参照してください。

Kubernetes 1.30

  • ImageMaximumGCAge を使用すると、kubelet を使用して、ガベージコレクションの前に未使用イメージの最大 TTL を構成できます。 TTL が終了した後もイメージが使用されていない場合、イメージはガベージコレクションによって削除されます。デフォルト値は "0s" で、TTL が設定されていないことを意味します。このフィーチャーゲートは Kubernetes 1.29 でアルファ版に達し、Kubernetes 1.30 でベータ版に達しました。

  • イメージのプル時間を追跡するために、kubelet に image_pull_duration_seconds メトリックが追加されました。詳細については、アルファ版 Kubernetes メトリックのリスト を参照してください。

  • LegacyServiceAccountTokenCleanUp フィーチャーゲートが GA に達し、デフォルトで有効になっています。 ServiceAccount に関連付けられた自動生成されたシークレットが一定期間 (デフォルトでは 1 年) 以内に使用されず、どのポッドにもマウントされていない場合、kube-controller-manager はシークレットに kubernetes.io/legacy-token-invalid-since ラベルを追加します。シークレットは無効としてマークされます。ラベル値は現在の日付です。シークレットが無効としてマークされた日から、一定期間 (デフォルトでは 1 年) 以内にまだ使用されていない場合、kube-controller-manager はシークレットを自動的に削除します。このラベルが付いているが削除されていないシークレットについては、kubernetes.io/legacy-token-invalid-since ラベルを削除して、シークレットを再び有効にすることができます。詳細については、自動生成されたレガシー ServiceAccount トークンのクリーンアップ および レガシー ServiceAccount トークンクリーナー を参照してください。

  • Kubernetes 1.30 では、kube-proxy--nodeport-addresses が構成されていない場合 (このフラグはデフォルトでは構成されていません)、NodePort サービスの更新はすべてのノード IP アドレスを更新する代わりにプライマリノード IP アドレスのみを更新します。詳細については、#122724 を参照してください。

  • 構成の競合やセキュリティの問題を防ぐために、OIDC Issuer URL と API サーバー ServiceAccount Issuer URL は同じパラメーターで構成しないでください。詳細については、#123561 を参照してください。

  • LoadBalancerIPMode フィーチャーゲートを使用すると、LoadBalancer サービスに .status.loadBalancer.ingress.ipMode フィールドを追加して、指定されたロードバランサー IP アドレスに送信されたリクエストの転送アクションを指定できます。このフィールドは、.status.loadBalancer.ingress.ip フィールドが指定されている場合にのみ使用できます。 LoadBalancerIPMode フィーチャーゲートはベータ版に達しました。詳細については、ロードバランサーステータスの IPMode の指定 および サービスのロードバランサー IP モード を参照してください。

  • ContainerResource メトリックに基づく Horizontal Pod Autoscaler (HPA) は、Kubernetes 1.30 で Stable に達しました。これにより、HPA はポッドのリソース使用量に基づいてスケーリングする代わりに、ポッド内の各コンテナのリソース使用量に基づいて自動スケーリングを構成できます。このようにして、ポッド内の重要なコンテナに対して個別にスケーリングしきい値を構成できます。詳細については、コンテナリソースメトリック を参照してください。

  • AdmissionWebhookMatchConditions フィーチャーゲートが GA に達し、デフォルトで有効になっています。このフィーチャーゲートは無効にすることができません。このフィーチャーゲートを使用すると、アドミッション Webhook の一致条件を定義して、よりきめ細かい方法で Webhook をトリガーできます。詳細については、動的アドミッション制御 を参照してください。

  • JobSuccessPolicy フィーチャーゲートが追加され、ジョブに属するポッドのグループが成功したときにジョブが完了したと主張できるようになりました。ジョブが完了したと主張するために、特定のインデックス (ポッドインデックス X、Y、Z など) またはインデックスの数 (3 つのインデックスなど) を指定できます。このフィーチャーゲートはアルファ版に達しました。詳細については、ジョブの成功/完了ポリシー を参照してください。

  • RelaxedEnvironmentVariableValidation フィーチャーゲートが追加され、等号 (=) を除く、環境変数で使用されるほとんどの印刷可能な ASCII 文字 (32 から 126 までのすべての文字) を制御できるようになりました。このフィーチャーゲートはアルファ版に達しており、デフォルトでは無効になっています。詳細については、#123385 を参照してください。

  • CustomResourceFieldSelectors フィーチャーゲートが追加され、CRD に selectableFields を構成できるようになりました。このようにして、フィールドセレクター を使用して List、Watch、および DeleteCollection リクエストをフィルタリングして、特定の条件を満たす CRD を見つけたり管理したりできます。このフィーチャーゲートはアルファ版に達しており、デフォルトでは無効になっています。詳細については、カスタムリソースフィールドセレクター を参照してください。

  • CRDValidationRatcheting フィーチャーゲートの更新がリリースされました。新しい CRD 検証ラチェッティングが追加された後、既存のリソースが更新後に無効になる場合でも、検証に合格しなかったリソースが更新されない限り、API サーバー はリソースの更新をブロックしません。これにより、既存のリソースとユーザーへの影響を回避できます。このようにして、移行中に OpenAPI v3 スキーマ を介して CRD を検証できます。このフィーチャーゲートはベータ版に達しており、デフォルトで有効になっています。詳細については、CRD 検証ラチェッティング を参照してください。

  • Downward API は status.hostIPs フィールドを使用して IPv4/IPv6 デュアルスタックをサポートしています。status.hostIPs リストの最初の IP アドレスは常に status.hostIP と同じです。詳細については、Downward API を参照してください。

  • NodeLogQuery フィーチャーゲートを使用すると、/logs エンドポイントを使用してノードサービスログをクエリできます。このフィーチャーゲートはベータ版に達しており、デフォルトでは false に設定されています。詳細については、ログクエリ を参照してください。

非推奨の機能

Kubernetes 1.29

  • CronJobs は .spec.scheduleCRON_TZ または TZ 設定をサポートしなくなりました。.spec.timeZone フィールドが代わりに使用されます。このフィールドは Kubernetes 1.25 以降のバージョンで使用できます。詳細については、CronJob の制限 を参照してください。

  • アルファ版の networking/v1alpha1 API ClusterCIDR が削除されました。詳細については、Cluster CIDR V1alpha1 を参照してください。

Kubernetes 1.30

  • kubectl apply コマンドの --prune-whitelist パラメーターが削除されました。--prune-allowlist を使用することをお勧めします。詳細については、--prune を参照してください。

  • アドミッションプラグインは Kubernetes 1.27 で非推奨になり、Kubernetes 1.30 で削除されました。 PodSecurity アドミッションプラグインを使用することをお勧めします。このプラグインは Kubernetes 1.25 で Stable に達し、デフォルトで有効になっています。詳細については、PodSecurity を参照してください。

非推奨の API

flowcontrol.apiserver.k8s.io/v1beta2 API バージョンの FlowSchema と PriorityLevelConfiguration は Kubernetes 1.29 で非推奨になりました。 flowcontrol.apiserver.k8s.io/v1 API (Kubernetes 1.29 以降のバージョンで使用可能) または flowcontrol.apiserver.k8s.io/v1beta3 API (Kubernetes 1.26 以降のバージョンで使用可能) を使用することをお勧めします。

  • flowcontrol.apiserver.k8s.io/v1 の主な変更点:

    PriorityLevelConfiguration の spec.limited.assuredConcurrencyShares フィールドの名前が spec.limited.nominalConcurrencyShares に変更されました。デフォルト値は 30 で、明示的な値 0 は 30 に変更できません。

  • flowcontrol.apiserver.k8s.io/v1beta3 の主な変更点:

    PriorityLevelConfiguration の spec.limited.assuredConcurrencyShares フィールドの名前が spec.limited.nominalConcurrencyShares に変更されました。

フィーチャーゲート

Kubernetes でサポートされているフィーチャーゲート、フィーチャーゲートのバージョン、および機能の詳細については、フィーチャーゲート を参照してください。

フィーチャーゲートには次のステージがあります。

  • アルファ: デフォルトでは、機能は無効になっています。

  • ベータ: デフォルトでは、機能は有効になっています。

  • GA: デフォルトでは、機能は有効になっており、無効にすることはできません。対応するフィーチャーゲートウェイはもはや必要ありません。

参考資料

Kubernetes 1.29 および 1.30 のリリースノートの詳細については、CHANGELOG-1.29 および CHANGELOG-1.30 を参照してください。