💻

Kubernetes 1.34: SIG Appsの変更内容

に公開

Kubernetes v1.34がリリースされました🎉

本記事では、とくにSIG Appsに関係する変更点を、CHANGELOGからピックアップして紹介いたします。

📝がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。

直近の変更点は以下になります。

他の各SIGについては、Kubernetes 1.34: 変更点まとめリンク集に各記事へのリンクが載っています。
ぜひご覧ください!

📝 所感

今回のリリーステーマは「Of Wind & Will (O' WaW)」ということですが、なぜロゴが熊なのでしょうか…?わたし、気になります。もし由来についてご存知の方がいたら、こっそり教えてください。

SIG Apps的に大きなニュースといえば、KEP-3939として進められていたJobPodReplacementPolicyのGAですね!
JobPodReplacementPolicyは、JobのPodの再作成タイミングを制御できる機能です。本機能が入る前は、JobはTerminating(deletion timestampがPodにセットされている)かFailed(status.phase=Failed)時に、すぐに代わりのPodを生成していました。本機能により、.spec.podReplacementPolicy=Failedを指定することで、PodがFailedになった時に初めて、代わりのPodが作成されるようになります。詳細については、Kubernetes 1.28: SIG-Apps の変更内容で解説されているので、ぜひご覧ください。また、Kubernetes公式ブログに紹介記事が出ているので、そちらもぜひご覧ください。

個人的に気になった変更はこちら
  • MutatingAdmissionPolicyは、Mutating Webhookの代替を目指した機能で、CEL(Common Expression Language)を使って動的にマニフェストを書き換えることができる機能です。サイドカーの注入といった操作を、より信頼性の高い形で入れることができるようになります。ただ、引き続きデフォルトでは無効なので、MutatingAdmissionPolicyフィーチャーゲートと--runtime-config=admissionregistration.k8s.io/v1beta1=trueフラグをkube-apiserverに設定する必要があります。

  • KubeletServiceAccountTokenForCredentialProvidersは、KEP-4412として進められていた機能で、誤解を恐れずに言うと、Projected Service Account tokenを使ってprivate imageをpullできるようになる仕組みです。この機能により、セキュリティリスクを低減しながら、安全にイメージを取得することができます。

  • ExternalServiceAccountTokenSignerがBetaに昇格し、デフォルトで有効となりました。この機能は、KEP-740として進められています。この機能により、Projected Service Account tokenの署名や検証キーの管理に、KMSといった外部署名者が使えるようになります。ExternalJWTSigner gRPC APIを実装したプロバイダーに対して、kube-apiserverからUNIXドメインソケット経由でリクエストが飛ぶような形です。kube-apiserverに--service-account-signing-endpointフラグを設定する必要があります。

  • ドキュメントには載っていませんが、KEP-5311として進められていたRelaxedServiceNameValidationという機能がアルファ版として入っています。今までServiceリソースの名前は、RFC 1035に準拠、すなわち、常に小文字の英字で始める必要がありました。そのため、数字から始まる名前は指定することができませんでした。しかし、他の多くのAPIオブジェクトは、もう少し制約の緩いRFC 1123に準拠しており、数字から始まる名前についても許容しています。RelaxedServiceNameValidationフィーチャーゲートを有効にすると、他のAPIオブジェクトと同様に、RFC 1123に準拠するようになるため、Serviceリソースの名前にも、数字から始まる名前が使用できるようになります。

フィーチャーゲートから見るv1.34

フィーチャーゲートとは、特定の機能の有効・無効を管理するための仕組みです。詳しくは、Kubernetes公式ドキュメントをご参照ください。

このセクションでは、SIG Appsに関連するフィーチャーゲートを、Kubernetes公式ドキュメントの説明の日本語訳と一緒に追っていきます。

アルファとして追加された新規機能

v1.34でアルファ版として追加された機能には、SIG Appsが主管するものはありませんでした。

以下は、SIG Appsが関係する機能です。それぞれの文頭には、対応するフィーチャーゲート名を記載しています。

  • 📝 以下の2つは、KEP-5278として進められていた機能の一部です。リリースブログにわかりやすい説明が載っているので、ぜひそちらをご覧ください。また、本変更は、SIG Scheduling編で解説されています。
    • NominatedNodeNameForExpectation: 有効にすると、kube-schedulerはPodがバインドされる場所を表現するために.status.nominatedNodeNameを使用します。
      外部コンポーネントも、推奨される配置を提供するためにPodの.status.nominatedNodeNameに書き込むことができます。
    • ClearingNominatedNodeNameAfterBinding: Podがノードにバインドされるたびに.status.nominatedNodeNameをクリアできるようにします。
  • ContainerRestartRules: コンテナレベルでの再起動ポリシーと再起動ルールを設定する機能を有効にします。詳細についてはContainer Restart Policy and Rulesを参照してください。
    • 📝 SIG Node編で解説されています。
    • 📝 KEP-5307として進められている機能です。restartPolicyがコンテナ単位で指定できるようになりました。また、restartPolicyRulesが追加され、終了ステータスを再起動の条件として設定できるようになりました。以下に例を示します。
apiVersion: v1
kind: Pod
metadata:
  name: per-container-restart-sample
spec:
  # Pod全体のrestartPolicy
  # これはapp containersやinit containersのデフォルト動作の基準になります
  restartPolicy: Never

  initContainers:
    - name: init-only-once
      image: busybox:1.28
      command: ["sh", "-c", "echo Init once; sleep 5; exit 1"]
      # このinit containerは一度だけ実行し、失敗したらPodをFailedの状態にしたい
      restartPolicy: Never

  containers:
    - name: app-container
      image: busybox:1.28
      command: ["sh", "-c", "echo Running app; sleep 30; exit 42"]
      # このコンテナは、基本的には再起動させない
      restartPolicy: Never
      restartPolicyRules:
        - action: Restart
          exitCodes:
            operator: In
            values: [42]
        # exit codeが42だった場合にのみ、再起動させたい。

    - name: always-restart-side
      image: busybox:1.28
      command: ["sh", "-c", "echo Always side; sleep 30; exit 1"]
      # このコンテナは常に再起動したい
      restartPolicy: Always
  • EnvFiles: ファイルを通じてコンテナの環境変数値を定義することをサポートします。詳細についてはDefine Environment Variable Values Using An Init Containerを参照してください。
    • 📝 SIG Node編で解説されています。
    • 📝 KEP-3721として進められている機能です。マウントされたVolume内にあるEnvファイル経由で、環境変数の読み込みができるようになります。Envファイルのフォーマットは、.envファイルとほぼ同等です。本機能により、例えば、以下の例のように、initContainerで動的に環境変数を定義し、メインのコンテナから使用することができるようになります。Kubernetes公式ブログの紹介記事が出ているので、そちらも併せてご覧ください。

以下は、Kubernetes公式ドキュメントに掲載されているサンプルマニフェストです。

apiVersion: v1
kind: Pod
metadata:
  name: envfile-test-pod
spec:
  initContainers:
    - name: setup-envfile
      image:  nginx
      command: ['sh', '-c', 'echo "DB_ADDRESS=address\nREST_ENDPOINT=endpoint" > /data/config.env']
      volumeMounts:
        - name: config
          mountPath: /data
  containers:
    - name: use-envfile
      image: nginx
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: DB_ADDRESS
          valueFrom:
            fileKeyRef:
              path: config.env
              volumeName: config
              key: DB_ADDRESS
              optional: false
  restartPolicy: Never
  volumes:
    - name: config
      emptyDir: {}
  • HostnameOverride: Podのホスト名として任意のFQDNを設定できるようにします。
    • 📝 SIG Network編で解説されています。
    • 📝 KEP-4762として進められていた機能です。このフィーチャーゲートを有効にすると、Podに.spec.hostnameOverrideというフィールドが設定可能となります。このフィールドに設定した値が、Podのホスト名として使用されます。ただし、.spec.hostnameOverrideにセットした値は、あくまで Pod内のhostnameにのみ 使用されます。クラスタDNSのAレコード/AAAAレコードには影響しません。詳細については、公式ドキュメントをご覧ください。
  • PodCertificateRequest: PodCertificateRequestオブジェクトとpodCertificate projected volumeソースを有効にします。
    • SIG Auth編に詳しい説明があります。
    • 📝 KEP-4317として進められていた機能です。リリースブログでも言及されているので、ぜひそちらもご覧ください。

フィーチャー昇格

v1.34で動きがあった機能のうち、SIG Appsに関係するものを記載しています。それぞれの文頭には、対応するフィーチャーゲート名を記載しています。

Beta

Betaに昇格した機能のうち、SIG Appsが主管するものはありませんでした。以下は、SIG Appsが関係する機能です。それぞれの文頭には、対応するフィーチャーゲート名を記載しています。

以下に記載のあるフィーチャーゲートは、全てデフォルトで 有効 です。

  • 📝 以下の2つは、KEP-3695として進められています。
  • KubeletServiceAccountTokenForCredentialProviders: kubeletが、イメージが取得されるPodにバインドされたサービスアカウントトークンを認証プロバイダプラグインに送信できるようにします。
    • 📝 KEP-4412として進められていた変更です。
  • MatchLabelKeysInPodTopologySpreadSelectorMerge: matchLabelKeysから構築されたセレクターを
    Podトポロジー分散制約labelSelectorにマージすることを有効にします。
    このフィーチャーゲートはMatchLabelKeysInPodTopologySpreadフィーチャーフラグでmatchLabelKeys機能が有効な場合に有効にできます。
  • PodLevelResources: Podレベルリソース を有効にします。特定のコンテナに対してのみではなく、Podレベルでリソース要求と制限を指定する機能です。
    • 📝 KEP-2837で進められていた変更です。Podの.spec.resourcesフィールドで、Pod全体のリソース要求や制限を設定することができます。今までは、各コンテナごとにリソース要求と制限を設定する必要があり、Pod全体のリソース消費量の管理が少々面倒だったと思います。本機能により、Pod全体でリソース要求・制限を設定することができるようになるので、より直感的にリソースの管理ができるようになります。
  • PodObservedGenerationTracking: kubeletがPodの.status内でobservedGenerationを設定することを有効にし、他のコンポーネントがPodの状態でobservedGenerationを設定することも有効にします。
    この機能により、全体的なステータスまたは特定の状態が記録された時点でのPodの.metadata.generationを反映できるようになります。
    これを保存することで、_失われた更新_に関連するリスクを回避できます。
    • 📝 KEP-5067で進められていた変更です。

GA

GAの機能については、リリースブログにわかりやすい説明が載っています。ぜひそちらをご覧ください。

  • JobPodReplacementPolicy: Jobで終了中のPodに対してPod置換を指定できるようにします。
  • OrderedNamespaceDeletion: ネームスペースを削除する際、Podリソースが他のリソースより先に削除されるようになります。
  • PodLifecycleSleepAction: コンテナライフサイクルフックでsleepアクションを有効にします。
  • PodLifecycleSleepActionAllowZero: コンテナライフサイクルフックのsleepアクションでゼロ値の設定を有効にします。
  • RelaxedEnvironmentVariableValidation: 環境変数でほぼすべての印刷可能なASCII文字を許可します。
  • VolumeAttributesClass: VolumeAttributesClassesのサポートを有効にします。詳細についてはVolume Attributes Classesを参照してください。

⚠️ Urgent Upgrade Notes

📝 SIG Appsに関連するものはありません

🗑️ Deprecation (非推奨になった機能)

📝 SIG Appsに関連するものはありません

🌏 API Changes (API周りの変更)

  • in-place pod vertical scalingが完了した際の詳細なイベントを追加し、クラスター管理とデバッグを改善しました。 (#130387, @shiya0705)
    • 📝 Podのリサイズが完了した際に、ResizeCompletedというイベントが記録されるようになりました。これにより、正しくリサイズが完了したかどうかをイベントログ経由で確認できるようになります。
  • コンテナの再起動を構成可能にするメカニズムである コンテナレベル再起動ルール を追加しました。これはContainerRestartRulesフィーチャーゲートの背後にあるアルファ機能でした。 (#132642, @yuanwang04)
  • コンテナに新しいFileKeyRefフィールドを追加し、このフィールドを設定することでファイルから変数を読み込むことができるようになりました。
    この機能の有効化を制御するためのEnvFilesフィーチャーゲートを導入しました。 (#132626, @HirazawaUi)
  • ResourceSliceにドライバー所有のフィールドを追加し、デバイスが複数のリソースクレーム(または要求)間で共有可能かどうかを示し、各容量を異なる要求間でどのように共有できるかを指定するようにしました。
    • ResourceClaimにユーザー所有のフィールドを追加し、各デバイス容量に対するリソース要求を指定するようにしました。
    • ResourceClaim.Statusにスケジューラー所有のフィールドを追加し、特定の要求用にどれだけのデバイス容量が予約されているかを指定するようにしました。
    • 複数の割り当てをサポートするデバイス用にResourceClaim.Statusに追加の識別子を追加しました。
    • 割り当てられたすべてのデバイス間で指定された属性の一意性を強制するための新しい制約タイプを追加しました。 (#132522, @sunya-ch)
      • 📝 DRA関連の変更です
  • ResouceSlice.BasicResourceClaim.Status.AllocatedDeviceStatusに新しいオプションAPIを追加しました。 (#130160, @KobayashiD27)
    • 📝 DRA関連の変更です
  • Dynamic Resource Allocation(DRA)を介して割り当てられたデバイスの健全性をKubeletが監視し、pod.status.containerStatuses.allocatedResourcesStatusフィールドで報告するサポートを追加しました。これにはDRAプラグインが新しいv1alpha1 NodeHealth gRPCサービスを実装する必要がありました。この機能はResourceHealthStatusフィーチャーゲートによって制御されました。 (#130606, @Jpsassine)
    • 📝 DRA関連の変更です
  • サポートの不足により、PodLevelResources機能をWindows OSで使用するPodを拒否するバリデーションを追加しました。APIサーバーは、Pod レベルリソースを持ちPod.spec.os.nameがWindowsを対象とするPodを拒否しました。WindowsノードのKubeletも、アドミッション段階でPodレベルリソースを持つPodを拒否しました。 (#133046, @toVersus)
  • pvc.spec.VolumeAttributesClassNameをnon-nilからnilへ変更することを許可しました。 (#132106, @AndrewSirenko)
  • PodSpechostnameOverrideフィールドをRFC 1123 DNS サブドメインとしてPodのホスト名に指定できるように設定を許可しました。この機能の有効化を制御するためにHostnameOverrideフィーチャーゲートを導入しました。 (#132558, @HirazawaUi)
  • hugepageリソースを指定していないコンテナにPodレベルのhugepage cgroupを伝播するよう基盤となるロジックを変更しました。
    コンテナのhugepage制限値の合計がPodレベルの制限値以下であることを強制するバリデーションを追加しました。これは指定された制限値からデフォルト化された要求でもすでに強制されていましたが、hugepageの要求と制限の両方について明確にしませんでした。 (#131089, @KevinTMtz)
  • DRA: 要求で優先順位付きリスト機能が使用され、結果として割り当てられたデバイス数がクレームあたりの許可デバイス数を超えた場合、スケジューラーはデバイスの割り当て試行を早期に中止しました。以前は、多くの異なる組み合わせを試行しており、時間がかかることがありました。 (#130593, @mortent)
    • 📝 DRA関連の変更です
  • Dynamic Resource Allocation: コア機能を一般利用可能(GA)に昇格させました。この新しく安定した機能は、DRAの 構造化パラメータ フレーバーを使用します。 (#132706, @pohly)
    • 📝 DRA関連の変更です
  • PodCertificateRequestPodCertificateプロジェクトボリュームのkube-apiserverサポートを有効化しました(PodCertificateRequestフィーチャーゲートの背後)。 (#128010, @ahmedtd)
  • DRAでバックアップされた拡張リソース機能により、クラスターオペレータがDeviceClassextendedResourceNameを指定し、アプリケーションオペレータがPodの要求で拡張リソースを使い続けてDeviceClassにマッチするDRAデバイスを要求できるようになりました。
    NodeResourcesFitプラグインのスコアリングは、DRAでバックアップされた拡張リソースでは動作しませんでした。 (#130653, @yliaog)
    • 📝 DRA関連の変更です
  • Kube-log-runner: ログ出力が特定のサイズに達したら新しいファイルにローテートするための-log-file-sizeパラメータを追加しました。古い出力ファイルの自動削除を有効にするための-log-file-age、および定期的なフラッシュをサポートする-flush-intervalを導入しました。 (#127667, @zylxjtu)
  • Job Pod Replacement Policyを一般利用可能に昇格させました。JobPodReplacementPolicyフィーチャーゲートはtrueにロックされ、将来のKubernetesリリースで削除される予定です。 (#132173, @dejanzele)
  • フィーチャーゲートVolumeAttributesClassをGAに昇格させました
  • API VolumeAttributesClassVolumeAttributesClassListstorage.k8s.io/v1に昇格させました。 (#131549, @carlory)
  • RelaxedEnvironmentVariableValidationフィーチャーゲートをGAに昇格させ、デフォルトで有効状態にロックしました。 (#132054, @HirazawaUi)
  • 冗長なフィールド名を削除して、無効なフィールドのバリデーションエラーメッセージを簡素化しました。 (#132513, @xiaoweim)
  • 冗長なメッセージを削除して、必須フィールドのバリデーションエラーメッセージを簡素化しました。 (#132472, @xiaoweim)
  • ReplicationControllerの/scaleサブリソースのreplicasフィールドのバリデーションが宣言的バリデーションに移行されました。
    DeclarativeValidationフィーチャーゲートが有効な場合、既存のバリデーションとの不整合はメトリクスで報告されます。
    DeclarativeValidationTakeoverフィーチャーゲートが有効な場合、宣言的バリデーションが移行されたフィールドのエラーの主要ソースとなります。 (#131664, @jpbetz)
  • validation-genコードジェネレータは、バリデーションラチェット処理をサポートするバリデーションコードを生成しました。 (#132236, @yongruilin)
  • ゼロ値のmetadata.creationTimestamp値は省略され、JSON、YAML、CBOR出力で明示的なnullをシリアライズしなくなりました (#130989, @liggitt)
    • 📝 これは地味に嬉しい変更ですね!kubectl create等で生成したYAMLからcreationTimestamp: nullを消す作業が不要になります。

Before

❯ kubectl version --client true
Client Version: v1.32.2
Kustomize Version: v5.5.0

❯ kubectl create secret generic --dry-run=client -o yaml hoge
apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: null
  name: hoge

After

❯ kubectl version --client true
Client Version: v1.34.1
Kustomize Version: v5.7.1

❯ kubectl create secret generic --dry-run=client -o yaml hoge
apiVersion: v1
kind: Secret
metadata:
  name: hoge
  • MultiCIDRServiceAllocatorがロックされデフォルトで有効になり、DisableAllocatorDualWriteがデフォルトで有効になりました。 (#131318, @aojea)

✨ Features (機能追加)

  • Podレベルリソース仕様にHPAサポートを追加しました。Podレベルリソース機能が有効な場合、Resourceタイプメトリクスで設定されたHPAは、指定されていればpod.Spec.ResourcesフィールドからPodリソースを計算しました。 (#132430, @laoj2)
    • 📝 今までHPAでResourceタイプを指定した場合は、全てのコンテナのrequestsやlimitsを合算した値で判断していました。しかし、Podレベルリソースが導入されてからは、Podレベルリソースが優先されるので、HPAでもこの値を使用するのが自然です。Podレベルリソースが指定されていない場合は、従来通りの挙動となります。
  • kubectl api-resourcesにマシン読み取り可能な出力オプション(JSON & YAML)を追加しました。 (#132604, @dharmit)
  • PodObservedGenerationTracking機能をベータに昇格させ、デフォルトで有効にしました。この機能により、Pod内のトップレベルstatus.observedGenerationstatus.conditions[].observedGenerationフィールドが、ステータスまたは条件が報告された時点でのpodspecのmetadata.generationを反映するように設定されました。 (#132912, @natasha41575)
  • Kubeletは、ノード上のアタッチメント制限を超えることによる終端的なCSIボリュームマウント失敗を検出し、StatefulSet Podを失敗としてマークして、そのコントローラが再作成できるようにしました。これにより、PodがContainerCreating状態で無期限にスタックすることを防ぎました。 (#132933, @torredil)
  • メモリ制限は、NotRequiredリサイズ再起動ポリシーで減らすことができるようになりました。メモリ制限を減らす際、制限が使用量を下回って減らされOOM-killを引き起こすことを防ぐため、ベストエフォートチェックが実行されました。 (#133012, @tallclair)
    • 📝 これまでは、In-place pod vertical scalingでは、メモリ制限を増やすことはできても、減らすことはできませんでした。今回の変更により、In-place pod vertical scaling(restartPolicy=NotRequired)の場合でも、メモリ制限を減らすことができるようになりました。
  • ボリューム拡張失敗からの回復をGAに移行しました。 (#132662, @gnufied)
  • KubeletPodResourcesDynamicResourcesKubeletPodResourcesGetフィーチャーゲートをベータに昇格させ、DRAがGAになる場合はデフォルトで有効にしました。 (#132940, @guptaNswati)
    • 📝 DRA関連の変更です
  • デフォルトのAPF設定から「endpoint-controller」と「workload-leader-election」FlowSchemaを削除しました。
    ワークロードのリーダー選出で使用されるロックタイプをconfigmapsleases/endpointsleasesからleasesに移行してください。 (#131215, @tosi3k)
    • 📝 APFってなんだ…?と一瞬思いましたが、どうやらAPI Priority and Fairnessの略みたいです。以前はリーダー選出にEndpointやConfigMapが使われていましたが、現在はLease APIに置き換えられています。そのため、kube-controller-managerからEndpointやConfigMapへのリクエストを、APFにより優先的に処理する必要はもうありません。
  • Kubernetes APIサーバーは、matchLabelKeysから構築されたセレクタをtopologySpreadConstraintslabelSelectorにマージし、Pod Topology Spread動作をInter-Pod Affinityと整合させました。matchLabelKeysを使用している既存のPodの破損を防ぐため、このスケジューラ動作はv1.34まで保持されました。v1.32からv1.34へのアップグレードは段階的に行う必要があり(v1.32 → v1.33 → v1.34)、v1.32でmatchLabelKeysで作成されたPodがv1.34に達する前にスケジュールされることを保証してください。matchLabelKeysに依存するコントローラはもはやそれらを直接処理する必要がなく、代わりにlabelSelectorを使用できます。デフォルトで有効な新しいフィーチャーゲートMatchLabelKeysInPodTopologySpreadSelectorMergeがこの動作を制御します。 (#129874, @mochizuki875)
  • PreferSameTrafficDistributionフィーチャーゲートがデフォルトで有効になり、
    ServiceのPreferSameNodeトラフィック分散値が有効になりました。 (#132127, @danwinship)
  • RelaxedServiceNameValidationフィーチャーゲートが有効な場合、
    新しいServiceの名前はNameIsDNSLabel()でバリデーションされ、
    既存のバリデーションが緩和されました。 (#132339, @adrianmoisey)
  • Podがノードに正常にバインドされるたびに、kube-apiserverはPodのnominatedNodeNameフィールドをクリアしました。これにより、古い情報が外部のスケジューリングコンポーネントに影響することを防ぎました。 (#132443, @utam0k)
  • PodLifecycleSleepActionがGAに昇格しました。 (#132595, @AxeZhan)
  • kube-controller-managerは管理者アクセス権を持つResourceClaimについて次のメトリクスを報告するようになりました:
    • admin_access(trueまたはfalse)、status(failureまたはsuccess)ラベル付きのresourceclaim_controller_creates_totalカウントメトリクスで、ResourceClaim作成要求の総数を追跡
    • admin_access(trueまたはfalse)、allocated(trueまたはfalse)ラベル付きのresourceclaim_controller_resource_claimsゲージメトリクスで、現在のResourceClaim数を追跡 (#132800, @ritazh)
      • 📝 DRA関連の変更です

📃 Documentation

📝 SIG Appsに関連するものはありません

🐛 Bug or Regression (バグ修正)

  • StatefulSet作成のためのpodSpecバリデーションを追加しました。 (#131790, @chengjoey)
    • 📝 どうやらStatefulSetの.spec.template.specについては、適切なバリデーションがかかってなかったようです。この手のバグ修正は、逆に既存の挙動を破壊することにもつながるので、regressionの観点から慎重に行う必要があります。今回のケースでは、更新前のStatefulSetの内容で既にバリデーションが失敗する場合は、今回追加された.spec.template.spec向けのバリデーションは無視されるような挙動になっています。[pkg/apis/apps/validation/validation.go#L250-L253]
  • DRAドライバ: リソーススライスコントローラは、kubeletや他の誰かが最近作成されたResourceSliceを削除した際に適切に反応しないことがありました。ResourceSliceがまだ存在すると誤って想定し、再作成しませんでした。 (#132683, @pohly)
    • 📝 DRA関連の変更です
  • DeploymentReplicaSetTerminatingReplicasフィーチャーゲートが有効な場合のReplicationControllerの調整を修正しました。 (#131822, @atiratree)
  • すでに完了とマークされた(成功または失敗の)Jobに対して不要なPodを作成する可能性があるJobコントローラのバグを修正しました。 (#130333, @kmala)
  • 新しく作成されたJobに対してPodを作成する際の予期しない遅延を引き起こすバグを修正しました。 (#132109, @linxiulei)
  • ReplicaSetを更新する際に重複バリデーションが発生するバグを修正しました。 (#131873, @gavinkflam)
  • デプロイメント名が長すぎる場合にレプリカセットの作成に失敗するバグを修正しました。 (#132560, @hdp617)
    • 📝 Deploymentリソースに紐づくReplicaSetの名前は、${deploymentName}-${hashOfPodTemplateSpec}という形式になります。しかし、Deploymentリソースの名前が長い場合、DNSサブドメインの長さの上限である253文字を超えてしまい、作成時にエラーとなってしまうことがありました。今回の修正で、Deploymentコントローラは、Deploymentリソースの名前を必要に応じて切り詰めることで、全体の名前が適切な長さに収まるような挙動をとるようになりました。
  • PVCステータスバリデーションにおけるallocatedResourceStatusesフィールド名の不整合を修正しました。 (#131213, @carlory)
  • Podレベルでサポートされていないリソースについてコンテナレベルでリソース要件を指定する際のバリデーションエラーの問題を修正しました。Podレベルの値を暗黙的に0として解釈するようにしました。 (#132551, @chao-liang)
    • 📝 Podレベルリソースでサポートされていない設定項目(例えばstorageephemeral-storage)をコンテナレベルリソースに指定していると、全てのコンテナの合計値とPodレベルリソースの制約との整合性チェックでエラーとなってしまう問題がありました。この修正で、storage等の、Podレベルリソースでサポートされていない項目については、バリデーション自体がスキップされるようになりました。
  • suspend=trueかつcompletions=0のJobに対するバリデーションを修正し、Complete条件を設定するようにしました。 (#132614, @mimowo)
    • 📝 v1.31からv1.32にバージョンが上がった際、suspend=trueかつcompletions=0のJobの挙動が変わったとIssueで報告されていましたが、その問題の修正となります。
  • HPAステータスでメモリメトリクスがKiを使用して表示されるようにしました。 (#132351, @googs1025)
  • Kube-apiserver: ドキュメント化されているように、CronJobオブジェクトの空のspec.jobTemplate.spec.podFailurePolicy.rules[*].onPodConditions[*].statusフィールドをデフォルト化し、書き込み要求時のバリデーション失敗を回避しました。 (#131525, @carlory)
  • Kubelet: 静的Podが任意のResourceClaimを参照することを許可する抜け穴を閉じました。これらのPodはサニティチェックにより実行に失敗していましたが、そのような参照は明示的に許可されなくなりました。 (#131844, @pohly)
  • Podはuser-namespaceshostUsers: false)とvolumeDevicesの使用を混在させることが許可されませんでした。Kubernetesはこの場合にエラーを返しました。 (#132868, @rata)
  • ノードが到達不能になった際のnode.kubernetes.io/unreachable:NoExecuteテイント前の5秒の遅延を減らしました。 (#120816, @tnqn)
  • ReplicaSetとDeploymentは遅延なく正しいタイミングで.status.availableReplicasを常にカウントするようになりました。これにより、Deployment条件の調整がより高速になり、ブロックされないより高速なDeploymentロールアウトが実現しました。 (#132121, @atiratree)
  • DaemonSet更新がValidateDaemonSetValidateDaemonSetUpdateへの重複呼び出しにより不必要に重複バリデーションをトリガーするバグを解決しました。この冗長性は削除され、繰り返しバリデーション実行を防ぐようになりました。 (#132548, @gavinkflam)
  • ガベージコレクションコントローラが、孤立したオブジェクトを削除する際にownerReferencesの変更と競合しなくなりました。 (#132632, @sdowell)
  • kubectl get jobを更新し、リストされたジョブにSuccessCriteriaMetステータスを表示するようにしました。 (#132832, @Goend)
  • HPAコントローラを更新し、競合によりスケール操作が最初に失敗したが再試行後に成功した場合にFailedRescaleイベントを発行しなくなりました。この場合はSuccessfulRescaleイベントを発行するようになりました。すべての再試行が終了した場合には引き続きFailedRescaleイベントが発行されます。 (#132007, @AumPatel1)
  • StatefulSetminReadySecondsを尊重するようになりました。 (#130909, @Edwinhr716)
    • 📝 StatefulSetは、ローリングアップデートやスケールイン時には、minReadySecondsに関係なく、Podの実行状態を見て進行可否を判断していました。しかし、本来であれば、minReadySeconds経過前は、Podはまだ利用可能ではないとみなすべきです。本変更により、Podの実行状態に加えて、minReadySecondsについても考慮されるようになりました。

🔬 Others (その他修正)

  • Jobコントローラを変更し、パフォーマンス向上のためPodルックアップにコントローラUIDインデックスを使用するようにしました。 (#132305, @xigang)
    • 📝 それまではNamespace内の全てのPodの一覧を取得していましたが、パフォーマンスの観点で問題がありました。本変更により、JobリソースのUIDをもとに、OwnerReferenceベースでPodの一覧を取得するようになり、パフォーマンスが改善しました。
  • NONW (#132890, @atiratree)
    • 📝 PRの説明欄に「Does this PR introduce a user-facing change?」という項目があり、ここに記入された文面がCHANGELOGに出力されます。PR作成者の意図としては「ユーザ影響のある変更はない」ということだったのですが、NONEと記入したことでここに現れてしまったようです。PR自体は、テストケースの追加をしているだけなので、ユーザ影響のある変更ではありません。
    • 📝 KEP-3973: Consider Terminating Pods in Deploymentsに関する作業の一環で追加されたようです。KEP-3973は、Jobに追加されたPodReplacementPolicyの機能を、Deploymentにも追加しようというものです。
  • SeparateTaintEvictionControllerフィーチャーゲートをGAに昇格させました。現在は無条件で有効になっています。 (#122634, @carlory)
  • 一般利用可能フィーチャーゲートPodDisruptionConditionsを削除しました。 (#129501, @carlory)
  • 📝 以下は全て内部的なもので、内部のヘルパー関数や、非推奨パッケージであるk8s.io/utils/pointerを、k8s.io/utils/ptrに置き換える変更です。
    • toPtrヘルパー関数を「k8s.io/utils/ptr」実装に置き換えました。 (#132806, @PatrickLaabs)
    • 非推奨パッケージk8s.io/utils/pointerを./test/e2eについてk8s.io/utils/ptrに置き換えました。 (#132765, @PatrickLaabs)
    • 非推奨パッケージk8s.io/utils/pointerをpkg/apis用にk8s.io/utils/ptrに置き換えました(1/2)。 (#132778, @PatrickLaabs)
    • 非推奨パッケージk8s.io/utils/pointerをpkg/apis用にk8s.io/utils/ptrに置き換えました(2/2)。 (#132779, @PatrickLaabs)
    • 非推奨パッケージk8s.io/utils/pointerをpkg/controller用にk8s.io/utils/ptrに置き換えました(1/2)。 (#132781, @PatrickLaabs)
    • 非推奨パッケージk8s.io/utils/pointerをpkg/controller用にk8s.io/utils/ptrに置き換えました(2/2)。 (#132784, @PatrickLaabs)

Discussion