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

# はじめに

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

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

- [Metrics Changes と SIG Instrumentation](https://qiita.com/watawuwu/items/0a0496f415b818edcb4d) @watawuwu 
- [SIG Apps](https://qiita.com/yosshi_/items/5ef6805eb358631fbbbc) @yosshi_ 
- [SIG API Machinery](https://qiita.com/Ladicle/items/a37d040dddfd7a982fb2) @Ladicle 
- [SIG Auth](https://qiita.com/hiyosi/items/7f9b4d2dd456cde8acd9) @hiyosi 
- [SIG CLI](https://qiita.com/superbrothers/items/2089e1f71bf4c3f89b4b) @superbrothers
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/1acaa17dcc1fd6045a93) @yuanying 
- [SIG Storage](https://qiita.com/ysakashita/items/0fc986b99971572a45f1) @ysakashita 
- [SIG Network](https://qiita.com/tkusumi/items/9516b7955c1c33d31e8e) @tkusumi 
- [SIG Scheduling](https://qiita.com/everpeace/items/1b6ad68075d81ce315c4) @everpeace 
- [SIG Node](https://qiita.com/y1r96/items/b5927b7f052d1fccbb1d) @y1r96 

# What's new!

## Deprecation of FlexVolume

<!--
FlexVolume is deprecated. Out-of-tree CSI driver is the recommended way to write volume drivers in Kubernetes. See this doc for more information. Maintainers of FlexVolume drivers should implement a CSI driver and move users of FlexVolume to CSI. Users of FlexVolume should move their workloads to CSI driver.
-->

FlexVolumeが非推奨となりました。Out-of-treeのCSI DriverがKubernetesでVolume Driverを書くための推奨の方法です。詳細は[こちらのドキュメント](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)をご参照ください。FlexVolumeドライバのメンテナはCSI Driverを実装し、FlexVolumeのユーザはCSIへ移行すべきです。FlexVolumeを利用しているユーザはそれらのワークロードをCSI Driverへ移行してください。

## Deprecation of klog specific flags

<!--
To simplify the code base, several logging flags got marked as deprecated in Kubernetes 1.23. The code which implements them will be removed in a future release, so users of those need to start replacing the deprecated flags with some alternative solutions.
-->

コードベースをシンプルにするために、いくつかのロギングフラグがKubernetes v1.23で非推奨とマークされました。それらを実装しているコードは将来のリリースで削除されるため、利用しているユーザは代替の解決方法で非推奨フラグを置き換え始める必要があります。

- :pencil: 非推奨となるフラグは[こちら](https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#klog)で確認できます
- :pencil: 詳細は[Kubernetes 1.23: Metrics Changes と SIG Instrumentation の変更内容](https://qiita.com/watawuwu/items/0a0496f415b818edcb4d#klog-%E5%9B%BA%E6%9C%89%E3%83%95%E3%83%A9%E3%82%B0%E3%81%AE%E9%9D%9E%E6%8E%A8%E5%A5%A8)をご参照ください

## Software Supply Chain SLSA Level 1 Compliance in the Kubernetes Release Process

<!--
Kubernetes releases are now generating provenance attestation files describing the staging and release phases of the release process and artifacts are verified as they are handed over from one phase to the next. This final piece completes the work needed to comply with Level 1 of the SLSA security framework (Supply-chain Levels for Software Artifacts).
-->

Kubernetesのリリースでは、リリースプロセスのステージングとリリースのフェーズを記述した証明ファイルが生成され、あるフェーズから次のフェーズに引き渡される際にアーティファクトが検証されるようになりました。この最後のピースにより、SLSA（Supply-chain Levels for Software Artifacts）セキュリティフレームワークのレベル1に準拠するために必要な作業が完了します。

- SLSAについては[こちらのブログポスト](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html)や[公式サイト](https://slsa.dev/)や[こちらのリポジトリ](https://github.com/slsa-framework/slsa)に情報がまとまっていそうです

## IPv4/IPv6 Dual-stack Networking graduates to GA

<!--
IPv4/IPv6 dual-stack networking graduates to GA. Since 1.21, Kubernetes clusters are enabled to support dual-stack networking by default. In 1.23, the IPv6DualStack feature gate is removed. The use of dual-stack networking is not mandatory. Although clusters are enabled to support dual-stack networking, Pods and Services continue to default to single-stack. To use dual-stack networking: Kubernetes nodes have routable IPv4/IPv6 network interfaces, a dual-stack capable CNI network plugin is used, Pods are configured to be dual-stack and Services have their .spec.ipFamilyPolicy field set to either PreferDualStack or RequireDualStack.
-->

[IPv4/IPv6 デュアルスタックネットワーキング](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack) が GA (General Availability) となりました。1.21 から、Kubernetes クラスタはデュアルスタックネットワーキングのサポートがデフォルトで有効です。1.23 で、IPv6DualStack フィーチャーゲートは削除されました。デュアルスタックネットワーキングの使用は、必須ではありません。クラスタではデュアルスタックネットワークのサポートが有効になっていますが、Pod と Service のデフォルトは引き続きシングルスタックとなっています。
デュアルスタックネットワーキングを使用するには、ノードがルーティング可能なIPv4/IPv6ネットワークを持ち、デュアルスタックが利用可能なCNIネットワークプラグインを利用する必要があり、Podがdual-stackとなるように設定され、Serviceはそれらの`.spec.ipFamilyPolicy`フィールドで`PreferDualStack`もしくは`RequireDualStack`のどちらかが設定されている必要があります。


## HorizontalPodAutoscaler v2 graduates to GA

<!--
Version 2 of the HorizontalPodAutoscaler API graduates to stable in the 1.23 release. The HorizontalPodAutoscaler autoscaling/v2beta2 API is deprecated in favor of the new autoscaling/v2 API, which the Kubernetes project recommends for all use cases.

This release does not deprecate the v1 HorizontalPodAutoscaler API.
-->

HorizontalPodAutoscaler APIのVersion 2vが1.23リリースでstableとなりました。HorizontalPodAutoscaler autoscaling/v2beta2 APIは非推奨となり、代わりにautoscaling/v2 APIを利用してください。このリリースはv1のHorizontalPodAutoscaler APIを廃止しません。

## Generic Ephemeral Volume feature graduates to GA

<!--
The generic ephemeral volume feature moved to GA in 1.23. This feature allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume with the volume’s lifecycle bound to the Pod. All StorageClass parameters for volume provisioning and all features supported with PersistentVolumeClaims are supported.
-->

generic ephemeral volume機能はv1.23でGAとなりました。この機能はdynamic provisioningをサポートする全てのストレージドライバーをPodにVolumeのライフサイクルが紐づけられたephemeral volumeとして利用できます。全てのボリュームプロビジョニングのためのStorageClassパラメータとPersistentVolumeClaimでサポートされている全ての機能がサポートされています。

## Skip Volume Ownership change graduates to GA

<!--
The feature to configure volume permission and ownership change policy for Pods moved to GA in 1.23. This allows users to skip recursive permission changes on mount and speeds up the pod start up time.
-->

Podのためにボリュームのパーミッションとオーナーシップを変更するポリシーを設定するための機能がv1.23でGAとなりました。これにより、マウント時の再帰的なパーミッション変更をスキップすることができ、Podの起動時間を短縮することができます。

## Allow CSI drivers to opt-in to volume ownership and permission change graduates to GA

CSIドライバがfsGroupのパーミッションを宣言できる機能が1.23にてGAとなりました。

## PodSecurity graduates to Beta

<!--
PodSecurity moves to Beta. PodSecurity replaces the deprecated PodSecurityPolicy admission controller. PodSecurity is an admission controller that enforces Pod Security Standards on Pods in a Namespace based on specific namespace labels that set the enforcement level. In 1.23, the PodSecurity feature gate is enabled by default.
-->

PodSecurityがBetaとなりました。PodSecurityは廃止されるPodSecurityPopily admission controllerを置き換えます。PodSecurityはPod Security Standardをエンフォースレベルがセットするための特定のラベルがセットされたNamespace内のPodへ適用するadmission controllerです。v1.23でPodSecurity feature gateはデフォルトで有効化されます。

- :pencil: PodSecurityについて知りたい方は、拙作の[PodSecurityPolicyの廃止に備えて、一足先にPodSecurity Admissionを試してみよう!](https://qiita.com/uesyn/items/cf47e12fba5e5c5ea25f)も合わせてご参照いただけると嬉しいです

## Container Runtime Interface (CRI) v1 is default

<!--
The Kubelet now supports the CRI v1 API, which is now the project-wide default. If a container runtime does not support the v1 API, Kubernetes will fall back to the v1alpha2 implementation. There is no intermediate action required by end-users, because v1 and v1alpha2 do not differ in their implementation. It is likely that v1alpha2 will be removed in one of the future Kubernetes releases to be able to develop v1.
-->

KubeletはCRI v1 APIをサポートし、プロジェクト全体でデフォルトとなります。コンテナランタイムが v1 API をサポートしていない場合、Kubernetes は v1alpha2 の実装にフォールバックします。v1 と v1alpha2 は実装に違いがないため、エンドユーザーによる中間的なアクションは必要ありません。v1を進展できるように将来のKubernetesリリースのいずれかでv1alpha2が削除される可能性があります。

## Structured logging graduate to Beta

<!--
Structured logging reached its Beta milestone. Most log messages from kubelet and kube-scheduler have been converted. Users are encouraged to try out JSON output or parsing of the structured text format and provide feedback on possible solutions for the open issues, such as handling of multi-line strings in log values.
-->

構造化ロギングがbetaとなりました。kubeletやkube-schedulerからの多くのログが変換されました。ユーザーは、JSON出力や構造化テキスト形式の解析を試し、ログ値における複数行の文字列の処理など、未解決の問題に対する可能な解決策についてフィードバックができます。

## Simplified Multi-point plugin configuration for scheduler

<!--
The kube-scheduler is adding a new, simplified config field for Plugins to allow multiple extension points to be enabled in one spot. The new multiPoint plugin field is intended to simplify most scheduler setups for administrators. Plugins that are enabled via multiPoint will automatically be registered for each individual extension point that they implement. For example, a plugin that implements Score and Filter extensions can be simultaneously enabled for both. This means entire plugins can be enabled and disabled without having to manually edit individual extension point settings. These extension points can now be abstracted away due to their irrelevance for most users.
-->

kube-schedulerは複数の拡張点(extension point)を持つPluginの設定を単純化するために新しい設定フィールドを追加しました。新しいmultiPointpluginフィールドは、管理者がschedulerをシンプルに設定できるようにすることを目的としています。
multiPointで有効化されたpluginは自動的にpluginが実装している拡張点をschedulerに登録します。たとえば、ScoreとFilterという拡張点を実装しているpluginは、双方同時にenabledできるようになります。これによって、拡張点を個別のenables/disabledを手動で編集せずに、全てのpluginをenabled/disbledすることができるようになります。これらの拡張点を個別に設定する方式は、ほとんどのユーザーにとって無関係であるため、抽象化されました。

## CSI Migration updates

<!--
CSI Migration enables the replacement of existing in-tree storage plugins such as kubernetes.io/gce-pd or kubernetes.io/aws-ebs with a corresponding CSI driver. If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.

- CSI Migration feature is turned on by default but stays in Beta for GCE PD, AWS EBS, and Azure Disk in 1.23.
- CSI Migration is introduced as an Alpha feature for Ceph RBD and Portworx in 1.23.
-->

CSI Migrationは既存のin-treeのStorage Plugin(kubernetes.io/gce-pd or kubernetes.io/aws-ebsなど)を対応するCSIドライバへ置き換えるものです。CSI Migrationが正しく動作していれば、Kubernetesのエンドユーザは、違いに気が付かないはずです。移行後、Kubernetesのユーザは、既存のインターフェースを利用して、in-treeのStorage Pluginの全ての機能を継続し利用できます。

- CSI Migration機能がデフォルトでオンになりますが、1.23ではGCE PD, AWS EBS, Azure DiskはBetaのままです。
- 1.23ではCeph RBD, PortworxのCSI Migration機能はAlphaです。

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

<!--
- Kubeadm: remove the deprecated flag --experimental-patches for the init|join|upgrade commands. The flag --patches is no longer allowed in a mixture with the flag --config. Please use the kubeadm configuration for setting patches for a node using {Init|Join}Configuration.patches. (#104065, @pacoxu)
- Log messages in JSON format are written to stderr by default now (same as text format) instead of stdout. Users who expected JSON output on stdout must now capture stderr instead or in addition to stdout. (#106146, @pohly) [SIG API Machinery, Architecture, Cluster Lifecycle and Instrumentation]
- Support for the seccomp annotations seccomp.security.alpha.kubernetes.io/pod and container.seccomp.security.alpha.kubernetes.io/[name] has been deprecated since 1.19, will be dropped in 1.25. Transition to using the seccompProfile API field. (#104389, @saschagrunert)
- kube-log-runner is included in release tar balls. It can be used to replace the deprecated --log-file parameter. (#106123, @pohly) [SIG API Machinery, Architecture, Cloud Provider, Cluster Lifecycle and Instrumentation]
-->

- kubeadm: `init|join|upgrade`コマンドにおける非推奨の`--experimental-patches`を削除しました。`--patches`フラグは`--config`フラグと共に利用することはできません。ノードにパッチを適用するkubeadmの設定には、`{Init|Join}Configuration.patches`を利用してください。([#104065](https://github.com/kubernetes/kubernetes/pull/104065), [@pacoxu](https://github.com/pacoxu))
- JSONフォーマットのログメッセージはstdoutの代わりにデフォルトでstderrへ出力されるようになりました。stdoutで出力されたJSON出力を期待していたユーザはstdoutに加えてstderrもキャプチャーする必要があります。([#106146](https://github.com/kubernetes/kubernetes/pull/106146), [@pohly](https://github.com/pohly)) [SIG API Machinery, Architecture, Cluster Lifecycle and Instrumentation]
- seccompのためのアノーテーションである`seccomp.security.alpha.kubernetes.io/pod`と`container.seccomp.security.alpha.kubernetes.io/[name]`はv1.19以降非推奨となっており、v1.25で削除予定です。seccompProfile APIフィールドを利用するようにしてください。([#104389](https://github.com/kubernetes/kubernetes/pull/104389), [@saschagrunert](https://github.com/saschagrunert))
- [kube-log-runner](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/component-base/logs/kube-log-runner)はtar ballのリリースに追加されました。これは非推奨となった--log-fileパラメータを置き換えるために利用できます。([#106123](https://github.com/kubernetes/kubernetes/pull/106123), [@pohly](https://github.com/pohly)) [SIG API Machinery, Architecture, Cloud Provider, Cluster Lifecycle and Instrumentation]