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

このエントリは、Kubernetes 1.30 の [Kubernetes v1.30: Uwubernetes](https://kubernetes.io/blog/2024/04/17/kubernetes-v1-30-release/)についてまとめたページです。
細かな変更点については、SIG毎に[CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md)をまとめた以下のリンクを参照してください。

# 変更点の詳細へのリンク

- [Metrics Changes と SIG Instrumentation](https://qiita.com/watawuwu/items/09b929fa5537babeaf6e) @watawuwu 
- [SIG Apps](https://qiita.com/yosshi_/items/b575a20cbbb6ebf1609f) @yosshi_ 
- [SIG API Machinery](https://qiita.com/Ladicle/items/c270e28566623b6b0167) @Ladicle 
- [SIG Auth](https://qiita.com/hiyosi/items/bfbdd44a9fc528d22390) @hiyosi 
- [SIG CLI](https://qiita.com/superbrothers/items/e2b2bd0de7f621d68a1b) @superbrothers
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/89eecf3e79e7a156218a)　@yuanying 
- [SIG Storage](https://qiita.com/ysakashita/items/07fab50bff17c10fa07d) @ysakashita 
- SIG Network TBD 
- [SIG Scheduling](https://qiita.com/ordovicia/items/fc0053e0d27d5b0bcca0) @ordovicia 
- [SIG Node](https://qiita.com/y1r96/items/7032451f5200d111ed9a) @y1r96 


## Improvements that graduated to stable in Kubernetes v1.30

<!--
## Improvements that graduated to stable in Kubernetes v1.30 {#graduations-to-stable}

_This is a selection of some of the improvements that are now stable following the v1.30 release._
-->

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

### Robust VolumeManager reconstruction after kubelet restart ([SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage))

<!--
### Robust VolumeManager reconstruction after kubelet restart ([SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage))

This is a volume manager refactoring that allows the kubelet to populate additional information
about how existing volumes are mounted during the kubelet startup. In general, this makes volume
cleanup after kubelet restart or machine reboot more robust.

This does not bring any changes for user or cluster administrators. We used the feature process and
feature gate `NewVolumeManagerReconstruction` to be able to fall back to the previous behavior in
case something goes wrong. Now that the feature is stable, the feature gate is locked and cannot be
disabled.
-->

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

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

### Prevent unauthorized volume mode conversion during volume restore ([SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage))

<!--
### Prevent unauthorized volume mode conversion during volume restore ([SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage))

For Kubernetes v1.30, the control plane always prevents unauthorized changes to volume modes when
restoring a snapshot into a PersistentVolume. As a cluster administrator, you'll need to grant
permissions to the appropriate identity principals (for example: ServiceAccounts representing a
storage integration) if you need to allow that kind of change at restore time.

{{< warning >}}
Action required before upgrading. The `prevent-volume-mode-conversion` feature flag is enabled by
default in the external-provisioner `v4.0.0` and external-snapshotter `v7.0.0`. Volume mode change
will be rejected when creating a PVC from a VolumeSnapshot unless you perform the steps described in
the the "Urgent Upgrade Notes" sections for the [external-provisioner
4.0.0](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v4.0.0) and the
[external-snapshotter
v7.0.0](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v7.0.0). 
{{< /warning >}}

For more information on this feature also read [converting the volume mode of a
Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode). 
-->

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

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

この機能に関する詳細は[converting the volume mode of a Snapshot](https://kubernetes.io/docs/concepts/storage/volume-snapshots/#convert-volume-mode)をご参照ください。

- :pencil: こちらの詳細については @ysakashita さんの[Kubernetes: Prevent unauthorized volume mode conversion during volume restoreの動作検証 #kubernetes - Qiita](https://qiita.com/ysakashita/items/0bb38c39d70acd211da7) も参考になります。

### Pod Scheduling Readiness ([SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling))

<!--
### Pod Scheduling Readiness ([SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling))

_Pod scheduling readiness_ graduates to stable this release, after being promoted to beta in
Kubernetes v1.27.

This now-stable feature lets Kubernetes avoid trying to schedule a Pod that has been defined, when
the cluster doesn't yet have the resources provisioned to allow actually binding that Pod to a node.
That's not the only use case; the custom control on whether a Pod can be allowed to schedule also
lets you implement quota mechanisms, security controls, and more.

Crucially, marking these Pods as exempt from scheduling cuts the work that the scheduler would
otherwise do, churning through Pods that can't or won't schedule onto the nodes your cluster
currently has. If you have [cluster
autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/) active, using scheduling
gates doesn't just cut the load on the scheduler, it can also save money. Without scheduling gates,
the autoscaler might otherwise launch a node that doesn't need to be started.

In Kubernetes v1.30, by specifying (or removing) a Pod's `.spec.schedulingGates`, you can control
when a Pod is ready to be considered for scheduling. This is a stable feature and is now formally
part of the Kubernetes API definition for Pod.
-->

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

重要なことは、これらのPodをスケジューリングの除外としてマークすることにより、スケジューラが現在クラスタにあるノードにスケジューリングできない、あるいはスケジューリングしようとしないPodを処理する作業を削減できることです。もし[cluster autoscaling](https://kubernetes.io/docs/concepts/cluster-administration/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](https://github.com/kubernetes/community/tree/master/sig-scheduling))

<!--
### Min domains in PodTopologySpread ([SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling))

The `minDomains` parameter for PodTopologySpread constraints graduates to stable this release, which
allows you to define the minimum number of domains. This feature is designed to be used with Cluster
Autoscaler.

If you previously attempted use and there weren't enough domains already present, Pods would be
marked as unschedulable. The Cluster Autoscaler would then provision node(s) in new domain(s), and
you'd eventually get Pods spreading over enough domains.
-->

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

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


### Go workspaces for k/k ([SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture))

<!--
### Go workspaces for k/k ([SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture))

The Kubernetes repo now uses Go workspaces. This should not impact end users at all, but does have a
impact for developers of downstream projects. Switching to workspaces caused some breaking changes
in the flags to the various [k8s.io/code-generator](https://github.com/kubernetes/code-generator)
tools. Downstream consumers should look at
[`staging/src/k8s.io/code-generator/kube_codegen.sh`](https://github.com/kubernetes/code-generator/blob/master/kube_codegen.sh)
to see the changes.

For full details on the changes and reasons why Go workspaces was introduced, read [Using Go
workspaces in Kubernetes](https://www.kubernetes.dev/blog/2024/03/19/go-workspaces-in-kubernetes/).
-->

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

なぜGo workspaceを導入したかの理由や変更についての詳細は[Using Go workspaces in Kubernetes](https://www.kubernetes.dev/blog/2024/03/19/go-workspaces-in-kubernetes/)をご参照ください。


## Improvements that graduated to beta in Kubernetes v1.30

<!--
## Improvements that graduated to beta in Kubernetes v1.30 {#graduations-to-beta}

_This is a selection of some of the improvements that are now beta following the v1.30 release._
-->

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

### Node log query ([SIG Windows](https://github.com/kubernetes/community/tree/master/sig-windows))

<!--
### Node log query ([SIG Windows](https://github.com/kubernetes/community/tree/master/sig-windows))

To help with debugging issues on nodes, Kubernetes v1.27 introduced a feature that allows fetching
logs of services running on the node. To use the feature, ensure that the `NodeLogQuery` feature
gate is enabled for that node, and that the kubelet configuration options `enableSystemLogHandler`
and `enableSystemLogQuery` are both set to true.

Following the v1.30 release, this is now beta (you still need to enable the feature to use it,
though).

On Linux the assumption is that service logs are available via journald. On Windows the assumption
is that service logs are available in the application log provider. Logs are also available by
reading files within `/var/log/` (Linux) or `C:\var\log\` (Windows). For more information, see the
[log query](/docs/concepts/cluster-administration/system-logs/#log-query) documentation.
-->

ノード上で問題のデバッグを手伝うために、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](https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#log-query)ドキュメントを確認してください。


### CRD validation ratcheting ([SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery))

<!--
### CRD validation ratcheting ([SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery))

You need to enable the `CRDValidationRatcheting` [feature
gate](/docs/reference/command-line-tools-reference/feature-gates/) to use this behavior, which then
applies to all CustomResourceDefinitions in your cluster.

Provided you enabled the feature gate, Kubernetes implements _validation racheting_ for
CustomResourceDefinitions. The API server is willing to accept updates to resources that are not valid
after the update, provided that each part of the resource that failed to validate was not changed by
the update operation. In other words, any invalid part of the resource that remains invalid must
have already been wrong. You cannot use this mechanism to update a valid resource so that it becomes
invalid.

This feature allows authors of CRDs to confidently add new validations to the OpenAPIV3 schema under
certain conditions. Users can update to the new schema safely without bumping the version of the object or breaking workflows.
-->

この機能を利用するには`CRDValidationRatcheting` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)を有効化する必要があり、それによりクラスタの全てのCustomResourceDefinitionsへ適用されます。

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

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


### Contextual logging ([SIG Instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation))

<!--
### Contextual logging ([SIG Instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation))

Contextual Logging advances to beta in this release, empowering developers and operators to inject
customizable, correlatable contextual details like service names and transaction IDs into logs
through `WithValues` and `WithName`. This enhancement simplifies the correlation and analysis of log
data across distributed systems, significantly improving the efficiency of troubleshooting efforts.
By offering a clearer insight into the workings of your Kubernetes environments, Contextual Logging
ensures that operational challenges are more manageable, marking a notable step forward in
Kubernetes observability.
-->

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


### Make Kubernetes aware of the LoadBalancer behaviour ([SIG Network](https://github.com/kubernetes/community/tree/master/sig-network))

<!--
### Make Kubernetes aware of the LoadBalancer behaviour ([SIG Network](https://github.com/kubernetes/community/tree/master/sig-network))

The `LoadBalancerIPMode` feature gate is now beta and is now enabled by default. This feature allows
you to set the `.status.loadBalancer.ingress.ipMode` for a Service with `type` set to
`LoadBalancer`. The `.status.loadBalancer.ingress.ipMode` specifies how the load-balancer IP
behaves. It may be specified only when the `.status.loadBalancer.ingress.ip` field is also
specified. See more details about [specifying IPMode of load balancer
status](/docs/concepts/services-networking/service/#load-balancer-ip-mode).
-->

`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](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-ip-mode)をご確認ください。


### Structured Authentication Configuration ([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth))

<!--
### Structured Authentication Configuration ([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth))

_Structured Authentication Configuration_ graduates to beta in this release.

Kubernetes has had a long-standing need for a more flexible and extensible
authentication system. The current system, while powerful, has some limitations
that make it difficult to use in certain scenarios. For example, it is not
possible to use multiple authenticators of the same type (e.g., multiple JWT
authenticators) or to change the configuration without restarting the API server. The Structured Authentication Configuration feature is the first step towards addressing these limitations and providing a more flexible and extensible way to configure authentication in Kubernetes. See more details about [structured authentication configuration](/docs/reference/access-authn-authz/authentication/#using-authentication-configuration).
-->

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

- :pencil: @hiyosi さんの [K8s StructuredAuthenticationConfiguration](https://qiita.com/hiyosi/items/173d8338c742071fe8a1) もあわせてご参照ください

### Structured Authorization Configuration ([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth))

<!--
### Structured Authorization Configuration ([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth))

_Structured Authorization Configuration_ graduates to beta in this release.

Kubernetes continues to evolve to meet the intricate requirements of system
administrators and developers alike. A critical aspect of Kubernetes that
ensures the security and integrity of the cluster is the API server
authorization. Until recently, the configuration of the authorization chain in
kube-apiserver was somewhat rigid, limited to a set of command-line flags and
allowing only a single webhook in the authorization chain. This approach, while
functional, restricted the flexibility needed by cluster administrators to
define complex, fine-grained authorization policies. The latest Structured
Authorization Configuration feature aims to revolutionize this aspect by introducing 
a more structured and versatile way to configure the authorization chain, focusing 
on enabling multiple webhooks and providing explicit control mechanisms. See more
details about [structured authorization configuration](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file).
-->

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

- :pencil: @hiyosi さんの[K8s StructuredAuthorizationConfiguration](https://qiita.com/hiyosi/items/7c396ce98ba3ce42833c)もあわせてご参照ください


## New alpha features

<!--
## New alpha features
-->

### Speed up recursive SELinux label change ([SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage))

<!--
### Speed up recursive SELinux label change ([SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage))

From the v1.27 release, Kubernetes already included an optimization that sets SELinux labels on the
contents of volumes, using only constant time. Kubernetes achieves that speed up using a mount
option. The slower legacy behavior requires the container runtime to recursively walk through the
whole volumes and apply SELinux labelling individually to each file and directory; this is
especially noticable for volumes with large amount of files and directories.

Kubernetes v1.27 graduated this feature as beta, but limited it to ReadWriteOncePod volumes. The
corresponding feature gate is `SELinuxMountReadWriteOncePod`. It's still enabled by default and
remains beta in v1.30.

Kubernetes v1.30 extends support for SELinux mount option to **all** volumes as alpha, with a
separate feature gate: `SELinuxMount`. This feature gate introduces a behavioral change when
multiple Pods with different SELinux labels share the same volume. See
[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1710-selinux-relabeling#behavioral-changes)
for details.

We strongly encourage users that run Kubernetes with SELinux enabled to test this feature and
provide any feedback on the [KEP issue](https://kep.k8s.io/1710).

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

Both feature gates `SELinuxMountReadWriteOncePod` and `SELinuxMount` must be enabled to test this
feature on all volumes.

This feature has no effect on Windows nodes or on Linux nodes without SELinux support.
-->

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](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1710-selinux-relabeling#behavioral-changes)をご参照ください。

SELinuxを有効化したKubernetesを実行しているユーザには、この機能をテストしていただき、[KEP issue](https://kep.k8s.io/1710)にフィードバックを提供していただくことを強くお勧めします。

| 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](https://github.com/kubernetes/community/tree/master/sig-node))

<!--
### Recursive Read-only (RRO) mounts ([SIG Node](https://github.com/kubernetes/community/tree/master/sig-node))

Introducing Recursive Read-Only (RRO) Mounts in alpha this release, you'll find a new layer of
security for your data. This feature lets you set volumes and their submounts as read-only,
preventing accidental modifications. Imagine deploying a critical application where data integrity
is key—RRO Mounts ensure that your data stays untouched, reinforcing your cluster's security with an
extra safeguard. This is especially crucial in tightly controlled environments, where even the
slightest change can have significant implications.
-->

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


### Job success/completion policy ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps))

<!--
### Job success/completion policy ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps))

From Kubernetes v1.30, indexed Jobs support `.spec.successPolicy` to define when a Job can be
declared succeeded based on succeeded Pods. This allows you to define two types of criteria:

- `succeededIndexes` indicates that the Job can be declared succeeded when these indexes succeeded,
  even if other indexes failed.
- `succeededCount` indicates that the Job can be declared succeeded when the number of succeeded
  Indexes reaches this criterion.

After the Job meets the success policy, the Job controller terminates the lingering Pods.
-->

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

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

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


### Traffic distribution for services ([SIG Network](https://github.com/kubernetes/community/tree/master/sig-network))

<!--
### Traffic distribution for services ([SIG Network](https://github.com/kubernetes/community/tree/master/sig-network))

Kubernetes v1.30 introduces the `spec.trafficDistribution` field within a Kubernetes Service as
alpha. This allows you to express preferences for how traffic should be routed to Service endpoints.
While [traffic policies](/docs/reference/networking/virtual-ips/#traffic-policies) focus on strict
semantic guarantees, traffic distribution allows you to express _preferences_ (such as routing to
topologically closer endpoints). This can help optimize for performance, cost, or reliability. You
can use this field by enabling the `ServiceTrafficDistribution` feature gate for your cluster and
all of its nodes. In Kubernetes v1.30, the following field value is supported: 

`PreferClose`: Indicates a preference for routing traffic to endpoints that are topologically
proximate to the client. The interpretation of "topologically proximate" may vary across
implementations and could encompass endpoints within the same node, rack, zone, or even region.
Setting this value gives implementations permission to make different tradeoffs, for example
optimizing for proximity rather than equal distribution of load. You should not set this value if
such tradeoffs are not acceptable.

If the field is not set, the implementation (like kube-proxy) will apply its default routing
strategy.

See [Traffic Distribution](/docs/reference/networking/virtual-ips/#traffic-distribution) for more 
details. 
-->

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

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

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

詳細は[Traffic Distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution)をご参照ください。


### Storage Version Migration ([SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery))

<!--
### Storage Version Migration ([SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery))
Kubernetes v1.30 introduces a new built-in API for _StorageVersionMigration_.
Kubernetes relies on API data being actively re-written, to support some
maintenance activities related to at rest storage. Two prominent examples are
the versioned schema of stored resources (that is, the preferred storage schema
changing from v1 to v2 for a given resource) and encryption at rest (that is,
rewriting stale data based on a change in how the data should be encrypted).

StorageVersionMigration is alpha API which was available [out of tree](https://github.com/kubernetes-sigs/kube-storage-version-migrator) before.

See [storage version migration](/docs/tasks/manage-kubernetes-objects/storage-version-migration) for more details.
-->

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

StorageVersionMigrationは以前は[out of tree](https://github.com/kubernetes-sigs/kube-storage-version-migrator)で利用可能であったalpha APIです。
詳細はSee [storage version migration](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/storage-version-migration)をご参照ください。

<!--
## Graduations, deprecations and removals for Kubernetes v1.30
-->


### Graduated to stable

<!--
### Graduated to stable

This lists all the features that graduated to stable (also known as _general availability_). For a
full list of updates including new features and graduations from alpha to beta, see the [release
notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md).

This release includes a total of 17 enhancements promoted to Stable:

- [Container Resource based Pod Autoscaling](https://kep.k8s.io/1610)
- [Remove transient node predicates from KCCM's service controller](https://kep.k8s.io/3458)
- [Go workspaces for k/k](https://kep.k8s.io/4402)
- [Reduction of Secret-based Service Account Tokens](https://kep.k8s.io/2799)
- [CEL for Admission Control](https://kep.k8s.io/3488)
- [CEL-based admission webhook match conditions](https://kep.k8s.io/3716)
- [Pod Scheduling Readiness](https://kep.k8s.io/3521)
- [Min domains in PodTopologySpread](https://kep.k8s.io/3022)
- [Prevent unauthorised volume mode conversion during volume restore](https://kep.k8s.io/3141)
- [API Server Tracing](https://kep.k8s.io/647)
- [Cloud Dual-Stack --node-ip Handling](https://kep.k8s.io/3705)
- [AppArmor support](https://kep.k8s.io/24)
- [Robust VolumeManager reconstruction after kubelet restart](https://kep.k8s.io/3756)
- [kubectl delete: Add interactive(-i) flag](https://kep.k8s.io/3895)
- [Metric cardinality enforcement](https://kep.k8s.io/2305)
- [Field `status.hostIPs` added for Pod](https://kep.k8s.io/2681)
- [Aggregated Discovery](https://kep.k8s.io/3352)
-->

このリストはすべてstable(一般的にGeneral availabilityとして知られている)へ昇格した機能です。新しい機能やalphaからbetaへ昇格したものを服すアップデートの全てのリストは[release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md)をご参照ください。

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

- [Container Resource based Pod Autoscaling](https://kep.k8s.io/1610)
- [Remove transient node predicates from KCCM's service controller](https://kep.k8s.io/3458)
- [Go workspaces for k/k](https://kep.k8s.io/4402)
- [Reduction of Secret-based Service Account Tokens](https://kep.k8s.io/2799)
- [CEL for Admission Control](https://kep.k8s.io/3488)
- [CEL-based admission webhook match conditions](https://kep.k8s.io/3716)
- [Pod Scheduling Readiness](https://kep.k8s.io/3521)
- [Min domains in PodTopologySpread](https://kep.k8s.io/3022)
- [Prevent unauthorised volume mode conversion during volume restore](https://kep.k8s.io/3141)
- [API Server Tracing](https://kep.k8s.io/647)
- [Cloud Dual-Stack --node-ip Handling](https://kep.k8s.io/3705)
- [AppArmor support](https://kep.k8s.io/24)
- [Robust VolumeManager reconstruction after kubelet restart](https://kep.k8s.io/3756)
- [kubectl delete: Add interactive(-i) flag](https://kep.k8s.io/3895)
- [Metric cardinality enforcement](https://kep.k8s.io/2305)
- [Field `status.hostIPs` added for Pod](https://kep.k8s.io/2681)
- [Aggregated Discovery](https://kep.k8s.io/3352)


### Deprecations and removals

<!--
### Deprecations and removals
-->

#### Removed the SecurityContextDeny admission plugin, deprecated since v1.27 

<!--
#### Removed the SecurityContextDeny admission plugin, deprecated since v1.27 
([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth), [SIG Security](https://github.com/kubernetes/community/tree/master/sig-security), and [SIG Testing](https://github.com/kubernetes/community/tree/master/sig-testing))
With the removal of the SecurityContextDeny admission plugin, the Pod Security Admission plugin,
available since v1.25, is recommended instead.
-->

([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth), [SIG Security](https://github.com/kubernetes/community/tree/master/sig-security), と [SIG Testing](https://github.com/kubernetes/community/tree/master/sig-testing)) SecurityContextDeny admission pluginが削除されたため、代わりにv1.25から利用できるPod Security Admissionプラグインが推奨されます。

## Urgent Upgrade Notes

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

- なし
  - :pencil: 今回このフィールドはありませんでしたが、[いくつかの廃止された機能](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md#deprecation)があるため、そちらの影響がないか確認された方が良さそうです。