はじめに

このエントリは、Kubernetes 1.20 の CHANGELOG からWhat's new!と、各変更点についてまとめたページへのリンクです。
詳細については各まとめページを参照してください。

変更点の詳細へのリンク

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
k8s.io/klogのFilterとして実現しており、Filter自体は k8s.io/component-base で実装されています
- klogの引数に渡すオブジェクトがこれらのどれかが含まれていた場合に代替メッセージが表示されるようです。
@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では指定がなくてもメトリクスが出力されるようです
- https://qiita.com/watawuwu/items/ab5a0f11210d15cc6a86#pod-resource-metrics

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 さんの以下の記事が参考になります
- TokenRequestProjectionについて調べてみた
- BoundServiceAccountVolumeを有効にしてみる

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に問い合わせてください。

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