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

kubernetes

Last updated at 2024-05-16Posted at 2024-05-15

このエントリは、Kubernetes 1.30 の Kubernetes v1.30: Uwubernetesについてまとめたページです。
細かな変更点については、SIG毎にCHANGELOGをまとめた以下のリンクを参照してください。

変更点の詳細へのリンク

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 TBD
SIG Scheduling @ordovicia
SIG Node @y1r96

Improvements that graduated to stable in Kubernetes v1.30

ここではv1.30でstableとなった改善点の一部を紹介します。

Robust VolumeManager reconstruction after kubelet restart (SIG Storage)

これはkubeletが存在するボリュームがどのようにマウントされたかkubeletのスタートアップ中に追加の情報を取得するというvolume managerのリファクタリングです。
一般的に、これはkubeletのリスタートやマシンの再起動後のボリュームクリーンナップをより堅牢にします。

これはユーザやクラスタ管理者にとっての変更はありません。うまく動作しない場合、以前の動作に戻すためにNewVolumeManagerReconstruction feature gateが利用できましたが、
この機能が安定したため、feature gateはロックされ、無効にすることはできません。

Prevent unauthorized volume mode conversion during volume restore (SIG Storage)

Kubernetes v1.30では、コントロールプレーンは、スナップショットをPersistentVolumeにリストアする際に、ボリュームモードの不正な変更を常に防止します。
クラスタ管理者としては、リストア時にそのような変更を許す必要があれば、権限を適切なアイデンティティープリンシパル(例えばストレージインテグレーションを表すサービスアカウント)へ与える必要があります。

warning
アップグレード前に必要なアクションがあります。prevent-volume-mode-conversion featureフラグがexternal-provisioner v4.0.0およびexternal-snapshotter v7.0.0でデフォルト有効になりました。VolumeSnapShotからPVCを作成する際、external-provisioner
4.0.0とexternal-snapshotter v7.0.0の"Urgent Upgrade Notes"セクションの記載内容を実行しない限り、ボリュームモードの変更は拒否されます。

この機能に関する詳細はconverting the volume mode of a Snapshotをご参照ください。

こちらの詳細については @ysakashita さんのKubernetes: Prevent unauthorized volume mode conversion during volume restoreの動作検証 #kubernetes - Qiita も参考になります。

Pod Scheduling Readiness (SIG Scheduling)

Pod scheduling redinessはKubernetes v1.27でbetaへ昇格し、このリリースでstableとなりました。
このstableとなった機能により、クラスタがまだPodをノードへバインディングするためのリソースがプロビジョニングできていない場合、Kubernetesが定義済みのPodのスケジューリングを試みようとするのを回避できます。
それだけがユースケースではなく、Podのスケジューリングを許可できるかどうかのカスタムコントロールにより、クォータメカニズム、セキュリティ制御などを実装することもできます。

重要なことは、これらのPodをスケジューリングの除外としてマークすることにより、スケジューラが現在クラスタにあるノードにスケジューリングできない、あるいはスケジューリングしようとしないPodを処理する作業を削減できることです。もしcluster autoscalingがアクティブなら、scheduling gateは単にスケジューラの負荷を軽減するだけでなく、利用料も節約できます。scheduling gateがなければ、autoscalerは不要なノードを起動してしまうかもしれません。

Kubernetes v1.30では、Podの.spec.schedulingGatesを指定することにより、Podがスケジューラにとってreadyと考慮されるタイミングをコントロールできます。これはstableな機能であり、現在正式なPodのKubernetes API定義の一部となっています。

Min domains in PodTopologySpread (SIG Scheduling)

このリリースではPodTopologySpread constraintsのminDomainsパラメータがstableへと昇格しました。この機能はドメインの最小数を定義できるようにします。この機能はCluster Autoscaleと共に利用されることを想定されています。

以前試行しドメインが十分に存在しない場合は、Podはunschedulableとしてマークされていました。Cluster Autoscalerはその後、nodeを新しいドメインでプロビジョニングし、最終的にPodが十分なドメインに分散されます。

Go workspaces for k/k (SIG Architecture)

KubernetesリポジトリはGo workspaceを利用するようになりました。これはエンドユーザには全く影響はないはずですが、ダウンストリームのプロジェクトの開発者にとっては影響があります。workspaceへ切り替えることで、様々なk8s.io/code-generatorのツールにフラグのいくつかの破壊的変更が発生しました。ダウンストリームのコンシューマはstaging/src/k8s.io/code-generator/kube_codegen.shの変更を確認してください。

なぜGo workspaceを導入したかの理由や変更についての詳細はUsing Go workspaces in Kubernetesをご参照ください。

Improvements that graduated to beta in Kubernetes v1.30

ここではv1.30でbetaとなった改善点の一部を紹介します。

Node log query (SIG Windows)

ノード上で問題のデバッグを手伝うために、Kubernetes v1.27でノード上のserviceのログをフェッチする機能が導入されました。この機能を利用するためには、NodeLogQuery feature gateをそのノードで有効化しており、kubeletの設定で enableSystemLogHandler と enableSystemLogQuery がtrueへ設定されていることを確認してください。

