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

# はじめに

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

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

- [Metrics Changes と SIG Instrumentation](https://qiita.com/watawuwu/items/87108aa1545eb5ff4556) @watawuwu 
- [Known Issues, Urgent Upgrade Notes](https://qiita.com/uesyn/items/286f515e602aa7e78778) @uesyn 
- [SIG Apps](https://qiita.com/yosshi_/items/ec042a801ef69fa44ef6) @yosshi_ 
- [SIG API Machinery](https://qiita.com/Ladicle/items/726c1b8937976b7b6ece) @Ladicle 
- [SIG Auth](https://qiita.com/hiyosi/items/d0b4bcde347296548ebc) @hiyosi 
- [SIG CLI](https://qiita.com/superbrothers/items/afeea65db4f3d4d1c5ef) @superbrothers
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/9f32e2ac1be6f78c96b5) @yuanying
- [SIG Storage](https://qiita.com/ysakashita/items/5c54dcf0f51992760e5e) @ysakashita 
- [SIG Network](https://qiita.com/tkusumi/items/a816626c258735bdc98f) @tkusumi 
- [SIG Scheduling](https://qiita.com/everpeace/items/084da032a83c81bb887a) @everpeace 
- [SIG Autoscaling](https://qiita.com/shmurata/items/7c207695ba5ea7484327) @shmurata 
- [SIG Node](https://qiita.com/ryotarai/items/528707facb3341cd1f54) @ryotarai

# What's new!

## PodSecurityPolicyが非推奨へ

<!--
PSP as an admission controller resource is being deprecated. Deployed PodSecurityPolicy's will keep working until version 1.25, their target removal from the codebase. A new feature, with a working title of "PSP replacement policy", is being developed in KEP-2579. To learn more, read PodSecurityPolicy Deprecation: Past, Present, and Future.
-->

AdmissionControllerのリソースとしてのPSPは廃止されます。デプロイされたPodSecurityPolicyはコードベースから削除予定のv1.25まで動作し続けます。
[KEP-2579](https://features.k8s.io/2579)では、「PSP replacement policy」というワーキングタイトルの新機能が開発されています。
詳しくは[PodSecurityPolicy Deprecation: Past, Present, and Future](https://blog.k8s.io/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)をご覧ください。

## Kubernetes API Reference Documentation 

APIリファレンスは [gen-resourcesdocs](https://github.com/kubernetes-sigs/reference-docs/tree/c96658d89fb21037b7d00d27e6dbbe6b32375837/gen-resourcesdocs) により生成されるようになり、 [Kubernetes API](https://docs.k8s.io/reference/kubernetes-api/) へ移りました

## kubectlのkustomizeがアップデート

kubectlのkustomizeのバージョンがv2.0.3からv4.0.5となりました。
kustomizeはライブラリとして扱われ、将来の更新は散発的ではなくなります。

## デフォルトコンテナのラベル

複数のコンテナを持つPodは、`kubectl.kubernetes.io/default-container`ラベルを使用して、kubectlコマンド用に事前選択されたコンテナを指定できます。詳細は [KEP-2227](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/2227-kubectl-default-container/README.md) をご覧ください。

## Immutable Secrets と ConfigMaps 

Immutable SecretとConfigMapがGAとなりました。この機能は特定のSecretとConfigMapがそのオブジェクトが存在している間、不変であることを指定するものです。このようなインスタンスでは、Kubeletは変更を監視/ポーリングしないため、apiserverの負荷が軽減されます。

## kubelet の Structured Logging

リリースタイムライン内kubeletが構造化ロギングを採用しました。これは、コミュニティの努力により、リリースのタイムライン内で達成されました。プロジェクトでの構造化ロギングは現在も継続して行われています。参加に興味のある方は、[メーリングリストでの議論に注目してください](https://groups.google.com/g/kubernetes-dev/c/y4WIw-ntUR8)。

## Storage Capacity Tracking 

<!--
Traditionally, the Kubernetes scheduler was based on the assumptions that additional persistent storage is available everywhere in the cluster and has infinite capacity.
Topology constraints addressed the first point, but up to now pod scheduling was still done without considering that the remaining storage capacity may not be enough to start a new pod.
Storage capacity tracking addresses that by adding an API for a CSI driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod.
This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained.
-->

従来、KubernetesのSchedulerは追加のPersistentVolumeがクラスタ内のどこでも利用可能であり、容量が無制限であるという仮定に基づいています。
トポロジーの制約は前者に対応していましたが、これまでは残りのストレージ容量が新しいポッドを起動するのに十分でない可能性を考慮せずにPodのスケジューリングが行われていました。
ストレージのキャパシティトラッキングがその問題に対応します。CSI driverへストレージキャパシティをレポートするためのAPIを追加し、
PodのためのノードをSchedulerが選択する時にその情報を利用します。
この機能は、ローカルボリュームや、より容量に制約のある他のボリュームタイプのダイナミックプロビジョニングをサポートするための足がかりとなります。

## Generic Ephemeral Volumes

<!--
Generic ephermeral volumes 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.
It can be used to provide scratch storage that is different from the root disk, for example persistent memory, or a separate local disk on that node. 
All StorageClass parameters for volume provisioning are supported.
All features supported with PersistentVolumeClaims are supported, such as storage capacity tracking, snapshots and restore, and volume resizing.
-->

[Generic ephemeral volumes](https://docs.k8s.io/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) はdynamic provisioningをサポートする既存のストレージドライバーを、ボリュームのライフサイクルがポッドにバインドされたエフェメラルボリュームとして使用できます。
これは、ルートディスクとは異なるスクラッチストレージを提供するために使用することができます。例えば、永続的なメモリや、そのノード上の独立したローカルディスクなどです。
ボリュームプロビジョニングのための全てのStorageClassのパラメータがサポートされています。
PersistentVolumeClaimでサポートされている全ての機能がサポートされており、例えばキャパシティトラッキングやスナップショット, リストア, ボリュームのリサイズなどです。

## CSI Service Account Token 

<!--
CSI Service Account Token feature moves to Beta in 1.21. This feature improves the security posture and allows CSI drivers to receive pods' bound service account tokens. This feature also provides a knob to re-publish volumes so that short-lived volumes can be refreshed.
-->

CSI Service Account Token機能は1.21でベータとなりました。この機能はsecurity postureを改善し、CSI driverがPodに割り当てられたService Account Tokenを受け取ることを許可します。
また、この機能はボリュームを再発行するためのノブを提供し、短命のボリュームをリフレッシュすることができます。

## CSI Health Monitoring 

<!--
The CSI health monitoring feature is being released as a second Alpha in Kubernetes 1.21. This feature enables CSI Drivers to share abnormal volume conditions from the underlying storage systems with Kubernetes so that they can be reported as events on PVCs or Pods. This feature serves as a stepping stone towards programmatic detection and resolution of individual volume health issues by Kubernetes.
-->

CSI Health Monitoring 機能はKubernetes v1.21でsecond alphaとしてリリースされました。
この機能はCSI driverが基盤のストレージシステムから異常なボリュームの状態を共有し、PVCやPodのイベントとしてレポートできるようするものです。
この機能は、Kubernetesによる個々のボリュームの健全性に関する問題のプログラムによる検出と解決に向けた足がかりとなります。