はじめに
このエントリは、Kubernetes 1.20 の CHANGELOG からWhat's new!と、各変更点についてまとめたページへのリンクです。
詳細については各まとめページを参照してください。
変更点の詳細へのリンク
- Metrics Changes と SIG Instrumentation @watawuwu
- Known Issues, Urgent Upgrade Notes @uesyn
- SIG Apps @yosshi_
- SIG API Machinery @Ladicle
- SIG Auth @hiyosi
- SIG CLI @superbrothers
- SIG Cluster Lifecycle @yuanying
- SIG Storage @ysakashita
- SIG Network @tkusumi
- SIG Scheduling @everpeace
- SIG Autoscaling @shmurata
- SIG Node @ryotarai
What's new!
Dockershim deprecation
Dockershimが非推奨となります。Dockerで生成されたイメージは、これまでと同様に、すべてのランタイムでクラスタ内で動作し続けます。
Kubernetesコミュニティはこの詳細に関するブログと専用のFAQページで詳しく紹介しています。
External credential provider for client-go
client-go クレデンシャルプラグインは、環境変数KUBERNETES_EXEC_INFO
を介して現在のクラスタ情報を渡すことができるようになりました。これについての詳細は、client-go クレデンシャルプラグインのドキュメントを参照してください。
CronJob controller v2 is available through feature gate
CronJob
コントローラの代替実装がこのリリースでアルファとして利用可能になりました。これはポーリングの代わりにinformerにより実験的にパフォーマンスが向上しています。これは将来的にデフォルトの動作となる予定であり、FeatureGateで有効化することで試すことができます。
PID Limits graduates to General Availability
1年間のベータ期間を経てPID Limit機能であるSupportNodePidsLimit
(ノードとPodのPIDの分離)とSupportPodPidsLimit
(Pod単位のPIDの制限をする機能)が現在GAとなりました。
API Priority and Fairness graduates to Beta
v1.18で最初に導入され、Kubernetes v1.20でAPI PriorityとFairness(APF)がデフォルトで有効化されました。これはkube-apiserver
が優先度に応じて受けたリクエストをカテゴライズできるようにします。
IPv4/IPv6 run
IPv4/IPv6 デュアルスタックはコミュニティとユーザのフィードバックをもとにv1.20で再実装されました。もしクラスタでデュアルスタックが有効化されているなら、IPv4,IPv6またはその両方を利用することができるサービスを作ることができます。詳細は更新されたIPv4/IPv6 デュアルスタックのドキュメントで確認できます。
go1.15.5
go1.15.5はこのリリース時点でKubernetesプロジェクトへ組み込まれました。
CSI Volume Snapshot graduates to General Availability
Volume Snapshotが1.20でGAになりました。この機能は、KubernetesでVolume Snapshotのオペレーションをトリガーする標準的な方法を提供し、Kubernetesのユーザーは、サポートしているストレージプロバイダによらず、あらゆるKubernetes環境上で同じようにVolume Snapshotの操作を組み込むことができます。さらに、これらKubernetesのスナップショットのプリミティブなアクションは、アプリケーションやクラスタレベルのバックアップソリューションなど、Kubernetesのエンタープライズグレードのストレージ管理機能の開発に利用できる基本的なビルディングブロックとして機能します。
スナップショットのサポートするには、KubernetesのディストリビュータがSnapshot controller、Snapshot CRD、およびvalidation webhookをバンドルする必要があることに注意してください。
さらに、スナップショット機能をサポートするCSI driverもクラスタにデプロイする必要があります。
Non-recursive Volume Ownership (FSGroup) graduates to Beta
デフォルトでは、fsgroup 設定が指定されている場合、マウントのたびにボリューム内のすべてのファイルのパーミッションが再帰的に更新されます。このため、ボリュームに多数のファイルがある場合、マウントやPodの起動が非常に遅くなることがあります。この設定により、ルートディレクトリのパーミッションとオーナーシップがボリューム上の期待するパーミッションと一致しない場合にのみ、ボリュームのオーナーシップとパーミッションが変更されることを示す PodFSGroupChangePolicy をPodで指定できるようになります。
CSIDriver policy for FSGroup graduates to Beta
FSGroupのCSIDriver Policyが1.20でベータになりました。これにより、CSIDriverは、Kubernetesにボリュームのパーミッションとオーナーシップをfsgroup経由で管理させたいかどうかを明示的に示すことができるようになりました。
Security Improvements for CSI Drivers (Alpha)
1.20では、新しいアルファ機能としてCSIServiceAccountTokenを導入しました。この機能により、CSI DriversがボリュームをマウントするPodになりすますことができます。これにより、CSI Driverのservice acountに不必要なパーミッションを渡すことなく、ボリュームがPodのservice account上でACLをコントロールするマウントプロセスにおけるセキュリティが改善されます。この機能は、secrets-store-csi-driver のような秘密扱いの CSI Driverにとって特に重要です。これらのトークンはローテートさせて短命にすることができるので、この機能はCSI Driverが新しいトークンで定期的にNodePublishVolume RPCコールを受信するためのノブを提供します。このノブは、ボリュームが証明書のように短命の場合にも有用です。
Runtime log sanitation
ログは機密データの漏洩を防ぐため、ランタイムの保護機能を設定できるようになりました。 この実験的な機能の詳細はドキュメントに記載されています。
-
ワークロードではなくKubernetesコンポーネントのログのサニタイズ機能です
- v1.20でサポートされているコンポーネント
- kube-controller-manager
- kube-apiserver
- kube-scheduler
- kubelet
- v1.20でサポートされているコンポーネント
- k8s.io/klogのFilterとして実現しており、Filter自体は k8s.io/component-base で実装されています
- @watawuwu さんのKubernetes 1.20: Metrics Changes と SIG Instrumentation の変更内容 でこの変更についてまとめられています
- 下記のようなコードで試すことができます
package main
import (
"flag"
"net/http"
"crypto/x509"
"k8s.io/component-base/logs/sanitization"
"k8s.io/klog/v2"
)
func main() {
klog.InitFlags(nil)
flag.Parse()
klog.SetLogFilter(&sanitization.SanitizingFilter{})
klog.V(0).Info("test")
klog.V(0).Info("test1", &http.Header{"test": []string{"header"}})
klog.V(0).Info("test2", &http.Cookie{Name: "test"})
klog.V(0).Info("test3", &x509.Certificate{Raw: []byte{}})
}
I0126 13:42:22.275555 93832 main.go:17] test
I0126 13:42:22.275732 93832 main.go:18] Log message has been redacted. Log argument #0 contains: [password token]
I0126 13:42:22.275756 93832 main.go:19] Log message has been redacted. Log argument #0 contains: [token]
I0126 13:42:22.275762 93832 main.go:20] Log message has been redacted. Log argument #0 contains: [security-key]
Pod resource metrics
オンデマンドのメトリクスが/metrics/resources
から利用できるようになりました。この機能を有効にすると実行中のPodのリソースリクエストが取得できます。
-
上記リンク先に記載してある
--show-hidden-metrics-for-version=1.20
はv1.20では指定がなくてもメトリクスが出力されるようです
Introducing RootCAConfigMap
RootCAConfigMap
がベータへ、BoundServiceAccountTokenVolume
から分離されました。kube-root-ca.crt
というConfigMapがデフォルトで全てのネームスペースで利用可能になりました。これには、kube-apiserver 接続を検証するための Certificate Authority バンドルが含まれています。
kubectl debug
graduates to Beta
kubectl alpha debug
はv1.20でアルファからベータへ昇格し、kubectl debug
となりました。kubectl debug
は一般的なデバッグワークフローをkubectl
から直接サポートします。このリリースのkubectlでサポートされているトラブルシューティングシナリオは、
- 起動時にクラッシュするワークロードをコピーして異なるコンテナイメージや引数のPodとしてトラブルシューティングを行う
- デバッグツールを含む新しいコンテナを対象のPodのコピーやエフェメラルコンテナを追加することでdistrolessコンテナのトラブルシューティングを行う
- (エフェメラルコンテナはアルファ機能であるため、デフォルトでは有効になっていません)
- ホストのネームスペースやファイルシステムへアクセスできるコンテナを作ることでノードのトラブルシュートを行う
新しい組み込みコマンドとして、kubectl debug
は"debug"という名前のkubectlプラグインよりも優先されることに注意してください。影響のあるプラグインはリネームが必要になるでしょう。kubectl alpha debug
は非推奨となり今後のリリースで削除されます。kubectl debug
についての詳細は、KubernetesのWebサイトのDebugging Running Podsやkubectl help debugを参照するか、#sig-cliにアクセスしてSIG CLIに連絡するか、enhancement #1441にコメントしてください。
Removing deprecated flags in kubeadm
kubeadm
は、このリリースで多くの非推奨と非推奨機能の削除を適用します。詳細については、「Urgent Upgrade Notes」および「Kind/Deprecation」セクションを参照してください。
Pod Hostname as FQDN graduates to Beta
1.19 でフィーチャーゲート SetHostnameAsFQDN で導入された機能がデフォルトで有効になりました。詳しくは、Service と Pod に対しての DNS のドキュメントをご覧ください。
TokenRequest
/TokenRequestProjection
graduates to General Availability
ポッドにバインドされたサービスアカウントトークンがstable機能になりました。このFeatureGatesは1.21リリースで削除される予定です。詳細については、CHANGELOGの注意事項を参照してください。
- TokenRequestとTokenRequestProjectionについては @hiyosi さんの以下の記事が参考になります
RuntimeClass feature graduates to General Availability
node.k8s.io
APIグループはv1beta1
からv1
へ昇格しました。v1beta1
は廃止され、将来のリリースで削除される予定です。v1
を利用し始めてください。
Cloud Controller Manager now exclusively shipped by Cloud Provider
KubernetesはCloud Controller Managerバイナリを提供しなくなります。各クラウドプロバイダが自分たちのCloud Controller Managerを提供することが期待されています。クラウドプロバイダがこのようなバイナリのインスタンスを作成するための詳細は、ここに記載されています。Cloud Controller Manager の構築について質問がある場合は、SIG Cloud Provider に連絡してください。マネージドKubernetesソリューションのCloud Controller Managerに関する質問は、関連するクラウドプロバイダーに問い合わせてください。管理されていないソリューションのCloud Controller Managerに関する質問はSIG Cloud Providerに問い合わせてください。