Kubernetes 1.22: 変更点まとめ(What's new!)

# はじめに

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

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

- [Metrics Changes と SIG Instrumentation](https://qiita.com/watawuwu/items/c177d1bc8a4b9a1d3a91) @watawuwu 
- [Known Issues, Urgent Upgrade Notes](https://qiita.com/uesyn/items/8009687f565418b50721) @uesyn 
- [SIG Apps](https://qiita.com/yosshi_/items/95b8a38ad1c44a0266bd) @yosshi_ 
- [SIG API Machinery](https://qiita.com/Ladicle/private/fbf416a9a07538ee05b1) @Ladicle 
- [SIG Auth](https://qiita.com/hiyosi/items/51bd6dd1a7e26b4fdd09) @hiyosi 
- [SIG CLI](https://qiita.com/superbrothers/items/4e75e076493114431f78) @superbrothers
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/f3fb02144079227d29df) @yuanying
- [SIG Storage](https://qiita.com/ysakashita/items/c54b4107524f45effd4a) @ysakashita 
- [SIG Network](https://qiita.com/tkusumi/items/2e3c69849ce2a4b50a90) @tkusumi 
- [SIG Scheduling](https://qiita.com/everpeace/items/c7ab1c366dd777dce14a)  [@everpeace](https://qiita.com/everpeace)
- [SIG Node](https://zenn.dev/ryotarai/articles/0e4868ec0275cd) @ryotarai 

# What's new!

### いくつかのbetaのKubernetes APIの削除
<!--
### Removal of several beta Kubernetes APIs

A number of APIs are no longer serving specific Beta versions in favour of the GA version of those APIs. All existing objects can be interacted with via general availability APIs. This removal includes beta versions of `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `APIService`, `TokenReview`, `SubjectAccessReview`, `CertificateSigningRequest`, `Lease`, `Ingress`, and `IngressClass` APIs. For the full list check out [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22) and the blog post [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/).
-->

いくつかのAPIは特定のベータ版の提供をしなくなったため、それらのAPIのGA版を利用してください。全ての既存のオブジェクトはGAのAPIを通して操作できます。この削除は`ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `APIService`, `TokenReview`, `SubjectAccessReview`, `CertificateSigningRequest`, `Lease`, `Ingress`, そして `IngressClass` APIのbeta版を含みます。全てのリストは[Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22) とブログポスト [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/)を確認してください.

- :pencil: どのバージョンでどのAPIが利用可能か確認したい場合は @tkusumi さんの[こちら](https://qiita.com/tkusumi/items/cb2dc318875fbef19468)のまとめをご参照ください


### Kubernetesのリリース頻度の変更
<!--
### Kubernetesのリリース頻度の変更

We all have to adapt to change in our lives, and especially so in the past year. The Kubernetes release team was also affected from the COVID-19 pandemic and has listened to its user base regarding the number of releases in a calendar year. From April 23, 2021 it was made official that Kubernetes release cadence has reduced from 4 releases per year to 3 releases per year.

You can read more in the official blog post [Kubernetes Release Cadence Change: Here’s What You Need To Know](https://blog.k8s.io/2021/07/20/new-kubernetes-release-cadence/).
-->

私たちは皆、生活の中で変化に対応しなければなりませんが、この1年は特にそうでした。Kubernetesのリリースチームも同様にCOVID-19のパンデミックの影響を受け、１年間のリリース数に関するユーザベースの意見に耳を傾けていました。2021年4月24日から、Kubernetesのリリース頻度は年4回から年3回へ減らされたことが公式から発表されました。
詳細は公式ブログ記事[Kubernetes Release Cadence Change: Here’s What You Need To Know](https://blog.k8s.io/2021/07/20/new-kubernetes-release-cadence/)をご確認ください。

### External credential providers

<!--
### External credential providers

Kubernetes client [credential plugins](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) have been in beta since 1.11, a few eons ago. With the release of Kubernetes 1.22, this feature set graduates to stable. The GA feature set includes improved support for plugins that provide interactive login flows.
This release also contains a number of bug fixes to the feature set. Aspiring plugin authors can look at [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin) as a way to get started.

Related to this topic, the in-tree Azure and GCP authentication plugins have been [deprecated](https://github.com/kubernetes/kubernetes/pull/102181) in favor of out-of-tree implementations.
-->

Kubernetesクライアントの[credential plugin](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)は1.11以来betaでしたが、Kubernetes v1.22でこの機能はstableとなりました。GAの機能セットにはインタラクティブなログインフローを提供するプラグインのサポートの改善が含まれます。このリリースは多くのバグ修正も含みます。プラグインを作りたい人は[sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin)を参考にしてみてください。これと関連して、in-treeのAzureとGCP認証プラグインが非推奨となりout-of-treeの実装をものが推奨されます。

### Server-side ApplyがGAへ

<!--
### Server-side Apply graduates to GA

Server-side Apply is a new object merge algorithm, as well as tracking of field ownership, running on the Kubernetes API server. Server-side Apply helps users and controllers manage their resources via declarative configurations. It allows them to create and/or modify their objects declaratively, simply by sending their fully specified intent. After being in beta for a couple releases, [Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) is now generally available.
-->

Server-side Applyはフィールドの所有者をトラッキングする新しいオブジェクトのマージアルゴリズムでありKubernetes API server上で動作します。 Server-side Applyはユーザやコントローラが宣言的な設定によりリソースを管理するのに役立ちます。
これにより完全に意図した設定を指定し送信するだけ宣言的に作成や修正を実行できます。数回のリリースのbetaを経て、[Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/)はGAとなりました。

### Cluster Storage Interface graduations

<!--
### Cluster Storage Interface graduations

CSI support for Windows nodes moves to GA in the 1.22 release. In Kubernetes v1.22, Windows privileged containers are only an alpha feature. To allow using CSI storage on Windows nodes, [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) enables CSI node plugins to be deployed as unprivileged pods, using the proxy to perform privileged storage operations on the node.

Another feature moving to GA in v1.22 is CSI Service Account Token support. This feature allows CSI drivers to use pods' [bound service account tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) instead of a more privileged identity. It also provides control over to re-publishing these volumes, so that short-lived tokens can be refreshed.
-->

WindowsノードのCSIサポートは、1.22リリースでGAになります。Kubernetes v1.22では、Windows特権コンテナはアルファ機能のみです。WindowsノードでCSIストレージを使用できるようにするには、[CSIProxy](https://github.com/kubernetes-csi/csi-proxy)の有効によりCSIノードプラグインが非特権Podとしてデプロイされ、このProxyを使うことで、ノード上の特権ストレージ操作を実行できます。

もう一つの、v1.22でGAする機能はCSI Service Account Tokenサポートです。この機能により、CSIドライバは、特権を持ったIDの代わりにPodの [bound service account tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)を使用できます。また、これらのボリュームを再発行するためのコントロールも提供しているため、短命のトークンを更新することができます。

### SIG Windows development tools

<!--
### SIG Windows development tools

To grow the developer community, SIG Windows  released multiple [tools](https://github.com/kubernetes-sigs/sig-windows-dev-tools/). The new tools support multiple CNI providers (Antrea, Calico), can run on multiple platforms (any vagrant compatible provider, such as Hyper-V, VirtualBox, or vSphere).
There is also a new way to run bleeding edge Windows features from scratch by compiling the windows kubelet and kube-proxy, then using them along with daily builds of other Kubernetes components.

-->

デベロッパーコミュニティの成長につれ、SIG Windowsは[複数のツール]((https://github.com/kubernetes-sigs/sig-windows-dev-tools/))をリリースしました。これらは複数のCNIプロバイダー(Antrea, Calico)をサポートし、マルチプラットフォーム(Hyper-VやVirtualBox, vSphereなどのvagrant互換のプロバイダー)で動作可能となります。
またWindows版のkubeletやkube-proxyをcompileすることでスクラッチで最先端のWIndowsの機能を実行するための新しい方法もあり、それらを他のKubernetesコンポーネントのデイリーのビルドとともに利用できます。

### kubeadmを使ったさらに安全なコントロールプレーンの構築

<!--

### Deploy a more secure control plane with kubeadm

A new alpha feature allows running the kubeadm control plane components as non-root users. This is a long requested security measure in kubeadm. To try it you must enable the kubeadm-specific `RootlessControlPlane` feature gate. When you deploy a cluster using this alpha feature, your control plane runs with lower privileges.

A new [v1beta3 configuration API](https://github.com/kubernetes/kubeadm/issues/1796). It [iterates over v1beta2](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) by adding some long requested features and deprecating some existing ones. The `V1beta3` is now the preferred API version; the `v1beta2` API also remains available and is not yet deprecated.
-->

新しいalpha機能によって、kubeadmのコントロールプレーンがnon-rootなユーザで実行することができるようになりました。これは長らくkubeadmに求められていたセキュリティ対策となります。試す場合にはkubeadm特有の `RootlessControlPlane` FeatureGateを有効化してください。このalpha機能を使ってクラスターをデプロイすることで、コントロールプレーンは少ない権限で実行されます。

新しい`v1beta3`の設定APIは`v1beta2`をベースに長らく求められていた機能を追加し、いくつかの機能を非推奨としました。そのため、`v1beta3`は現在推奨されているAPIのバージョンとなりますが、`v1beta2`APIも引き続き利用可能であり、非推奨APIではありません。


### etcdのバージョンが3.5.0へ

<!--
### etcd moves to version 3.5.0

Kubernetes' default backend storage, etcd, has a new release 3.5.0 and the community embraced it. The new release comes with improvements to the Security, performance, monitoring and developer experience. There are numerous bug fixes to lease objects causing memory leaks, and compact operation causing deadlocks and more. A couple of new features are also introduced like the migration to structured logging and build in log rotation. The release comes with a detailed future roadmap to implement a solution to traffic overload. A full and detailed list of changes can be read in the [3.5.0 release announcement](https://etcd.io/blog/2021/announcing-etcd-3.5/).
-->

Kubernetesのデフォルトのバックエンドストレージであるetcdは新たな3.5.0がリリースされ、コミュニティにそれは受け入れられました。新たなリリースはセキュリティやパフォーマンス、モニタリング、デベロッパーエクスペリエンスの改善を含みます。
リースオブジェクトがメモリリークを引き起こしたり、圧縮操作時デッドロックを引き起こすなどの多くのバグ修正が含まれています。複数の新しい機能が導入され、構造化ロギングへの移行やログローテーションの構築なども導入されています。
このリリースには、トラフィックの過負荷に対する解決策を実装するための、詳細な将来のロードマップが含まれています。変更点の詳細なリストは、[3.5.0 release announcement](https://etcd.io/blog/2021/announcing-etcd-3.5/)をご覧ください。

### Kubernetesノードのsystem swapをサポート

全てのシステム管理者またはKubernetesユーザは`swap領域を無効化する`という設定をKubernetesを利用している状況です。Kubernetes v1.22のリリースでswapメモリを有効化したノードの実行がalphaとしてサポートされました。
この変更は管理者がLinuxノードのswapを設定できるようにし、ブロックストレージの一部を追加の仮想メモリとして利用することを選択できるようになります。

<!--
### Kubernetes Node system swap support

Every system administrator or Kubernetes user has been in the same boat regarding setting up and using Kubernetes: disable swap space. With the release of Kubernetes 1.22, *alpha* support is available to run nodes with swap memory. This change lets administrators opt in to configuring swap on Linux nodes, treating a portion of block storage as additional virtual memory.
-->

### クラスターワイドなseccompのデフォルト 

<!--
### Cluster-wide seccomp defaults

A new alpha feature gate `SeccompDefault` has been added to the kubelet, together with a corresponding command line flag `--seccomp-default` and kubelet configuration. If both are enabled, then the kubelet's behavior changes for pods that don't explicitly set a seccomp profile.
With cluster-wide seccomp defaults, the kubelet uses the `RuntimeDefault` seccomp profile by default, rather than than `Unconfined`. This allows enhancing the default cluster wide workload security of the Kubernetes deployment. Security administrators will now sleep better knowing there is some security by default for the workloads.

To learn more about the feature, please refer to the official [seccomp tutorial](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads).
-->

新たなalphaのFeatureGateである`SeccompDefault`がkubeletへ追加され、対応する`--seccomp-default`フラグやkubeletの設定とともに追加されました。
両方が有効化されると、seccomp promfileを明示的に設定していないPodに対するkubelet挙動が代わります。
クラスターワイドなseccompのデフォルトを利用すると、kubeletは`Unconfined`ではなく`RuntimeDefault`をseccomp profileのデフォルトとして利用します。
これによりKubernetesデプロイメントのデフォルトのクラスター全体のワークロードセキュリティを強化できます。

### メモリリソースのためのQuality of Service

<!--
### Quality of Service for memory resources

Originally, Kubernetes used the v1 cgroups API. With that design, the QoS class for a pod only applied to CPU resources (such as `cpu_shares`). The Kubernetes cgroup manager uses `memory.limit_in_bytes` in v1 cgroups to limit the memory capacity for a container, and uses `oom_scores` to recommend an order for killing container processes if an out-of-memory event occurs. This implementation has shortcomings: for `Guaranteed` pods, memory can not be fully reserved, and the page cache is at risk of being recycled. For `Burstable` pods, overcommitting memory (setting `request` less than `limit` ) could increase the risk of a container being killed when the Linux kernel detects an out of memory condition.

As an alpha feature, Kubernetes v1.22 can use the cgroups v2 API to control memory allocation and isolation. This feature is designed to improve workload and node availability when there is contention for memory resources.
-->

もともと、Kubernetesはv1のcgroup apiを使用していました。この設計では、PodのQoSクラスはCPUだけ(`cpu_shareds`のような)に適用されます。 Kubernetesのcgroup managerはコンテナのためのメモリキャパシティを制限するためにv1 cgroupsで`memory.limit_in_bytes`を使用し、さらにout-of-memoryイベントが発生したときに、killされるコンテナプロセスの優先順位を決めるために`oom_scores`を利用していました。この実装は欠点があり、`Guaranteed`なPodは完全にメモリを予約することができず、ページキャッシュがリサイクルされる危険性があります。`Burstable`なPodではメモリをオーバーコミットすると(`request`を`limit`より小さくする)、Linuxカーネルがメモリ不足を検知した際、コンテナが強制終了されるリスクが高くなります。
alpha機能として、Kubernetes v1.22ではメモリの割り当てをコントロール・分離するためにcgroups v2のAPIを利用できます。この機能はメモリリソースの競合が発生した場合に、ワークロードとノードの可用性を向上させるように設計されています。

### エフェメラルコンテナのためのAPIの変更と改善

<!--
### API changes and improvements for ephemeral containers

The API used to create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) changed in 1.22. The Ephemeral Containers feature is alpha and disabled by default, and the new API does not work with clients that attempt to use the old API.

For stable features, the `kubectl` tool follows the Kubernetes [version skew policy](https://kubernetes.io/releases/version-skew-policy/);
however, kubectl v1.21 and older do not support the new API for ephemeral containers.
Users who create ephemeral containers using `kubectl debug` should note that kubectl version 1.22 will attempt to fall back to the old API; older versions of kubectl will not work with cluster verions of 1.22 or later. Please update kubectl to 1.22 if you wish to use `kubectl debug` with a mix of cluster versions.
s
-->

エフェメラルコンテナを作成するためのAPIがv1.22で変更されました。エフェメラルコンテナ機能はalphaであるためデフォルトで無効化されており、新たなAPIは古いAPIを利用しようとするクライアントでは利用できません。
安定版の機能のために、`kubectl`ツールはKubernetesの[version skew policy](https://kubernetes.io/releases/version-skew-policy/)に従います。
しかし、kubectl v1.21以前のものは新たなエフェメラルコンテナをサポートしていません。
`kubectl debug`を用いてエフェメラルコンテナを作成しようとするユーザは以下の注意すべきことがあります

- kubectl v1.22は古いAPIへフォールバックしようとします。
- v1.22より前のkubectlではKubernetes v1.22以降のKubernetesクラスタでは動作しません

複数のクラスタバージョンで`kubectl debug`を利用したい場合は、kubectlをv1.22へアップデートしてください。