Kubernetes v1.30リリース以降、これはベータとなりました(この機能を利用するには現在も有効化する必要はあります)。

Linuxではserviceのログがjournald経由で利用可能である想定となっています。Windowsではapplication log provider経由で利用可能であることが想定されています。ログは同様に/var/log(Linux)やC:\var\log\(Windows)の中のファイルを読むことで同様に利用可能です。詳細の情報については、log queryドキュメントを確認してください。

CRD validation ratcheting (SIG API Machinery)

この機能を利用するにはCRDValidationRatcheting feature gateを有効化する必要があり、それによりクラスタの全てのCustomResourceDefinitionsへ適用されます。

そのfeature gateを有効化すると、KubernetesはCustomResourceDefinitionsへvalidation rechetingを実装します。API serverはバリデーションに失敗したリソースの各部分が更新操作によって変更されていないことを条件に、更新後に有効でないリソースへの更新を受け入れます。言い換えると、無効なままのリソースの無効な部分は、すでに間違っている必要があります。このメカニズムを使用して、有効なリソースを無効となるように更新することはできません。

この機能はCRDの作者が特定の条件下でOpenAPIV3 schemaに新しいバリデーションを自信を持って追加できるようにします。ユーザはオブジェクトのバージョンのアップデートや、ワークフローを破壊せずに、新しいスキーマへ安全に更新できます。

Contextual logging (SIG Instrumentation)

Contextual Loggingはこのリリースでbetaとなり、開発者や運用者がWithValuesやWithNameを通してログにservice名やトランザクションIDのようなカスタマイズ可能で相互性のある構造の情報をインジェクトできるようになりました。このエンハンスメントは分散システムのログの相関関係や分析を容易にし、トラブルシューティングの効率が大幅に改善します。Kubernetes環境の動作に対するより明確な洞察を提供することで、Contextual Loggingは運用上の課題をより管理しやすくしなり、Kubernetesのオブザーバビリティが顕著に進化しました。

Make Kubernetes aware of the LoadBalancer behaviour (SIG Network)

LoadBalancerIPMode feature gateは現在betaとなりデフォルトで有効化されました。この機能は.status.loadBalancer.ingress.ipModeをtypeがLoadBalancerへセットされているServiceへセットできるようにします。.status.loadBalancer.ingress.ipModeはどのようにロードバランサーのIPが振る舞うかを指定するものです。これは.status.loadBalancer.ingress.ipフィールドも指定した場合にのみ指定できます。詳細はspecifying IPMode of load balancer statusをご確認ください。

Structured Authentication Configuration (SIG Auth)

Kubernetesはよりフレキシブルで拡張可能な認証システムが長年求められています。現在のシステムは、パワフルな一方、特定のシナリオで利用するのが難しくなるいくつかの制限があります。例として、同種の複数のauthenticator(例えば、複数のJWT authenticatorなど)の利用やAPIサーバの再起動なしに設定変更できません。Structured Authentication Configuration機能はこれらの制限を解決し、Kubernetesで認証の設定をするためのよりフレキシブルで拡張可能な方法を提供する最初のステップです。詳細はstructured authentication configurationをご参照ください。

@hiyosi さんの K8s StructuredAuthenticationConfiguration もあわせてご参照ください

Structured Authorization Configuration (SIG Auth)

Structured Authorization Configurationはこのリリースでbetaへ昇格しました。Kubernetesはシステム管理者や開発者の複雑な要件を満たすために進化し続けています。クラスタのセキュリティと完全性を保証するKubernetesの重要な側面は、APIサーバの認可です。最近まで、kube-apiserverで認可のチェーンの設定はやや厳しく、コマンドラインの設定に制限され、認可チェーンでは単一のWebhookしか許可されていませんでした。このアプローチは機能するものの、クラスタ管理者が複雑できめ細やかな認可ポリシーを定義するために必要な柔軟性がありませんでした。最新のStructured Authorization Configuration機能は、認可チェーンの設定のためのより構造的かつ多用途な方法を導入し、複数のwebhookや明確なコントロールメカニズムを提供することに集中することで、この点に革命を起こすことを目的としています。詳細はstructured authorization configurationをご参照ください。

@hiyosi さんのK8s StructuredAuthorizationConfigurationもあわせてご参照ください

New alpha features

Speed up recursive SELinux label change (SIG Storage)

v1.27リリースから、Kubernetesは既にvolumeのコンテンツへ一定時間でSELinuxのラベルをセットする最適化を含んでおります。Kubernetesはマウントオプションを使用してこの高速化を実現しています。従来の遅い振る舞いでは、コンテナランタイムが再起的にボリューム全体へSELinuxラベルを個々のファイル・ディレクトリへ適用する必要がありました。これは特に大量のファイル・ディレクトリを持つボリュームは影響が大きくなります。

