本文の内容は、2020年12月1日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/whats-new-kubernetes-1-20/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes 1.20がリリースされようとしていますが、目新しさが満載ですね。どこから始めればいいのでしょうか？前回のリリースで強調したように、拡張機能は安定性のために前に進まなければならないか、非推奨になるかのどちらかになります。その結果、CronJobsやKubeletのCRIサポートなど、Kubernetesの初期の頃からあったアルファ機能が注目を浴びるようになりました。
今回のKubernetes 1.20リリースのもう一つの注目すべき点は、1.19の34の機能強化から43の機能強化が行われたことです。その43の機能強化のうち、11は安定版への移行、15は完全な新機能、17は改善を続ける既存の機能です。
多くの機能強化があるということは、その範囲が狭くなっているということです。Kubernetes 1.20は、多くの小さなユーザーフレンドリーな変更を伴う健全なハウスクリーニングイベントです。例えば、kube-apiserverの改良により、HAクラスターでより良く動作し、アップグレード後の再起動をより効率的に行えるようになりました。また、リソースを適切に解放できるように、ノードをグレースフルシャットダウンできるようになりました。このような小さな機能が、これからの大きな変化への道を切り開いていくのを見るのは、とてもエキサイティングなことです。
Kubernetes 1.20の新機能の詳細なリストは以下の通りです。
このリリースで私たちにとって最もエキサイティングに見える機能は以下の通りです(ymmv)。
#1753 Kubernetesシステムコンポーネントのログのサニタイズ
最近、ログ出力への資格情報の漏洩に関連した脆弱性がいくつか発生しています。全体像を念頭に置き、潜在的な漏洩源を特定し、それらの漏洩を防ぐために再データ化メカニズムを設置することで、これらの脆弱性にアプローチしていることを知っていると、安心できます。
Vicente Herrera - Sysdigのクラウドネイティブセキュリティアドボケイト
#2047 CSIServiceAccountToken
この機能強化は、Kubernetesで行われている認証周りのセキュリティとトークンの扱いを改善するための大きな取り組みを表しています。この記事のAuthのセクションを見て、私が何を言っているのかを確認してください。この特定の機能により、認証を必要とするボリュームへのアクセス（シークレットの保管庫のようなもの）がより安全に、より簡単に設定できるようになります。
Víctor Jiménez - Sysdigのコンテンツマーケティングエンジニア
#19 CronJobs + #2040 Kubelet CRIサポート
これらが新機能ではないことを知るには、CronJobsのissue番号(19)を見る必要があります。CronJobsは1.4から、CRIは1.5からサポートされており、本番環境では広く使われていますが、どちらもまだ安定しているとは考えられていません。本番環境のクラスターを動かすために頼りにしている機能が、もうアルファではないということがわかって安心しました。
David de Torres - Sysdig のインテグレーションエンジニア
#2000 ノードのグレースフルシャットダウン
小さな機能？そうです。開発者への善意の巨大なデモンストレーション？それもまた真実です。ノードがシャットダウンしたときにリソースを適切に解放できるようになれば、デバッグやトラブルシューティングが困難な毛むくじゃらなものを含む、多くの奇妙な動作を回避することができます。
Álvaro Iradier - Sysdigのインテグレーションエンジニア
#1965 kube-apiserver identity
kube-apiserver のインスタンスごとに一意の識別子を持つことは、通常は気づかれない機能の一つです。しかし、将来のKubernetesのバージョンでより良い高可用性機能が可能になることを知っていると、私は本当に気合が入ります。
Mateo Burillo - Sysdigのプロダクトマネージャー
#1748 ポッドモデルを表すリソースリクエストとリミットに関するメトリクスを公開する
そうです！より多くのメトリクスはいつでも歓迎します。クラスターのキャパシティをより良く計画し、eviction問題のトラブルシューティングに役立てることができるようになればなおさらです。
Carlos Arilla - Sysdig のインテグレーションエンジニアリングマネージャー
#1558 ストリーミングプロキシのリダイレクト
ステージ：非推奨
機能グループ：ノード
StreamingProxyRedirects の非推奨化に伴い、--redirect-container-streaming フラグを有効にすることができなくなりました。
StreamingProxyRedirects の機能ゲートと --redirect-container-streaming フラグは両方とも 1.18 で非推奨とされていました。機能ゲートは 1.22 ではデフォルトで無効化され、1.24 で削除されます。
この非推奨の理由については、KEP を参照してください。
#2067 kubeadm master のノードロールラベルの名前の変更とtaint
ステージ：非推奨
機能グループ: クラスタライフサイクル
攻撃的な表現を避けるため、node-role.kubernetes.io/masterはnode-role.kubernetes.io/control-planeに改名されます。
この変更の意味合いについては、KEPを参照してください。
#1164 SelfLinkの非推奨化と削除
ステージ：ベータへの移行
機能グループ: api-machinery
SelfLinkフィールドは、すべてのKubernetesオブジェクトに存在し、与えられたオブジェクトを表すURLを含みます。このフィールドは新しい情報を提供するものではなく、その作成と維持はパフォーマンスに影響を与えます。
当初は Kubernetes 1.16 で非推奨とされていましたが、現在ではデフォルトでこの機能ゲートは無効化されており、最終的には Kubernetes 1.21 で削除される予定です。
#1965 kube-apiserver identity
ステージ：アルファ
機能グループ: api-machinery
高可用性クラスター内でどのkube-apiserversが生きているかをより良く制御するために、新しいリース/ハートビートシステムが実装されました。
各 kube-apiserver は、それ自身に kube-apiserver-{UUID} という形式のユニークな ID を割り当てます。これらのIDは、10秒ごとに更新される(デフォルトでは)リースオブジェクトに格納され、更新されない場合はガーベージコレクションされます。
このシステムは、ノードのハートビートに似ています。実際には、既存のKubeletのハートビートロジックを再利用します。
#1904 kube-apiserver再起動後の効率的なウォッチ再開
ステージ：アルファ
機能グループ: api-machinery, ストレージ
今後、kube-apiserver は再起動後にウォッチキャッシュをより高速に初期化できるようになりました。この機能はEfficientWatchResumption機能フラグで有効にすることができます。
クライアントは、ウォッチでKubernetesオブジェクトの変更を追跡することができます。これらのリクエストに応えるために、kube-apiserverはウォッチキャッシュを保持します。しかし、再起動後(例えば、ローリングアップグレード中など)はキャッシュが古くなっていることが多いので、kube-apiserver は更新された状態を etcd から取得する必要があります。
更新された実装では、etcd バージョン 3.0 の WithProgressNotify オプションを利用します。WithProgressNotify を使うと、オブジェクトの更新された状態を毎分ごとに、そしてシャットダウンする前に一度だけ取得することができるようになります。これにより、kube-apiserver が再起動したときには、すでにキャッシュがかなり更新されていることになります。
完全な実装の詳細は KEP で確認してください。
#1929 組み込みAPIタイプのデフォルト
ステージ：ステーブルへ移行
機能グループ: api-machinery
Go 構造体としてカスタムリソース定義（CRD）を構築する際に、デフォルト値を提供するために // +default マーカーを使用できるようになりました。これらのマーカーは OpenAPI のデフォルトフィールドに変換されます。
type Foo struct {
// +default=32
Integer int
// +default="bar"
String string
// +default=["popcorn", "chips"]
StringList []string
}
#1040 APIサーバリクエストのプライオリティとフェアネス
ステージ：ベータへ移行
機能グループ: api-machinery
APIPriorityAndFairness機能ゲートは、APIサーバーの新しいmax-in-flightリクエストハンドラを可能にします。FlowSchemaオブジェクトで異なるタイプのリクエストを定義し、RequestPriorityオブジェクトでリソースを割り当てることで、Kubernetes APIサーバーが高負荷時の管理者タスクやメンテナンスタスクに確実に応答できるようになります。
1.18のリリースについては、「What's new in Kubernetes」シリーズをご覧ください。
#541 External client-go クレデンシャル・プロバイダー
ステージ：ベータへ移行
機能グループ: auth
この機能拡張により、Goクライアントは、鍵管理システム(KMS)、信頼できるプラットフォームモジュール(TPM)、ハードウェアセキュリティモジュール(HSM)などの外部のクレデンシャルプロバイダを使用して認証できるようになります。
これらのデバイスは、他のサービスに対する認証にすでに使用されており、ローテーションが容易で、ディスク上にファイルとして存在しないため、より安全性が高い。
最初はKubernetes 1.10で導入されましたが、この機能はついにベータステータスに到達しました。
#542 TokenRequest APIとKubeletの統合
ステージ：ベータへ移行
機能グループ: auth
ワークロードが API に対して認証を行うために使用する現在の JSON Web Tokens (JWT) には、いくつかのセキュリティ上の問題があります。この拡張機能は、JWT のためのより安全な API を作成するための作業で構成されています。
新しいAPIでは、トークンは特定のワークロードにバインドされ、有効期間を与えられ、特定のオブジェクトが存在する間のみ存在することができます。
詳細はKEPで確認してください。
#1393 サービスアカウント・トークン発行者のためのOIDCディスカバリーを提供
ステージ：ベータへ移行
機能グループ: auth
Kubernetes サービスアカウント (KSA) は現在、例えば kubectl --token <the_token_string> を使用して Kubernetes API に対して認証するために JSON Web Tokens (JWT) を使用することができます。この機能拡張により、クラスター外のサービスがAPIサーバに過負荷をかけることなく、一般的な認証方法としてこれらのトークンを使用できるようになりました。
1.18のリリースについての詳細は、What's new in Kubernetesシリーズを参照してください。
#1020 kubectl のパッケージコードをステージングへ移動
ステージ：ステーブルへ移行
機能グループ：cli
Kubernetes 1.18で行われた作業の続きで、このkubectlコードの内部再構築は、kubectlバイナリを自身のリポジトリに移動するための最初のステップです。これにより、kubectl が kubernetes のコードベースから切り離され、アウトザツリープロジェクトがそのコードを再利用することが容易になりました。
#1441 kubectl debug
ステージ：ベータへ移行
機能グループ：cli
Kubernetes 1.18からのkubectl debugの大きな変更点は2つあります。
kubectl alpha debugの代わりに kubectl debugを使用できるようになりました。
また、kubectl debugでは、kubectl set imageがどのように動作するかと同様に、デバッグ用のポッドをコピーする際にコンテナイメージを変更できるようになりました。
#2133 Kubeletのクレデンシャルプロバイダー
ステージ：アルファ
機能グループ：クラウドプロバイダー
この機能拡張は、クラウドプロバイダー固有のSDKをツリー外に移動させるために行われた作業で構成されています。特に、ツリー内のコンテナイメージレジストリのクレデンシャルプロバイダーを、外部でプラグイン可能な新しいメカニズムに置き換えています。
クレデンシャルプロバイダーを構築する方法については、KEPで詳細な情報を得ることができます。
#667 ツリー外のAzureクラウドプロバイダーをサポート
ステージ：ベータへ移行
機能グループ：クラウドプロバイダー
この機能拡張には、kube-controller-manager の既存のコードと機能のパリティを維持しつつ、Azure クラウドプロバイダーをツリーの外に移動させるために行った作業が含まれています。
#1748 ポッドモデルを表すリソースリクエストとリミットに関するメトリクスを公開
ステージ：アルファ
特徴グループ：インストルメンテーション
kube-schedulerは、リクエストされたリソースと実行中のすべてのポッドの必要なリミットに関するより多くのメトリクスを公開するようになりました。これにより、クラスター管理者がより良いキャパシティ計画を立てたり、エラーをトリアージしたりするのに役立ちます。
メトリクスは --show-hidden-metrics-for-version=1.20 フラグを使用すると、HTTP エンドポイント /metrics/resources で公開されます。
#1753 Kubernetes システムコンポーネントのログのサニタイズ
ステージ：アルファ
特徴グループ：インストルメンテーション
この機能強化は、パスワードやトークンなどのセンシティブなデータがKubernetesのログに漏れないようにすることを目的としています。
機密性の高いフィールドにはタグが付けられています。
type ConfigMap struct {
Data map[string]string `json:"data,omitempty" datapolicy:"password,token,security-key"`
}
これにより、ログ出力ではそれらの情報を隠蔽することができるようになります。
サニタイズフィルタは --experimental-logging-sanitization フラグが使用されたときに起動します。しかし、現在の実装では顕著なパフォーマンスの低下があり、ユーザのワークロードによって機密データが漏洩する可能性があることに注意してください。
#1933 静的分析によるロギングシークレットからの防御
ステージ：アルファ
特徴グループ：インストルメンテーション
前回の拡張機能#1753を準備している間、go-flow-leveeを使用して、機密データがどこで使用されているかのインサイトを提供していました。
#1435 type=LoadBalancerを使用したサービスでの混合プロトコルのサポート
ステージ：アルファ
機能グループ：ネットワーク
現在のロードバランサーサービスの実装では、同じポート（UDP、TCP）の下で異なるプロトコルを使用することはできません。これは、一部のクラウド実装でロードバランサーの請求書に負のサプライズが発生するのを避けるためです。
しかし、ユーザーはDNSやSIPサーバーに対してUDPとTCPの両方のリクエストを同じポートで提供したいと思うかもしれません。
この機能拡張は、この制限を取り除き、異なるクラウド上での課金への影響を調査するための作業で構成されています。
#1864 サービスタイプ=LoadBalancerのNodePortsをオプションで無効にする
ステージ：アルファ
機能グループ：ネットワーク
LoadBalancer APIの実装によっては、MetalLBやkube-routerのようにKubernetesが自動的に割り当てたノードポートを消費しないものもあります。しかし、APIではポートを定義して割り当てる必要があります。
そのため、ロードバランサーの数は利用可能なポート数に制限されます。また、これらの割り当てられているが使用されていないポートが公開され、コンプライアンス要件に影響を与えます。
この問題を解決するために、Service.Spec.SampleにallocateLoadBalancerNodePortフィールドが追加されました。falseに設定すると、新しいノードポートの割り当てを停止します（ただし、既存のポートは解放されません）。
#1672 終了エンドポイントの追跡
ステージ：アルファ
機能グループ：ネットワーク
Kubeletがグレースフルシャットダウンを開始すると、シャットダウンしたPodはEndpointsから削除されます（有効な場合はEndpointSliceからも削除されます）。EndpointSlice APIのコンシューマがどのPodが終了しているかを知りたい場合は、Podを直接監視しなければなりません。これは物事を複雑にし、スケーラビリティにも影響します。
この機能拡張により、EndpointConditions構造体に新しいTerminateフィールドが追加されました。このようにして、EndpointSlice APIでTerminatingポッドを保持できるようになりました。
長期的には、これによりサービスがTerminatingポッドをよりインテリジェントに処理できるようになります。例えば、IPVS proxierは、コネクション追跡テーブルからその情報を推測する代わりに、Terminating時にエンドポイントの重みを 0 に設定することができます。
#614 サービス、ポッド、エンドポイント、NetworkPolicy のための SCTP サポート
ステージ：ステーブルへ移行
機能グループ：ネットワーク
SCTPは、Pod、Service、Endpoint、NetworkPolicyでTCPとUDPと並んで追加プロトコルとしてサポートされるようになりました。
Kubernetes 1.12で導入されたこの機能は、ついにStableに移行します。
#1507 サービスとエンドポイントにAppProtocolを追加する
ステージ：ステーブルへ移行
機能グループ：ネットワーク
EndpointSlice APIでは、Kubernetes 1.17で新しいAppProtocolフィールドが追加され、ポートごとにアプリケーションプロトコルを指定できるようになりました。この機能拡張により、そのフィールドがServicePortおよびEndpointPortリソースに追加され、ユーザーエクスペリエンスの低下を引き起こしている非標準のアノテーションが置き換えられます。
当初は Kubernetes 1.18 で導入されましたが、現在はStableに移行しています。
#752 EndpointSlice API
ステージ：ベータへ移行
機能グループ：ネットワーク
新しいEndpointSlice APIは、エンドポイントを複数のEndpoint Sliceリソースに分割します。これにより、現在のAPIでは大きなEndpointsオブジェクトに関連する多くの問題が解決されます。また、この新しいAPIは、ポッドごとの複数のIPなど、将来的な他の機能もサポートするように設計されています。
Kubernetes 1.20では、Topologyが非推奨となり、新しいNodeNameフィールドが追加されました。詳細はロールアウト計画をチェックしてください。
1.16のリリースについての詳細はWhat's new in Kubernetesシリーズをご覧ください。
#563 IPv4/IPv6デュアルスタックサポートの追加
ステージ：アルファへ移行
機能グループ：ネットワーク
この機能は、クラスターでデュアルスタックモードをネイティブにサポートするために行った作業をまとめたもので、与えられたポッドにIPv4とIPv6の両方のアドレスを割り当てることができます。
1.16のリリースについては、What's new in Kubernetesシリーズの続きをお読みください。
Kubernetes 1.20ではこの機能の大規模なオーバーホールが行われていますが、この機能がまだAlpha上にあるのはそのためです。
ユーザー向けの大きな変更点は、.spec.ipFamilyPolicyフィールドの導入です。これは以下のように設定できます：SingleStack、PreferDualStack、RequireDualStackに設定できます。
デュアルスタックは多くのKubernetesサービスに影響を与える大きなプロジェクトなので、アルファステージを離れる前に新たな改善や変更を期待してください。
#1967 メモリでバックアップされたボリュームのサイズ設定のサポート
ステージ：アルファ
機能グループ：ノード
Podがメモリバックアップされた空のdirボリューム(tmpfsなど)を定義している場合、すべてのホストがこのボリュームのサイズを等しくするわけではありません。例えば、Linuxホストでは、ホスト上のメモリの50%のサイズにしています。
これはいくつかのレベルで意味があります。例えば、Podの動作はデプロイ先のホストに依存するため、移植性が低くなります。また、このメモリ使用量はevictionヒューリスティックには透過的ではありません。
この新しい機能拡張では、SizeMemoryBackedVolumes機能ゲートを有効にした後、ノードの割り当て可能なメモリだけでなく、ポッドの割り当て可能なメモリとemptyDir.sizeLimitフィールドを考慮して、これらのボリュームのサイズを決定します。
#1972 Kubelet exec プローブのタイムアウトを修正
ステージ：ステーブル
機能グループ：ノード
これで、Kubelet の exec プローブは timeoutSeconds フィールドを尊重するようになりました。
これはバグフィックスなので、この機能はそのままステーブルに移行します。ExecProbeTimeout機能のゲートを無効にすることで、以前の動作に戻すことができます。
#2000 ノードのグレースフルシャットダウン
ステージ：アルファ
機能グループ：ノード
GracefulNodeShutdown機能ゲートを有効にすると、Kubeletはシャットダウン時にノード内で実行中のポッドをグレースフルに終了させようとします。この実装は、systemdのsystemd inhibitor locksをリッスンすることで動作します(Linuxの場合)。
新しいKubelet設定のkubeletConfig.ShutdownGracePeriodは、Podsがどのくらいの時間でグレースフルに終了するかを決定します。
この機能強化により、いくつかのワークロードの問題を緩和し、管理者や開発者の生活を楽にすることができます。例えば、コールドシャットダウンは開いているファイルを破損させたり、リソースを望ましくない状態にしてしまうことがあります。
#2053 hugepagesにおけるダウンワードAPIサポートを追加
ステージ：アルファ
機能グループ：ノード
DownwardAPIHugePages機能ゲートを介して有効にすると、PodsはダウンワードAPIを介してhugepagesのリクエストと制限に関する情報を取得できるようになります。これにより、CPU、メモリ、エフェメラルストレージなどの他のリソースとの整合性が保たれます。
#585 RuntimeClass
ステージ：ステーブルへ移行
機能グループ：ノード
RuntimeClassリソースは、クラスター（Docker、rkt、gVisorなど）で複数のランタイムをサポートするためのメカニズムを提供し、そのコンテナランタイムに関する情報をコントロールプレーンに表面化します。
例えば、以下のようになります。
apiVersion: v1 kind: Pod metadata: name: mypod spec: runtimeClassName: sandboxed
# ...
このYAMLは、このポッドを実行するためにサンドボックス化されたRuntimeClassを使用するようにKubeletに指示します。このセレクタは、rktやgVisorのようなDockerを超えた複数のコンテナランタイムエンジンに動的に適応するために必要です。
Kubernetes 1.12で導入されたこの機能は、最終的にステーブルへ移行します。
#606 サードパーティのデバイス監視プラグインをサポート
ステージ：ステーブルへ移行
機能グループ：ノード
この機能により、Kubelet はサードパーティの監視プラグインにコンテナのバインディングを公開できるようになります。
この実装により、管理者はサードパーティのデバイスモニタリングエージェントを使用してコンテナへのカスタムリソース割り当てを監視できるようになります（例えば、ポッドごとのGPU使用率など）。
1.15のリリースについての詳細は、What's new in Kubernetesシリーズを参照してください。
#757 PID制限
ステージ：ステーブルへ移行
機能グループ：ノード
PID はどのホストでも基本的なリソースです。管理者は、ユーザポッドがホストデーモン（ランタイム、Kubelet など）の実行を妨げる可能性のある pid の枯渇を引き起こさないようにするメカニズムを必要とします。
この機能により、特定のポッドが消費できるPIDの数を制限するようにKubeletを設定することができます。PID制限のためのノードレベルのサポートは、機能ゲートSupportNodePidsLimit=trueを明示的に設定する必要がなくなりました。
1.15のリリースについての詳細は、What's new in KubernetesシリーズとKubernetesブログを参照してください。
#950 起動が遅いポッドのためのポッド起動のliveness-probe holdoffを追加
ステージ：ステーブルへ移行
機能グループ：ノード
プローブによって、Kubernetesはアプリケーションの状態を監視することができます。ポッドの起動に時間がかかりすぎると、それらのプローブはポッドが死んだと考え、再起動ループを引き起こす可能性があります。この機能では、ポッドが起動を終了するまで他のすべてのプローブを保留する startupProbe を定義することができます。例えば、以下のようになります。"指定されたHTTPエンドポイントが利用可能になるまでは、起動性のテストを行わないようにします。"
1.16のリリースについては、What's new in Kubernetesシリーズの続きを読んでください。
#693 ノードトポロジーマネージャ
ステージ：ベータへ移行
機能グループ：ノード
機械学習、科学的コンピューティング、金融サービスなどは、計算量が多く、超低レイテンシを必要とするシステムの例です。これらの種類のワークロードでは、コア間のジャンプや他のプロセスと時間を共有するのではなく、1つのCPUコアにプロセスを分離することで利益を得ることができます。
ノードトポロジマネージャは、ハードウェアリソース割り当ての調整を一元化するkubeletコンポーネントです。現在のアプローチでは、このタスクを複数のコンポーネント（CPUマネージャ、デバイスマネージャ、CNI）に分割しているため、最適化されていない割り当てになることがあります。
Kubernetes 1.20では、トポロジヒントをコンテナごと、またはポッドごとに収集すべきスコープを定義できます。
1.16のリリースについての詳細はWhat's new in Kubernetes seriesを参照してください。
#1797 ポッドのホスト名をFQDN(Fully Qualified Domain Name)に設定できるようになりました
ステージ：ベータへ移行
機能グループ：ノード
これでポッドのホスト名をFQDN(Fully Qualified Domain Name)に設定できるようになり、Kubernetesとレガシーアプリケーションの相互運用性が向上しました。
hostnameFQDN: trueに設定した後、Pod内でuname -nを実行すると、fooだけではなくfoo.test.bar.svc.cluster.localが返されます。
この機能はKubernetes 1.19で導入されたもので、詳細は機能拡張案を参照してください。
#1867 Kubeletの機能：AcceleratorUsageのメトリクスを無効にする
ステージ：ベータへ移行
機能グループ：ノード
#606 (サードパーティ製デバイス監視プラグインのサポート) と PodResources API が GA に入ろうとしているため、Kubelet がメトリクスを収集することはもう期待できません。
Kubernetes 1.19で導入されたこのエンハンスメントは、Kubeletがそれらのアクセラレータメトリクスを収集することを廃止するまでのプロセスをまとめたものです。
#2040 KubeletのCRIサポート
ステージ：ベータへ移行
機能グループ：ノード
KubernetesはKubernetes 1.5と同時にContainer Runtime Interface (CRI)のサポートを導入しました。これはプラグインインターフェイスで、Kubeletが再コンパイルの必要なく、多種多様なコンテナランタイムを使用できるようにするものです。これには、CRI-OやcontainerdのようなDockerに代わるものも含まれます。
CRI APIはプロダクションで広くテストされていますが、まだ正式にはAlphaでした。
この機能強化は、CRIが最終的にステーブルに昇格できるように、残りのギャップを特定して閉じるための作業で構成されています。
#2047 CSIServiceAccountToken
ステージ：アルファ
機能グループ：ストレージ
CSIドライバは、ボリュームをマウントするポッドになりすますことができます。この機能は、CSIドライバに必要な権限のみを提供することでセキュリティを向上させます。しかし、現在の実装では、ドライバはサービスアカウントトークンをファイルシステムから直接読み込みます。
この場合のいくつかの欠点は、ドライバがファイルシステムを読み取るためのパーミッションが必要であり、必要以上に多くのシークレットにアクセ スできる可能性があることと、トークンが利用可能であることが保証されていないことである(例: automountServiceAccountToken=false)。
この機能強化により、CSI ドライバは、Kubelet から NodePublishVolume 関数にサービスアカウントトークンを要求できるようになります。また、Kubelet は、どのドライバがどのトークンを利用できるかを制限することができるようになります。そして最後に、ドライバは、RequiresRepublishをtrueに設定することで、NodePublishVolumeを再実行してボリュームを再マウントすることができるようになります。
この最後の機能は、マウントされたボリュームの有効期限が切れて再ログインが必要な場合に便利です。例えば、シークレットvaultなどです。
詳細はKEPで確認してください。
#177 Kubernetesのスナップショット/リストアボリュームのサポート
ステージ：ステーブルへ移行
機能グループ：ストレージ
アルファ版では、Kubernetes 1.12のリリース以来、この機能はようやくStableに移行します。
APIリソースPersistentVolumeとPersistentVolumeClaimがユーザーや管理者のためのボリュームのプロビジョニングに使用されるのと同様に、VolumeSnapshotContentとVolumeSnapshot APIリソースを提供することで、ユーザーや管理者のためのボリュームスナップショットを作成することができます。ボリューム スナップショットについての詳細はこちらをご覧ください。
Kubernetesの新機能シリーズのWhat's new in Kubernetesで1.16のリリースについての詳細はこちらをご覧ください。
#695 ボリュームの所有権変更をスキップする
ステージ：ベータへ移行
機能グループ：ストレージ
ボリュームがコンテナ内にバインドマウントされる前に、そのボリュームのすべてのファイルパーミッションが指定された fsGroup の値に変更されます。これは、非常に大きなボリュームでは処理が遅くなり、データベースのようなパーミッションに敏感なアプリケーションも壊してしまいます。
Kubernetes 1.18 で導入された新しい fsGroupChangePolicy フィールドは、この動作を制御するために追加されました。Alwaysに設定されている場合は、現在の動作を維持します。ただし、OnRootMismatchに設定されている場合、トップレベルのディレクトリが期待されるfsGroupの値と一致しない場合にのみ、ボリュームのパーミッションを変更します。
#1682 CSIドライバがボリュームの所有権の変更をオプトインできるようにしました
ステージ：ベータへ移行
機能グループ：ストレージ
すべてのボリュームが、NFS のように前回の拡張機能 (#695) で述べた fsGroup 操作をサポートしているわけではありません。これにより、ユーザーに報告されるエラーが発生する可能性があります。
この機能拡張では、CSIDriver.Spec.SupportsFSGroup という新しいフィールドが追加され、fsGroup を介したボリュームの所有権の変更をサポートしているかどうかをドライバーが定義できるようになります。
1.19のリリースについては、Kubernetesの新機能シリーズのWhat's new in Kubernetesを参照してください。
その他
#1610 コンテナリソースベースのPod自動スケーリング
ステージ：アルファ
機能グループ：オートスケーリング
現在のHorizontal Pod Autoscaler（HPA）は、そのPodが使用するリソースに基づいてワークロードをスケーリングすることができます。これは、Pod内のすべてのコンテナの使用量を集約したものです。
この機能により、HPAは個々のコンテナのリソース使用量に基づいてワークロードをスケーリングできます。
type: ContainerResource
containerResource:
name: cpu
container: application
target:
type: Utilization
averageUtilization: 60
#1001 WindowsでのCRI-ContainerDのサポート
ステージ：ステーブルへ移行
機能グループ：windows
ContainerDは、Kubernetesと連携するOCI準拠のランタイムで、Windows Server 2019のホストコンテナサービス（HCS v2）をサポートしています。今回のエンハンスメントでは、Windowsにおける ContainerD 1.3 のサポートを Container Runtime Interface (CRI) として導入しています。
1.18のリリースについては、What's new in Kubernetesシリーズで続きをお読みください。
#19 CronJobs (以前はScheduledJobs)
ステージ：ベータへ移行
機能グループ：アプリ
Kubernetes 1.4で導入され、1.8からベータ版として導入されたCronJobsは、いよいよステーブルへの道を歩むことになります。
CronJobsは、UNIXライクなシステム上のcronと同様に、Kubernetesクラスター内で定期的なタスクを実行します。
現在の機能を壊すことなく、現在のコードの主な問題点を解決するために、CronJobsの新しい代替実装が作成されました。
この新しい実装では、スケーラビリティに焦点を当て、より多くのステータス情報を提供し、現在の未解決の問題に対処します。
CronJobControllerV2機能フラグをtrueに設定することで、新しいCronJobsのテストを開始することができます。
#1258 PodTopologySpreadに設定可能なデフォルト制約を追加しました
ステージ：ベータへ移行
機能グループ：スケジューリング
even pod spreadingを活用するためには、各ポッドに独自のスプレッドルールが必要であり、これは面倒な作業になります。
Kubernetes 1.19で導入されたこの機能拡張により、独自のtopologySpreadConstraintsを定義していないすべてのポッドにクラスターレベルで適用されるグローバルなdefaultConstraintsを定義できるようになりました。
以上です。これらの機能を使おうと思っている方は、クラスターをアップグレードする準備をしておきましょう。
この記事がお気に召したのであれば、以前の「What's new in Kubernetes」をチェックしてみてはいかがでしょうか。
また、Kubernetesエコシステムの最新情報をお楽しみになられている方は、クラウドネイティブエコシステムの最新情報を毎月お届けするコンテナニュースレターを購読してください。