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

# はじめに

このエントリは、Kubernetes 1.24 の [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md) からWhat's new!とアップグレード時の注意事項、各変更点についてまとめたページへのリンクです。
詳細については各まとめページを参照してください。

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

- [Metrics Changes と SIG Instrumentation](https://qiita.com/watawuwu/items/fe9b8e7f8d3089813020) @watawuwu
- [SIG Apps](https://qiita.com/yosshi_/items/08539d8f9e14da73c152) @yosshi_ 
- [SIG API Machinery](https://qiita.com/Ladicle/items/f5308c1d63713dc1bd49) @Ladicle
- [SIG Auth](https://qiita.com/hiyosi/items/b46d8bc62a103179374c) @hiyosi
- [SIG CLI](https://qiita.com/superbrothers/items/2b1164b2634754bdd3e7) @superbrothers
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/87b4dd1a266410c7a483) @yuanying
- [SIG Storage](https://qiita.com/ysakashita/items/b90daf37bc3d1f2fa437) @ysakashita
- [SIG Network](https://qiita.com/tkusumi/items/8ae63017abf763b0a22d) @tkusumi
- [SIG Scheduling](https://qiita.com/everpeace/items/3cf879bfe1464947572b) @everpeace 
- [SIG Node](https://qiita.com/y1r96/items/37483ffd17e21f060331) @y1r96 

# What's new!

## Dockershim Removed from kubelet

<!--
After its deprecation in v1.20, the dockershim component has been removed from the kubelet.
From v1.24 onwards, you will need to either use one of the other [supported runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) (such as containerd or CRI-O)
or use cri-dockerd if you are relying on Docker Engine as your container runtime.
For more information about ensuring your cluster is ready for this removal, please
see [this guide](/blog/2022/03/31/ready-for-dockershim-removal/).
-->

v1.20で非推奨となっていたdockeshimコンポーネントはkubeletから削除されました。
v1.24移行、サポートされているランタイム(例えばcontainerdやCRI-Oなど)の一つを利用するか、コンテナランタイムとしてDocker Engineへ依存している場合はcri-dockerdを利用する必要があります。
より詳細な情報については、こちらの[ガイド](https://kubernetes.io/blog/2022/03/31/ready-for-dockershim-removal/)をご参照ください。

- :memo: cri-dockerdは[こちら](https://github.com/Mirantis/cri-dockerd)

## Beta APIs Off by Default

<!--
[New beta APIs will not be enabled in clusters by default](https://github.com/kubernetes/enhancements/issues/3136).
Existing beta APIs and new versions of existing beta APIs, will continue to be enabled by default.
-->

[新しいベータAPIはデフォルトでクラスタでは有効化されなくなります](https://github.com/kubernetes/enhancements/issues/3136)
既存のベータAPIと既存のベータAPIの新しいバージョンはデフォルトで有効のままとなります。

- :memo: あくまでAPIの話であり、Feature Gatesのベータとは別の話のようです

## Signing Release Artifacts

<!--
Release artifacts are [signed](https://github.com/kubernetes/enhancements/issues/3031) using [cosign](https://github.com/sigstore/cosign)
signatures
and there is experimental support for [verifying image signatures](https://kubernetes.io/docs/tasks/administer-cluster/verify-signed-images/).
Signing and verification of release artifacts is part of [increasing software supply chain security for the Kubernetes release process](https://github.com/kubernetes/enhancements/issues/3027).
-->

リリースの成果物は[cosign](https://github.com/sigstore/cosign)を用いて[署名](https://github.com/kubernetes/enhancements/issues/3031)され、イメージの署名検証が実験的にサポートされています。
リリース成果物の署名と検証は、Kubernetesのリリースプロセスにおけるソフトウェアサプライチェーンセキュリティを向上させるための一部です。

## OpenAPI v3

<!--
Kubernetes 1.24 offers beta support for publishing its APIs in the [OpenAPI v3 format](https://github.com/kubernetes/enhancements/issues/2896).
-->

Kubernetes 1.24は[OpenAPI v3 format](https://github.com/kubernetes/enhancements/issues/2896)を用いてAPIを公開する機能をベータ版としてサポートするようになりました。

## Storage Capacity and Volume Expansion Are Generally Available

<!--
[Storage capacity tracking](https://github.com/kubernetes/enhancements/issues/1472)
supports exposing currently available storage capacity via [CSIStorageCapacity objects](https://kubernetes.io/docs/concepts/storage/storage-capacity/#api)
and enhances scheduling of pods that use CSI volumes with late binding.

[Volume expansion](https://github.com/kubernetes/enhancements/issues/284) adds support
for resizing existing persistent volumes.
-->

[Storage capacity tracking](https://github.com/kubernetes/enhancements/issues/1472)は、[CSIStorageCapacity オブジェクト](https://kubernetes.io/docs/concepts/storage/storage-capacity/#api)を介した現在利用可能なストレージ容量の公開をサポートし、遅れてバインドするCSIボリュームを使用するPodのスケジューリングを強化します。

## NonPreemptingPriority to Stable

<!--
This feature adds [a new option to PriorityClasses](https://github.com/kubernetes/enhancements/issues/902),
which can enable or disable pod preemption.
-->

この機能はPod preemptionを有効・無効化できる[PriorityClassesへの新しいオプション](https://github.com/kubernetes/enhancements/issues/902)を追加します。

## Storage Plugin Migration

<!--
There is work under way to [migrate the internals of in-tree storage plugins](https://github.com/kubernetes/enhancements/issues/625) to call out to CSI Plugins,
while maintaining the original API.
The [Azure Disk](https://github.com/kubernetes/enhancements/issues/1490)
and [OpenStack Cinder](https://github.com/kubernetes/enhancements/issues/1489) plugins
have both been migrated.
-->

オリジナルのAPIはメンテナンスしながら、CSI Plugins を呼び出すために[in-tree storage pluginsを移行する](https://github.com/kubernetes/enhancements/issues/625) 作業が進行中です。
Azure DiskとOpenStack Cinderのプラグインは両方とも移行されています。

## gRPC Probes Graduate to Beta

<!--
With Kubernetes 1.24, the [gRPC probes functionality](https://github.com/kubernetes/enhancements/issues/2727)
has entered beta and is available by default. You can now [configure startup, liveness, and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for your gRPC app
natively within Kubernetes, without exposing an HTTP endpoint or
using an extra executable.
-->

Kubernetes v1.24を用いると、[gRPC probe機能](https://github.com/kubernetes/enhancements/issues/2727)がbetaとして導入され、デフォルトで有効可能です。
HTTPエンドポイントを公開したり、追加の実行ファイルの利用なしにKubernetes内でネイティブにgRPCアプリケーションの[startup/liveness/readiness probeを設定](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)可能となりました。

## Kubelet Credential Provider Graduates to Beta

<!--
Originally released as Alpha in Kubernetes 1.20, the kubelet's support for
[image credential providers](https://kubernetes.io/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/)
has now graduated to Beta.
This allows the kubelet to dynamically retrieve credentials for a container image registry
using exec plugins, rather than storing credentials on the node's filesystem.
-->

初めにKubernetes 1.20でアルファとしてリリースされたkubeletの[image credential providers](https://kubernetes.io/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/)のサポートはbetaへ昇格しました。
これはkubeletがexecプラグインを利用して、ノードのファイルシステムへクレデンシャルを保存せずに、コンテナイメージのためのクレデンシャルを動的に取得可能とします。

## Contextual Logging in Alpha

<!--
Kubernetes 1.24 has introduced [contextual logging](https://github.com/kubernetes/enhancements/issues/3077)
that enables the caller of a function to control all aspects of logging (output formatting, verbosity, additional values and names).
-->

Kubernetes 1.24は[contextual logging](https://github.com/kubernetes/enhancements/issues/3077)を導入しました。
これは関数の呼び出し元がロギングの全ての側面(出力フォーマット、冗長性、追加の値や名前) を制御できるようにするものです。

- :memo: klogにこの機能は入っているようですが、Kubernetes v1.24.0のソースコードを確認した限りだとまだ利用されてなさそう？

## Avoiding Collisions in IP allocation to Services

<!--
Kubernetes 1.24 introduced a new opt-in feature that allows you to
[soft-reserve a range for static IP address assignments](https://kubernetes.io/docs/concepts/services-networking/service/#service-ip-static-sub-range)
to Services.
With the manual enablement of this feature, the cluster will prefer automatic assignment from
the pool of Service IP addresses thereby reducing the risk of collision.

A Service `ClusterIP` can be assigned:

* dynamically, which means the cluster will automatically pick a free IP within the configured Service IP range.
* statically, which means the user will set one IP within the configured Service IP range.

Service `ClusterIP` are unique, hence, trying to create a Service with a `ClusterIP` that has already been allocated will return an error.
-->

Kubernetes 1.24では、Serviceに固定IPアドレスを割り当てるための範囲を[ソフトリザーブできる新しいオプトイン機能](https://kubernetes.io/docs/concepts/services-networking/service/#service-ip-static-sub-range)が導入されました。
この機能を有効にすると、クラスターはServiceのIPアドレスのプールから自動割り当てを優先するため、衝突のリスクが軽減されます。

Serviceの`ClusterIP`は以下のようにアサインされます:
- 動的に割り当てる: 設定されたService IPレンジ内の空いているIPをクラスタが自動的に選択します
- 静的に割り当てる: 設定されたService IPレンジ内の一つのIPをユーザがセットします

サービス`ClusterIP`はユニークであるため、すでに割り当てられている`ClusterIP`を使用してサービスを作成しようとするとエラーが返されます。

- :memo: この機能によりCoreDNSなど特定のClusterIPアドレスが必要なServiceが、他のServiceにそのアドレスを取得されづらくできるため便利そうです。

# アップグレード時の注意事項

<!--
- Docker runtime support using dockershim in the kubelet is now completely removed in 1.24. The kubelet used to have a module called dockershim, which implements CRI support for Docker, and it has seen maintenance issues in the Kubernetes community. From 1.24 onwards, please move to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. ([#97252](https://github.com/kubernetes/kubernetes/pull/97252), [@dims](https://github.com/dims))
-->

- kubelet内のdockershimを用いたDocker runtimeはv1.24で完全に削除されました。kubeletは以前はdockershimと呼ばれるdockerのためのCRIを実装しているモジュールを利用しており、それはKubernetes community内でメンテナンスの問題がありました。1.24以降、利用可能になり次第CRIを本格的に実装したコンテナランタイム（v1alpha1またはv1準拠のもの）に移行してください。([#97252](https://github.com/kubernetes/kubernetes/pull/97252), [@dims](https://github.com/dims))

<!--
- Fixed bug with leads to Node goes `Not-ready` state when credentials for vCenter stored in a secret and Zones feature is in use. Zone labels setup moved to KCM component, kubelet skips this step during startup in such case. If credentials stored in cloud-provider config file as plaintext current behaviour does not change and no action required. For proper functioning `kube-system:vsphere-legacy-cloud-provider` should be allowed to update node object if vCenter credentials stored in secret and Zone feature used. ([#101028](https://github.com/kubernetes/kubernetes/pull/101028), [@lobziik](https://github.com/lobziik))
-->

- Secretに保存されたvCenterの認証情報とZones機能が使用されている場合、Nodeが`Not-ready`となるバグを修正しました。ゾーンラベルのセットアップは KCM コンポーネントに移動し、kubelet はこのような場合、起動時にこのステップをスキップします。クラウドプロバイダー設定ファイルにプレーンテキストで保存された資格情報の場合、現在の動作は変更されず、アクションは必要ありません。適切な機能を実現するためには、Secret および Zone 機能で保存された vCenter 認証情報を使用している場合、`kube-system:vsphere-legacy-cloud-provider` がノードオブジェクトを更新できるようにする必要があります。([#101028](https://github.com/kubernetes/kubernetes/pull/101028), [@lobziik](https://github.com/lobziik))。

<!--
- The `LegacyServiceAccountTokenNoAutoGeneration` feature gate is beta, and enabled by default. When enabled, Secret API objects containing service account tokens are no longer auto-generated for every ServiceAccount. Use the [TokenRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API to acquire service account tokens, or if a non-expiring token is required, create a Secret API object for the token controller to populate with a service account token by following this [guide](https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets). ([#108309](https://github.com/kubernetes/kubernetes/pull/108309), [@zshihang](https://github.com/zshihang))
-->

- `LegacyServiceAccountTokenNoAutoGeneration` feature gateがベータとなり、デフォルトで有効化されます。有効化されるとService account tokenを含むSecret APIオブジェクトは自動生成されません。service account tokenを取得するための[TokenRequest](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) APIを利用するか、もし期限切れを起こさないトークンが必要な場合は、[このガイド](https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets)にしたがってService account tokenを追加するためのtoken controllerのためのSecret APIオブジェクトを作成してください。([#108309](https://github.com/kubernetes/kubernetes/pull/108309), [@zshihang](https://github.com/zshihang))

<!--
- The calculations for Pod topology spread skew now exclude nodes that
  don't match the node affinity/selector. This may lead to unschedulable pods if you previously had pods
  matching the spreading selector on those excluded nodes (not matching the node affinity/selector),
  especially when the `topologyKey` is not node-level. Revisit the node affinity and/or pod selector in the
  topology spread constraints to avoid this scenario. ([#107009](https://github.com/kubernetes/kubernetes/pull/107009), [@kerthcet](https://github.com/kerthcet))
-->

- Pod topology spreadのskewのための計算はnode affinity/selectorにマッチしないノードを除外するようになりました。これにより以前は除外されるノードでspreading selectorにマッチしていたpodが、特に`topologyKey`がノードレベルでないときに、スケジュールできないPodとなる可能性があります。このシナリオを避けるために、topology spread constraints利用時のnode affinityやpod selectorを再検討してください。([#107009](https://github.com/kubernetes/kubernetes/pull/107009), [@kerthcet](https://github.com/kerthcet))

<!--
- Remove the deprecated flag `--experimental-check-node-capabilities-before-mount`. With CSI now GA, there is a better alternative. Remove any use of  `--experimental-check-node-capabilities-before-mount` from your kubelet scripts or manifests. ([#104732](https://github.com/kubernetes/kubernetes/pull/104732), [@mengjiao-liu](https://github.com/mengjiao-liu))
-->

- 非推奨となっていた`--experimental-check-node-capabilities-before-mount`フラグが削除されました。CSIのGAに伴い、よりよい代替手段があります。kubeletのscriptやマニフェストから`--experimental-check-node-capabilities-before-mount`の利用している部分を削除してください。([#104732](https://github.com/kubernetes/kubernetes/pull/104732), [@mengjiao-liu](https://github.com/mengjiao-liu))

<!--
- `kubeadm.k8s.io/v1beta2` has been deprecated and will be removed in a future release, possibly in 3 releases (one year). You should start using `kubeadm.k8s.io/v1beta3` for new clusters. To migrate your old configuration files on disk you can use the `kubeadm config migrate` command. ([#107013](https://github.com/kubernetes/kubernetes/pull/107013), [@pacoxu](https://github.com/pacoxu))
-->

- `kubeadm.k8s.io/v1beta2`は非推奨となり将来のリリースおそらく3リリース(1年)で削除予定です。新しいクラスタのためには`kubeadm.k8s.io/v1beta3`を利用し始めるべきです。古い設定ファイルからマイグレートするためには`kubeadm config migrate`コマンドが利用できます。

<!--
- Kubeadm: default the kubeadm configuration to the containerd socket (Unix: `unix:///var/run/containerd/containerd.sock`, Windows: `npipe:////./pipe/containerd-containerd`) instead of the one for Docker. If the `Init|JoinConfiguration.nodeRegistration.criSocket` field is empty during cluster creation and multiple sockets are found on the host always throw an error and ask the user to specify which one to use by setting the value in the field. Make sure you update any kubeadm configuration files on disk, to not include the dockershim socket unless you are still using kubelet version < 1.24 with kubeadm >= 1.24. Remove the DockerValidor and ServiceCheck for the `docker` service from kubeadm preflight. Docker is no longer special cased during host validation and ideally this task should be done in the now external cri-dockerd project where the importance of the compatibility matters. Use `crictl` for all communication with CRI sockets for actions like pulling images and obtaining a list of running containers instead of using the docker CLI in the case of Docker. ([#107317](https://github.com/kubernetes/kubernetes/pull/107317), [@neolit123](https://github.com/neolit123))
-->

- Kubeadm: dockerの設定ではなくcontainerd socket(Unix: `unix:///var/run/containerd/containerd.sock`, Windows: `npipe:////./pipe/containerd-containerd`)をデフォルトとして利用するようになりました。クラスタ作成時に `Init|JoinConfiguration.nodeRegistration.criSocket` フィールドが空で、ホスト上に複数のソケットが見つかった場合は常にエラーをスローして、フィールドに値を設定することで使用するソケットを指定するようにユーザーに要求します。kubeadm設定ファイルを更新し、dockershimソケットを含めないようにしてください（kubeletバージョン<1.24かつkubeadm >= 1.24を使用している場合を除く）。kubeadm のpreflightから `docker` サービス用の DockerValidor と ServiceCheck を削除しました。ホスト検証時にDockerはもはや特別なケースではなく、理想的にはこのタスクは互換性の問題が重要となるcri-dockerdプロジェクトで処理されるべきタスクです。Docker の場合、docker CLI を使用する代わりに、イメージの取得や実行中のコンテナのリストの取得などの CRI ソケットとのすべての通信に `crictl` を使用するようにしました。([#107317](https://github.com/kubernetes/kubernetes/pull/107317), [@neolit123](https://github.com/neolit123))

<!--
- The feature gate was mentioned as `csiMigrationRBD` where it should have been `CSIMigrationRBD` to be in parity with other migration plugins. This release correct the same and keep it as `CSIMigrationRBD`.
    users who have configured this feature gate as `csiMigrationRBD` has to reconfigure the same to `CSIMigrationRBD` from this release. ([#107554](https://github.com/kubernetes/kubernetes/pull/107554), [@humblec](https://github.com/humblec))
-->

- 他のマイグレーションプラグインと同等にするために`CSIMigrationRBD`となるべき場所で`csiMigrationRBD`としてfeature gatesで指定されていました。このリリースではこれを修正し、`csiMigrationRBD`として設定しているユーザーは、このリリースから`CSIMigrationRBD`に再設定する必要があります。([#107554](https://github.com/kubernetes/kubernetes/pull/107554), [@humblec](https://github.com/humblec))

<!--
- The experimental dynamic log sanitization feature has been deprecated and removed in the 1.24 release. The feature is no longer available for use. ([#107207](https://github.com/kubernetes/kubernetes/pull/107207), [@ehashman](https://github.com/ehashman))
-->

- 実験的な動的なログのサニタイズ機能はv1.24で非推奨となり削除されます。この機能は利用できなくなりました。([#107207](https://github.com/kubernetes/kubernetes/pull/107207), [@ehashman](https://github.com/ehashman))
  - :memo: 新しいログの機能をブロック要素となること、機能のサポート負荷などが原因でalpha機能だったため削除されるようです

<!--
- Kubeadm: apply `second stage` of the plan to migrate kubeadm away from the usage of the word `master` in labels and taints. For new clusters, the label `node-role.kubernetes.io/master` will no longer be added to control plane nodes, only the label `node-role.kubernetes.io/control-plane` will be added. For clusters that are being upgraded to 1.24 with `kubeadm upgrade apply`, the command will remove the label `node-role.kubernetes.io/master` from existing control plane nodes. For new clusters, both the old taint `node-role.kubernetes.io/master:NoSchedule` and new taint `node-role.kubernetes.io/control-plane:NoSchedule` will be added to control plane nodes. In release 1.20 (`first stage`), a release note instructed to preemptively tolerate the new taint. For clusters that are being upgraded to 1.24 with `kubeadm upgrade apply`, the command will add the new taint `node-role.kubernetes.io/control-plane:NoSchedule` to existing control plane nodes. Please adapt your infrastructure to these changes. In 1.25 the old taint `node-role.kubernetes.io/master:NoSchedule` will be removed. ([#107533](https://github.com/kubernetes/kubernetes/pull/107533), [@neolit123](https://github.com/neolit123))
-->

- Kubeadm: kubeadmがラベルやtaintsで`master`という単語を使わないように移行する計画の`second stage`を適用しました。新しいクラスタでは、コントロールプレーンノードに `node-role.kubernetes.io/master` というラベルは追加されなくなり、`node-role.kubernetes.io/control-plane` というラベルだけが追加されます。`kubeadm upgrade apply` で 1.24 にアップグレードするクラスタでは、このコマンドは既存のコントロールプレーンノードから `node-role.kubernetes.io/master` というラベルを削除します。新しいクラスタでは、古い taint `node-role.kubernetes.io/master:NoSchedule` と新しい taint `node-role.kubernetes.io/control-plane:NoSchedule` の両方が制御プレーンノードに追加されます。リリース1.20 (`first stage`) では、リリースノートで新しいtaintを先取りして許容するように指示されています。`kubeadm upgrade apply`で1.24にアップグレードするクラスタでは、コマンドは既存のコントロールプレーンノードに新しいtaint `node-role.kubernetes.io/control-plane:NoSchedule` を追加することになるでしょう。これらの変更にあなたのインフラを適応させてください。1.25 では、古いtaint `node-role.kubernetes.io/master:NoSchedule` は削除される予定です。([#107533](https://github.com/kubernetes/kubernetes/pull/107533), [@neolit123](https://github.com/neolit123))