Kubernetes v1.27ではこの機能がbetaとなりましたが、ReadWriteOncePodボリュームに限定されていました。対応するfeature gateはSELinuxMountReadWriteOncePodです。それはデフォルトで有効化されており、v1.30までbetaのままとなります。

Kubernetes v1.30はアルファのSELinuxMountという分離されたfeature gateとしてSELinuxのマウントオプションのサポートが全てのボリュームへ拡張しました。このfeature gateは複数の異なるSELinuxラベルを持つPodが同じボリュームを共有しているときの振る舞いに変更をもたらします。詳細はKEPをご参照ください。

SELinuxを有効化したKubernetesを実行しているユーザには、この機能をテストしていただき、KEP issueにフィードバックを提供していただくことを強くお勧めします。

Feature gate	Stage in v1.30	Behavior change
SELinuxMountReadWriteOncePod	Beta	No
SELinuxMount	Alpha	Yes

全てのボリュームでこの機能をテストするには、feature gateのSELinuxMountReadWriteOncePodとSELinuxMountの両方を有効化する必要があります。

この機能はWindowsノードやSELinuxをサポートしないLinuxノードには影響がありません。

Recursive Read-only (RRO) mounts (SIG Node)

このリリースでアルファ機能としてRecursive Read-Only(RRO)マウントを導入することで、データのための新しいセキュリティーレイヤーが追加されました。この機能はリードオンリーとしてボリュームとそのサブボリュームをセットすることができ、誤った変更を防ぎます。データの整合性が重要なクリティカルなアプリケーションをデプロイする場合を想像してみてください。RROマウントはータが触れられないことを保証し、追加のセーフガードでクラスタのセキュリティを強化します。これは最小の変更でさえ大きなインパクトを与える可能性がある厳密にコントロールされた環境で特に重要です。

Job success/completion policy (SIG Apps)

Kubernetes v1.30から、indexed Jobが.spec.successPolicyをサポートし、成功したPodに基づいてジョブが成功したと宣言できるタイミングを定義できるようになりました。これにより2つのタイプの基準を定義できます。

succeededIndexesは例え他のインデックスが失敗しても、これらのインデックスが成功した時にJobが成功したと宣言できることを示します。
succeededCountは成功したインデックスの数がこの基準に達した時にJobが成功したと宣言できることを示します。

Jobがsuccess policyを満たした後、Jobコントローラは残留するPodを終了させます。

Traffic distribution for services (SIG Network)

Kubernetes v1.30ではalphaとしてKubernetesのServiceにspec.trafficDistributionフィールドを導入しました。これはどのようにトラフィックがServiceのエンドポイントへルーティングされるかについての優先度を表現できるようにします。traffic policiesが厳格なセマンティックの保証にフォーカスしている一方、traffic distributionは優先度を表現する(トポロジー的に近くのエンドポイントへルーティングされるような)ものです。これはパフォーマンス、コスト、信頼性の最適化に役立ちます。このフィールドはServiceTrafficDistribution feature gateをクラスタ・すべてのノードで有効化することで利用可能となります。Kubernetes v1.30で以下のフィールドがサポートされました。

PreferClose: クライアントに局所的に近いエンドポイントにトラフィックをルーティングする優先度を示します。"topologically proximate"の解釈は実装により異なり、この値を設定することで、例えば負荷の均等配分よりも近接性を最適化するなど、実装が異なるトレードオフを行うことを許容します。このようなトレードオフが許容できない場合は、この値を設定すべきではありません。

フィールドがセットされなかった場合、kube-proxyのような実装がそのデフォルトルーティングのストラテジーに利用されます。

詳細はTraffic Distributionをご参照ください。

Storage Version Migration (SIG API Machinery)

Kubernetes v1.30でStorageVersionMigrationのための新しい組み込みAPIが導入されました。KubernetesはAPIデータが能動的にストレージへ再書き込まれることに依存しており、これによりストレージに関連するいくつかのメンテナンス活動がサポートされます。その中で、主な例として挙げられるのは、保存されたリソースのバージョン付きスキーマ（つまり、特定のリソースの推奨ストレージスキーマがv1からv2に変更される）と暗号化（つまり、データを暗号化する方法が変更されたことに基づいて古いデータを書き換える）です。

StorageVersionMigrationは以前はout of treeで利用可能であったalpha APIです。
詳細はSee storage version migrationをご参照ください。

Graduated to stable

このリストはすべてstable(一般的にGeneral availabilityとして知られている)へ昇格した機能です。新しい機能やalphaからbetaへ昇格したものを服すアップデートの全てのリストはrelease notesをご参照ください。

このリリースでは計17のエンハンスメントがstableとなりました。

Deprecations and removals

Removed the SecurityContextDeny admission plugin, deprecated since v1.27

(SIG Auth, SIG Security, と SIG Testing) SecurityContextDeny admission pluginが削除されたため、代わりにv1.25から利用できるPod Security Admissionプラグインが推奨されます。

Urgent Upgrade Notes

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

なし
- 今回このフィールドはありませんでしたが、いくつかの廃止された機能があるため、そちらの影響がないか確認された方が良さそうです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up