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
フラグを設定する必要があります。- K8s v1.32 SIG-Authの変更内容で、アルファ版時点での解説がされています。
- Betaの時点では、GKEとの統合のみが完了している状況のようです。軽く調査した限りだと、ExternalJWTSigner APIを実装したプロバイダーのうち、オープンになっているものを発見することができませんでした。もしご存知の方がいたら教えていただきたいです🙇
- 現時点では、署名をする度にプロバイダーへリクエストが飛ぶため、可用性の観点で懸念があります。KEPには、将来的にはshort-livedな鍵を用いて、kube-apiserver側で署名を行えるようにすることも検討されているようです。ここでは、JWTをX.509証明書に紐づいた鍵を用いて署名する方法(x5c verification)が案として挙げられています。
-
ドキュメントには載っていませんが、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を参照してください。
例
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ソースを有効にします。
フィーチャー昇格
v1.34で動きがあった機能のうち、SIG Appsに関係するものを記載しています。それぞれの文頭には、対応するフィーチャーゲート名を記載しています。
Beta
Betaに昇格した機能のうち、SIG Appsが主管するものはありませんでした。以下は、SIG Appsが関係する機能です。それぞれの文頭には、対応するフィーチャーゲート名を記載しています。
以下に記載のあるフィーチャーゲートは、全てデフォルトで 有効 です。
- 📝 以下の2つは、KEP-3695として進められています。
-
KubeletPodResourcesDynamicResources
: kubeletの
podリソース監視gRPC API
のListおよびGetエンドポイントを拡張して、動的リソース割り当て
を通じてResourceClaimに割り当てられたリソースを含めるようにします。 -
KubeletPodResourcesGet
: PodリソースのためのkubeletでのgRPCGet
エンドポイントを有効にします。
このAPIはリソース割り当てレポートを拡張します。
-
-
KubeletServiceAccountTokenForCredentialProviders
: kubeletが、イメージが取得されるPodにバインドされたサービスアカウントトークンを認証プロバイダプラグインに送信できるようにします。- 📝 KEP-4412として進められていた変更です。
-
MatchLabelKeysInPodTopologySpreadSelectorMerge
:matchLabelKeys
から構築されたセレクターを
Podトポロジー分散制約のlabelSelector
にマージすることを有効にします。
このフィーチャーゲートはMatchLabelKeysInPodTopologySpread
フィーチャーフラグでmatchLabelKeys
機能が有効な場合に有効にできます。 -
PodLevelResources
: Podレベルリソース を有効にします。特定のコンテナに対してのみではなく、Podレベルでリソース要求と制限を指定する機能です。- 📝 KEP-2837で進められていた変更です。Podの
.spec.resources
フィールドで、Pod全体のリソース要求や制限を設定することができます。今までは、各コンテナごとにリソース要求と制限を設定する必要があり、Pod全体のリソース消費量の管理が少々面倒だったと思います。本機能により、Pod全体でリソース要求・制限を設定することができるようになるので、より直感的にリソースの管理ができるようになります。
- 📝 KEP-2837で進められていた変更です。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
というイベントが記録されるようになりました。これにより、正しくリサイズが完了したかどうかをイベントログ経由で確認できるようになります。
- 📝 Podのリサイズが完了した際に、
- コンテナの再起動を構成可能にするメカニズムである コンテナレベル再起動ルール を追加しました。これは
ContainerRestartRules
フィーチャーゲートの背後にあるアルファ機能でした。 (#132642, @yuanwang04) - コンテナに新しい
FileKeyRef
フィールドを追加し、このフィールドを設定することでファイルから変数を読み込むことができるようになりました。
この機能の有効化を制御するためのEnvFiles
フィーチャーゲートを導入しました。 (#132626, @HirazawaUi) -
ResourceSlice
にドライバー所有のフィールドを追加し、デバイスが複数のリソースクレーム(または要求)間で共有可能かどうかを示し、各容量を異なる要求間でどのように共有できるかを指定するようにしました。 -
ResouceSlice.Basic
とResourceClaim.Status.AllocatedDeviceStatus
に新しいオプションAPIを追加しました。 (#130160, @KobayashiD27)- 📝 DRA関連の変更です
- Dynamic Resource Allocation(DRA)を介して割り当てられたデバイスの健全性をKubeletが監視し、
pod.status.containerStatuses.allocatedResourcesStatus
フィールドで報告するサポートを追加しました。これにはDRAプラグインが新しいv1alpha1NodeHealth
gRPCサービスを実装する必要がありました。この機能はResourceHealthStatus
フィーチャーゲートによって制御されました。 (#130606, @Jpsassine)- 📝 DRA関連の変更です
- サポートの不足により、
PodLevelResources
機能をWindows OSで使用するPodを拒否するバリデーションを追加しました。APIサーバーは、Pod レベルリソースを持ちPod.spec.os.name
がWindowsを対象とするPodを拒否しました。WindowsノードのKubeletも、アドミッション段階でPodレベルリソースを持つPodを拒否しました。 (#133046, @toVersus)- 📝 PodレベルリソースのWindowsサポートは将来的に追加され予定ではありますが、現時点では実装されていません。そのため、Windows向けのPodでPodレベルリソースを設定しようとすると、バリデーションで拒否されるようになっています。
-
pvc.spec.VolumeAttributesClassName
をnon-nilからnilへ変更することを許可しました。 (#132106, @AndrewSirenko) -
PodSpec
のhostnameOverride
フィールドを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関連の変更です
-
PodCertificateRequest
とPodCertificate
プロジェクトボリュームのkube-apiserverサポートを有効化しました(PodCertificateRequest
フィーチャーゲートの背後)。 (#128010, @ahmedtd) - DRAでバックアップされた拡張リソース機能により、クラスターオペレータが
DeviceClass
でextendedResourceName
を指定し、アプリケーションオペレータが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
VolumeAttributesClass
とVolumeAttributesClassList
をstorage.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レベルリソースが指定されていない場合は、従来通りの挙動となります。
- 📝 今までHPAで
-
kubectl api-resources
にマシン読み取り可能な出力オプション(JSON & YAML)を追加しました。 (#132604, @dharmit) -
PodObservedGenerationTracking
機能をベータに昇格させ、デフォルトで有効にしました。この機能により、Pod内のトップレベルstatus.observedGeneration
とstatus.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
)の場合でも、メモリ制限を減らすことができるようになりました。
- 📝 これまでは、In-place pod vertical scalingでは、メモリ制限を増やすことはできても、減らすことはできませんでした。今回の変更により、In-place pod vertical scaling(
- ボリューム拡張失敗からの回復をGAに移行しました。 (#132662, @gnufied)
-
KubeletPodResourcesDynamicResources
とKubeletPodResourcesGet
フィーチャーゲートをベータに昇格させ、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
から構築されたセレクタをtopologySpreadConstraints
のlabelSelector
にマージし、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
について次のメトリクスを報告するようになりました:
📃 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]
- 📝 どうやらStatefulSetの
- 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リソースの名前を必要に応じて切り詰めることで、全体の名前が適切な長さに収まるような挙動をとるようになりました。
- 📝 Deploymentリソースに紐づくReplicaSetの名前は、
- PVCステータスバリデーションにおける
allocatedResourceStatuses
フィールド名の不整合を修正しました。 (#131213, @carlory) - Podレベルでサポートされていないリソースについてコンテナレベルでリソース要件を指定する際のバリデーションエラーの問題を修正しました。Podレベルの値を暗黙的に0として解釈するようにしました。 (#132551, @chao-liang)
- 📝 Podレベルリソースでサポートされていない設定項目(例えば
storage
やephemeral-storage
)をコンテナレベルリソースに指定していると、全てのコンテナの合計値とPodレベルリソースの制約との整合性チェックでエラーとなってしまう問題がありました。この修正で、storage
等の、Podレベルリソースでサポートされていない項目については、バリデーション自体がスキップされるようになりました。
- 📝 Podレベルリソースでサポートされていない設定項目(例えば
-
suspend=true
かつcompletions=0
のJobに対するバリデーションを修正し、Complete条件を設定するようにしました。 (#132614, @mimowo)- 📝 v1.31からv1.32にバージョンが上がった際、
suspend=true
かつcompletions=0
のJobの挙動が変わったとIssueで報告されていましたが、その問題の修正となります。
- 📝 v1.31からv1.32にバージョンが上がった際、
- HPAステータスでメモリメトリクスがKiを使用して表示されるようにしました。 (#132351, @googs1025)
- Kube-apiserver: ドキュメント化されているように、CronJobオブジェクトの空の
spec.jobTemplate.spec.podFailurePolicy.rules[*].onPodConditions[*].status
フィールドをデフォルト化し、書き込み要求時のバリデーション失敗を回避しました。 (#131525, @carlory) - Kubelet: 静的Podが任意のResourceClaimを参照することを許可する抜け穴を閉じました。これらのPodはサニティチェックにより実行に失敗していましたが、そのような参照は明示的に許可されなくなりました。 (#131844, @pohly)
- Podは
user-namespaces
(hostUsers: false
)とvolumeDevices
の使用を混在させることが許可されませんでした。Kubernetesはこの場合にエラーを返しました。 (#132868, @rata) - ノードが到達不能になった際の
node.kubernetes.io/unreachable:NoExecute
テイント前の5秒の遅延を減らしました。 (#120816, @tnqn) - ReplicaSetとDeploymentは遅延なく正しいタイミングで
.status.availableReplicas
を常にカウントするようになりました。これにより、Deployment条件の調整がより高速になり、ブロックされないより高速なDeploymentロールアウトが実現しました。 (#132121, @atiratree) - DaemonSet更新が
ValidateDaemonSet
とValidateDaemonSetUpdate
への重複呼び出しにより不必要に重複バリデーションをトリガーするバグを解決しました。この冗長性は削除され、繰り返しバリデーション実行を防ぐようになりました。 (#132548, @gavinkflam) - ガベージコレクションコントローラが、孤立したオブジェクトを削除する際に
ownerReferences
の変更と競合しなくなりました。 (#132632, @sdowell) -
kubectl get job
を更新し、リストされたジョブにSuccessCriteriaMet
ステータスを表示するようにしました。 (#132832, @Goend) - HPAコントローラを更新し、競合によりスケール操作が最初に失敗したが再試行後に成功した場合に
FailedRescale
イベントを発行しなくなりました。この場合はSuccessfulRescale
イベントを発行するようになりました。すべての再試行が終了した場合には引き続きFailedRescale
イベントが発行されます。 (#132007, @AumPatel1) -
StatefulSet
はminReadySeconds
を尊重するようになりました。 (#130909, @Edwinhr716)- 📝 StatefulSetは、ローリングアップデートやスケールイン時には、
minReadySeconds
に関係なく、Podの実行状態を見て進行可否を判断していました。しかし、本来であれば、minReadySeconds
経過前は、Podはまだ利用可能ではないとみなすべきです。本変更により、Podの実行状態に加えて、minReadySeconds
についても考慮されるようになりました。
- 📝 StatefulSetは、ローリングアップデートやスケールイン時には、
🔬 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