Kubernetes 1.28: 変更点まとめ(What's new!)とアップグレード時の注意事項

はじめに

このエントリは、Kubernetes 1.28 の CHANGELOG 及びKubernetes v1.28: PlanternetesからWhat's new!とアップグレード時の注意事項、各変更点についてまとめたページへのリンクです。
詳細については各まとめページを参照してください。

変更点の詳細へのリンク

• Metrics Changes と SIG Instrumentation @watawuwu
• SIG Apps @yosshi_
• SIG API Machinery @Ladicle
• SIG Auth @hiyosi
• SIG CLI @superbrothers
• SIG Cluster Lifecycle @yuanying
• SIG Storage @ysakashita
• SIG Network @tkusumi
• SIG Scheduling @ordovicia
• SIG Node @y1r96

What's New (Major Themes)

Changes to supported skew between control plane and node versions

コアノードとコントロールプレーンコンポーネント間のサポートされるバージョンのSkewをn-2からn-3に拡大・テストできるようにし、最も新しいサポートされるマイナーバージョンのコントロールプレーンコンポーネント（kube-apiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager）と、最も古いサポートされるマイナーバージョンのノードコンポーネント（kubeletおよびkube-proxy）が上手く動作するようになりました。
コントロールプレーンのアップグレードは、ほとんどの場合時間がかかってしまうワークロードを実行中のノードのアップグレードよりも少し速くなるため、これはエンドユーザーにとって価値があります。
Kubernetesの1年間のサポート期間はすでに年単位のアップレードを可能にしています。ユーザはセキュリティの修正のために最新のパッチバージョンへアップグレードでき、そして最新のマイナーバージョンへ追いつくために、年に1度だけ3マイナーバージョンのアップグレードを実行できます。
ただし、ノードとコントロール プレーン間のテスト/サポートされているskewは現在2バージョンに制限されているため、3バージョンのアップグレードでは、サポートされているskew内に収まるようにノードを2回更新する必要があります。

Generally available: recovery from non-graceful node shutdown

ノードが予期しない・復帰できない状態で終了する場合(おそらくハードウェアの障害やOSの応答がない)、Kubernetesを使用すると、後にクリーンアップし、ステートフル ワークロードを別のノードで再起動できるようになります。Kubernetes v1.28で、それは安定した機能となりました。
これにより、元のノードがシャットダウンや復帰できない状態となった後、ステートフルワークロードが異なるノードへフェイルオーバーできるようになります。
v1.20以前のKubernetesのバージョンはLinux上のノードのシャットダウンのためのハンドリングが欠けていましたが、kubeletがsystemdと統合し、graceful node shutdownを実装しました(betaとなっており、デフォルト有効)。しかしながら、以下の理由から意図したシャットダウンであっても上手く処理されない場合がありました。

• ノードがWindows上で動作している
• ノードがLinux上で動作しているが、systemdとはことなるinitを利用している
• シャットダウンがsystem inhibitor locks mechanismをトリガーしない
• ノードレベルの設定エラー(適切な値がshutdownGracePeriodやshutdownGracePeriodCriticalPodsへ設定されていないなど)

ノードがシャットダウンまたは失敗時、そのシャットダウンがkubeletにより検知されなかった場合、StatefulSetのPodはシャットダウンノード上で終了ステータスのままとなります。停止したノードが再起動すると、そのノード上のkubeletはkubernetes APIがまだそのノードにバインドされているとみなしているPodをクリーンアップ(DELETE)できます。しかし、もしノードが停止し続けたり、リブート後にkubeletがスタートできない場合、Kubernetesは代替のPodを作成できない可能性があります。シャットダウンノード上のkubeletが古いPodの削除ができない時、関連したStatefulSetは新しいPod(それは同じ名前をもつ)を作成できません。

またストレージにも問題があります。もしそのPodによって利用されているボリュームが存在する場合、既存の VolumeAttachmentsは元のノード（現在はシャットダウンされている）から切り離されないため、これらのポッドで使用されている PersistentVolumesを別の正常なノードにアタッチすることはできません。その結果、影響を受けたStatefulSet上で実行されているアプリケーションが正しく機能しなくなる可能性があります。シャットダウンされた元のノードが起動した場合、それらのPodはそのkubeletによって削除され、別の実行中のノードで新しいPodを作成できます。元のノードが立ち上がらない場合（イミュータブル・インフラストラクチャの設計では一般的）、それらのPodは、シャットダウンされたノード上のターミネーション・ステータスから永遠に抜け出せなくなります。

Non Graceful node shutdownの後のクリーンアップをトリガーする方法については、non-graceful node shutdownをご参照ください。

• NodeOutOfServiceVolumeDetachfeature がGAとなった話のようです。
• 詳細は @ysakashita さんの Kubernetes: Non Graceful Node Shutdownの動作検証　をご参照ください。

Improvements to CustomResourceDefinition validation rules

Common Expression Language(CEL)はCustomResourceのvalidateをするために利用できるようになりました。メインのゴールはかつてCustomResourceDefinition(CRD)の作成者としてwebhookのデザイン・実装が必要だったvalidationのユースケースの大部分です。ベータ機能として、webhookの代わりにvalidation式を直接CRDのスキーマに追加できます。

CRDには、複雑なvalidationに対する直接のサポートが必要です。Admission webhookはCRDのvalidationをサポートしていますが、それらはCRDの開発と運用を複雑化させる要因となります。

1.28から、validationが失敗した場合にユーザーが失敗の理由とフィールドパスを指定できるように、reasonおよびfieldPathという2つのオプションフィールドが追加されました。

詳細はCRDのドキュメントのvalidation rulesをご参照ください。

ValidatingAdmissionPolicies graduate to beta

Common Expression Language(CEL)を用いたAdmisson Controlは、Validating Admission Webhookに代わる形で、Kubernetes APIサーバーへのリクエストのカスタマイズ可能なin-processなvalidationを提供します。

これは1.25でbetaとなったCRDのValidation Rulesの機能をベースにしていますが、Validating admission controlのポリシーを強制する機能にフォーカスしたものです。

これにより、カスタマイズ可能なポリシーを実施するためのインフラの障壁が低くなるとともに、コミュニティがK8sとその拡張機能の両方のベストプラクティスを確立し、遵守するのに役立つ基本的な要素が提供されます。

ValidatingAdmissionPoliciesを使うためには、admissionregistration.k8s.io/v1beta1 APIグループとValidatingAdmissionPolicy feature gateをコントロールプレーンで有効化する必要があります。

Match conditions for admission webhooks

Kubernetes v1.27はadmission webhookのための一致条件を指定できるようになり、それはKubernetesがadmission時に外部へHTTPを呼び出す時のスコープを狭くできるようになりました。
ValidatingWebhookConfigurationとMutatingWebhookConfigurationのmatchConditionフィールドはwebhookへ送られるべきadmission requestの場合trueを評価するCELの式を記述します。

Kubernetes v1.28から、そのフィールドはbetaとなり、デフォルトで有効化されます。

詳細は、KubernetesのドキュメントのmatchConditionsをご参照ください。

Beta support for enabling swap space on Linux

これにより、Kubernetesユーザーがテストを実施し、スワップ上にクラスタ機能を構築し続けるためのデータを提供できるように、制御された予測可能な方法でノードにスワップサポートが追加されます。

スワップのユーザーには、重複する場合がある2つの明確なタイプがあります：

• ノードレベルのパフォーマンスチューニングや安定性の向上/隣接するノイズの問題を減少させるために、スワップを利用したいノード管理者
• スワップメモリ利用するとメリットがあるアプリケーションを開発したアプリケーション開発者

Mixed version proxy (alpha)

クラスタに複数の異なるバージョンのAPIサーバが存在する時(upgrade/downgradeやruntime-configの変更時やロールアウトが発生した時のような)、全てのapiserverがすべてバージョンの全リソースをサーブできるわけではありません。

Kubernetes v1.28では、API serverのaggregation layer内にmixed version proxyを有効化できます。mixed version proxyはローカルのAPIサーバが認識できないが、他のサポート可能なAPIサーバを見つけます。適切なピアが見つかった場合、aggregation layerはリクエストを互換性のあるAPI serverへプロキシします。これはクライアント視点では透過的です。

クラスタのアップグレードやダウングレード時、しばらくの間コントロールプレーンのAPIサーバは異なるバージョンとなるかもしれません。そうなると、APIサーバの異なるサブセットは異なる組み込みリソース・セット（異なるグループ、バージョン、リソースがすべて可能）を提供できるようになります。この新しいアルファ機能はクライアントからそれらのskewを隠蔽してくれます。

Source code reorganization for control plane components

Kubernetesのコントリビュータは、kube-apiserverのコードを再編成し始めており、k/apiserverを利用するが、再利用可能なようにkube-apiserverの機能のより大きく、慎重に選ばれたサブセットを持つ新しいステージングリポジトリを基盤として構築しています。

これは段階的な再編成であり、最終的にはKubernetesのAPIサーバーから抽象化された汎用機能を持つ新しいgitリポジトリが存在することになります。

Support for CDI injection into containers (alpha)

CDIは複雑なデバイスをコンテナへインジェクションするスタンダードな方法を提供します（つまり、動作させるためにノードの/devを一つ以上注入する必要があるデバイス）。この新機能により、プラグイン開発者は、1.27のCRIに追加されたCDIDevicesフィールドを使用して、CDIデバイスを直接CDI対応のランタイム（最近のリリースではcontainerdとcrio-oが該当）に渡すことができます。

API awareness of sidecar containers (alpha)

Kubernetes 1.28ではalphaでinit containerのためにrestartPolicyフィールドを導入し、init containerがサイドカーコンテナとして存在していることを示すためにそのフィールドを利用します。これによりrestartPolicy: Alwaysが設定されたinit containerは定義された順番で、他のinit containerと共にスタートします。Podのメインのコンテナがスタートする前に、kubeletはそのサイドカーコンテナが完了を待つ代わりに、サイドカーのinit containerがスタートするのだけ待ちます。

そのスタートアップの完了条件はstartup probeが成功したということ(もしくはstartup probeが定義されていない場合)そしてpostStart handlerが完了したこととなります。この条件はContainerStatus型のStartedフィールドで表現されます。このシグナルを選択した判断については"Pod startup completed condition"セクションをご確認ください。

サイドカーコンテナでは、init containerよりrestartの振る舞いが複雑です。restartPolicyがNeverへセットされているPodでは、Podのスタートアップ中に失敗するサイドカーコンテナはリスタートされず、Pod全体が終了として扱われます。もしPodのrestartPolicyがAlwaysまたはOnFailureにセットされている場合、起動に失敗したサイドカーはリトライされます。

一度サイドカーコンテナが起動後(プロセスが動作し、postStartが成功し、全ての設定されたstartup probeがパス)、何らかで失敗すると、Pod全体のrestartPolicyがNeverまたはOnFailureであってもサイドカーコンテナはリスタートされます。さらに、サイドカーコンテナはPodがTermination中でさえもリスタートされます(失敗または通常の終了で)。

詳細はサイドカーコンテナのAPIをご参照ください。

Automatic, retroactive assignment of a default StorageClass graduates to stable

KubernetesはPersistentVolumeClaimのstorageClassNameがセットされてない場合に、自動的にセットします。コントロールプレーンは、storageClassNameが定義されていない既存のPVCすべてにStorageClassを設定します。Kubernetesの以前のバージョンもこの動作を持っていましたが、Kubernetes v1.28ではこれは自動で常にアクティブです。この機能は安定版（一般提供）に昇格しました。

詳しくは、Kubernetesのドキュメント内のStorageClassに関する部分を読んでください。

Pod replacement policy for Jobs (alpha)

Kubernetes 1.28では、Job APIに新しいフィールドが追加され、前のPodが終了を開始すると、すぐに新しいPodをコントロールプレーンが作成するか（既存の動作）、または既存のPodが完全に終了するまで待つか（新しいオプションの動作）を指定することができます。

多くの一般的な機械学習フレームワーク、例えばTensorflowやJAXは、インデックスごとにユニークなPodを必要とします。古い動作において、Indexed Jobに属するPodが終了状態に入ると（プリエンプション、eviction、またはその他の外部要因のため）、代替のPodが作成されますが、まだシャットダウンしていない古いPodとの競合のため、すぐに起動に失敗します。

前のPodが完全に終了する前に代替のPodが現れることは、リソースが少ないクラスターや予算が厳しいクラスターでも問題を引き起こすことがあります。これらのリソースは入手が難しいため、既存のポッドが終了した後でのみノードを見つけることができるかもしれません。クラスターオートスケーラが有効になっている場合、代替Podの早期作成は望ましくないスケールアップを引き起こす可能性があります。

詳しくは、Jobのドキュメント内の Delayed creation of replacement pods をお読みください。

Job retry backoff limit, per index (alpha)

これにより、Job APIはインデックスごとのバックオフ制限を持ち、一部のインデックスが失敗してもJobの実行を続けることができるインデックス化されたジョブをサポートするように拡張されます。

現在、インデックス化されたJobのインデックスは単一のバックオフ制限を共有しています。Jobがこの共有バックオフ制限に達すると、ジョブコントローラはJob全体を失敗としてマークし、リソースがクリーンアップされます。これには、完了まで実行されていないインデックスも含まれます。

その結果、既存の実装は、ワークロードが本当にEmbarrassingly parallelである場面をカバーしていませんでした：各インデックスは他のインデックスと完全に独立しています。

例えば、インデックス化されたJobが長時間実行される統合テストのスイートの基盤として使用される場合、各テスト実行は単一のテスト失敗のみを見つけることができます。

詳細については、Kubernetesのドキュメントの Handling Pod and container failures セクションをお読みください。

CRI container and pod statistics without cAdvisor

これには2つの関連する作業が含まれます。(kubeletの/metrics/cadvisorエンドポイントへの変更と、置き換えのsummary APIへの改善)

動作中のコンテナとPodに関する統計を収集するために消費者が使用する2つの主要なAPIがあります: summary APIと/metrics/cadvisorです。Kubeletはsummary APIの実装を担当し、cadvisorは/metrics/cadvisorの要求を満たすための責任を持っています。

これにより、CRIの実装がKubernetesの統計ニーズをすべて満たすことができるようになります。大まかには、これには2つの部分があります：

• CRI APIを強化して、summary APIのpodとcontainerフィールドをCRIから直接補完するための十分なメトリクスが提供されます。
• CRIの実装が、/metrics/cadvisorエンドポイントのpodとcontainerフィールドを満たすための必要なメトリクスをブロードキャストするように強化されます。

Feature graduations and deprecations in Kubernetes v1.28

このリリースでは合計12のエンハンスメントがステーブルとなりました。

• kubectl events
• Retroactive default StorageClass assignment
• Non-graceful node shutdown
• Support 3rd party device monitoring plugins
• Auth API to get self-user attributes
• Proxy Terminating Endpoints
• Expanded DNS Configuration
• Cleaning up IPTables Chain Ownership
• Minimizing iptables-restore input size
• Graduate the kubelet pod resources endpoint to GA
• Extend podresources API to report allocatable resources
• Move EndpointSlice Reconciler into Staging

Deprecations and removals

Removals

• Removal of CSI Migration for GCE PD

Deprecations

• Ceph RBD in-tree plugin
• Ceph FS in-tree plugin

Urgent Upgrade Notes

(No, really, you MUST read this before you upgrade)

• カスタムスケジューラプラグインの開発者はアクションが必要です。スケジューリングフレームワークにおいてEnqueueExtensionで破壊的変更があります。EnqueueExtensionのEventsToRegisterはClusterEventからClusterEventWithHintへ返り値を変更しました。ClusterEventWithHintはプラグインに対してQueueingHintFnと呼ばれるコールバック関数を用いて、より必要のないイベントを除外できます。スケジューリングキューがクラスターイベントの受信時、各Podを未スケジュールのPodプールからactiveQ/backoffQに移動する前に、前回のスケジューリングサイクルで各Podを拒否したプラグインのQueueingHintFnを呼び出します。
  QueueingHintFnから返される値に応じて、スケジューリングキューは各Podのキューイング方法を変更します：
  • 1つ以上のQueueingHintFnがQueueImmediatelyを返す場合、PodをactiveQにキューします。
  • QueueingHintFnがQueueImmediatelyを返さず、1つ以上のプラグインがQueueAfterBackoffを返す場合、Podがバックオフ中の場合はPodをbackoffQにキューし、Podのバックオフが既に終了している場合はactiveQにキューします。
  • すべてのQueueingHintFnがQueueSkipを返す場合、このPodを未スケジュールポッドプールに戻します。

適切なQueueingHintFnを持つことで、無駄なリトライを削減し、結果としてスケジューラの全体的なパフォーマンスを向上させることができます。

どのようにマイグレートすれば良いか？

後方互換性のために、QueueingHintFnがnilの場合は常にQueueAfterBackoffを返していると使われます。
そのため、もし単に既存の挙動を続けたい場合、QueueingHintFnがないClusterEventWithHintを登録できます。
しかし、適切なQueueingHintFnを登録することはもちろんスケジューリングのパフォーマンスを考慮すると良いです。(#118551, @sanposhiho) [SIG Node, Scheduling, Storage and Testing]

• CephFSボリュームプラグイン (kubernetes.io/cephfs)はこのリリースで非推奨となり、今後のリリースで削除されます。代替としてはCephFS CSIドライバー (https://github.com/ceph/ceph-csi/)をクラスタで利用する事です。([#118143](https://github.com/kubernetes/kubernetes/pull/118143), @humblec)
• Ceph RBD volumesのCSIマイグレーションのサポートは非推奨となりました。out-of-treeのストレージドライバーへの移行のためのKubernetesの機能を利用していたユーザは、そのサポートが完全に削除される前に移行を完了させる必要があります。(#118303, @carlory)
• RBDボリュームプラグイン(kubernetes.io/rbd)はこのリリースで非推奨となり、今後のリリースで削除されます。代替としてはRBD CSI driver(https://github.com/ceph/ceph-csi/)をクラスタで利用することです。([#118552](https://github.com/kubernetes/kubernetes/pull/118552), @humblec)