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

はじめに

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

変更点の詳細へのリンク

• Metrics Changes と SIG Instrumentation @watawuwu
• Known Issues, Urgent Upgrade Notes @shmurata
• SIG Apps @yosshi_
• SIG API Machinery @Ladicle
• SIG Auth @hiyosi
• SIG CLI @superbrothers
• SIG Cluster Lifecycle @yuanying
• SIG Node @uesyn
• SIG Storage @ysakashita
• SIG Network @tkusumi
• SIG Scheduling @everpeace

What's new!

廃止予定API利用の警告

SIG API Machinery は、kubectl ユーザや API 利用者に表示される「廃止予定 API 利用の警告」とクラスタ管理者に表示されるメトリクスを実装しました。
廃止予定 API へのリクエストには、対象 の API が削除されるリリースと代替 API の情報を含む警告が返されます。
警告は、Admission Webhook、またカスタムリソースの廃止予定のバージョンとして指定することで返すこともできます。

永久にbetaの状態を回避

Kubernetes 1.20以降、SIG Architectureは9ヶ月以内にすべてのREST APIをベータ版から移行するという新しいポリシーを適用します。
この新しいポリシーの背景は、機能が長い間ベータ版に留まることを避けるためです。
新しいAPIがベータに入ると、そのAPIは9ヶ月以内にどちらかに移行することになります。

• GAとし、betaのものを非推奨とする
• 新しいbetaバージョンを出して、古いものを非推奨とする

REST APIが9ヶ月経過すると、次のKubernetesリリースではそのAPIのバージョンは非推奨となります。詳細はKubernetes Blogをご参照ください。

Pod とノードをデバッグする CLI のサポートの拡張

SIG CLI は kubectl によるデバッグを拡張して、新たに2つのデバッグワークフローをサポートします。
コピーの作成による Pod のデバッグとホストの namespaces でのコンテナの作成によるノードにデバッグです。
これらは、次の場合に便利です。

• エフェメラルコンテナが有効になっていないクラスタにデバッグコンテナを挿入する
• クラッシュするコンテナのイメージを変更したり、コマンドを sleep 1d に変更したりすることで、デバッグを容易にする
• ノードのホストファイルシステムの構成ファイルを調べる

これらの新しいワークフローは新しいクラスタ機能を必要としないので、kubectl alpha debug コマンドを使って既存のクラスタで試すことができます。kubectl を使ったデバッグに関するフィードバックをお待ちしています。イシューの作成や Kubernetes Slack #sig-cli チャンネルへの参加、または kubernetes/enhancements#1441 イシューへのコメントで私たちに連絡してください。

構造化ロギング

SIG Instrumentationは、ログメッセージの構造とKubernetesオブジェクトへの参照を標準化しました。構造化されたログにより、ログの解析、処理、保存、クエリ、分析が容易になります。klog ライブラリの新しいメソッドはログメッセージの構造を強制します。

• kube-controller-manager と kube-scheduler の引数に--logging-formatオプションでフォーマットを指定できます。

EndpointSlices がデフォルトで有効化

EndpointSlicesはエキサイティングな新しいAPIで、スケーラブルで拡張可能なEndpoints APIをおきかえるものです。
EndpointSlicesはServiceの後ろにあるPodのIPアドレス、ポート、readiness, トポロジー情報をトラックします。

Kubernetes v1.19で、この機能はデフォルトでkube-proxyで有効化され、Endpointsの代わりにEndpointSlicesを読むようになります。これはほとんど見えない変更ですが、大規模なクラスタでは顕著なスケーラビリティの向上につながるはずです。また、将来のKubernetesのリリースでは、トポロジ・アウェア・ルーティングのような重要な新機能が有効になります。

IngressがGeneral Availabilityへ

SIG NetworkはKubernetes v1.19で広く利用されているIngress APIをgeneral availabilityとしました。
この変更は、Kubernetesのコントリビュータによる長年の努力を認め、Kubernetesの将来のネットワーキングAPIのさらなる作業への道を開くものです。

seccompがGeneral Availabilityへ

KubernetesのseccompサポートがGeneral Available(GA)となりました。この機能はワークロードセキュリティをPodやコンテナのシステムコールを制限することで高めるために利用されます。
これにより、seccompProfile フィールドが Pod と Container securityContext オブジェクトに追加されました。

securityContext:
  seccompProfile:
    type: RuntimeDefault|Localhost|Unconfined # choose one of the three
    localhostProfile: my-profiles/profile-allow.json # only necessary if type == Localhost

seccomp.security.alpha.kubernetes.io/podとcontainer.seccomp.security.alpha.kubernetes.io/...のannotationは非推奨となり、Kubernetes v1.22.0で削除予定です。
いまのところ上記の新たに追加されたフィールドとannotationは相互に変換されるため、クラスタ内の既存のワークロードを変換するアクションは必要ありません。

seccompを用いたコンテナのシステムコールの制限方法についての新しいドキュメントが追加されました。

イメージ生成をコミュニティコントロールへ移行

Kuberenetes v1.19の時点では、Kubernetesコンテナイメージは{asia,eu,us}.gcr.io/k8s-artifacts-prodにあるコミュニティ制御のストレージバケットに格納されています。k8s.gcr.io バニティドメインはこの新しいバケットに更新されました。これにより、プロダクション・アーティファクトはコミュニティの管理下に置かれるようになりました。

KubeSchedulerConfigurationがbetaへ

SIG SchedulingはKubeSchedulerConfigurationをBetaへ昇格しました。KubeSchedulerConfiguration機能によりkube-schedulerのアルゴリズムや特定の設定をチューニングできます。選択したスケジューリングフェーズの特定の機能（プラグインに含まれる）を簡単に有効化したり無効化したりすることができます。さらに、一つのkube-schedulerインスタンスから、プロファイルと呼ばれる異なる設定を提供することができます。Podは.spec.schedulerNameフィールドでスケジュールしたいプロファイルを選択することができます。

CSI Migration - AzureDisk and vSphere（beta)

In-treeのVolume plugin と関連する全てのcloud providerはKubernetes coreの外に移動されます。
CSI migration機能により、全てのボリュームのオペレーションを各々のCSI driverへルーティングすることで、レガシーAPIを使用している既存のVolumeは、コードが削除されても機能し続けることができます。
AzureDiskとvSphereのこの機能の実装はベータに昇格しました。

Storage capacity tracking

これまで、Kubernetesのスケジューラは、追加の永続ストレージがクラスタ内のどこでも利用可能且つ無限の容量をもっているという想定でした。
トポロジーの制約により前者には対応しましたが、しかし、今までのPod スケジューリングは、ストレージの残り容量が新しいPodをスタートさせるのに十分でない可能性があることを考慮していませんでした。
ストレージ容量のトラッキング(アルファ機能)は、CSIドライバー向けにストレージ容量をレポートするAPIを追加することで、KubernetesのスケジューラがPodの新しいノードを選択する際に、この情報を使えるようになりました。
この機能は、容量が制限されるLocal Volumeや他のVolumeタイプのダイナミックプロビジョニングをサポートするための、足がかりとして提供します。

CSI Volume health monitoring

アルファバージョンのCSI ヘルスモニタリングがKubernetes 1.19でリリースされました。
この機能により、CSIドライバーは下位レイヤーのストレージからの異常なボリュームの状態をKubernetesと共有できるようになり、PVCやPodのイベントへ報告できます。
この機能は、Kubernetesにて個々のボリュームのヘルスイシューに対しプログラムでの検出と解決を行うための、足がかりとして提供します。

General ephemeral volumes

Kubernetesは、ライフサイクルがPodに関連づけられているスクラッチスペース(組み込みの"empty dir"のボリュームタイプ)や、Pod内にデータをロードするため(組み込みのConfigMapとSecretのボリュームタイプや"CSI inline volumes")に使用できるvolume pluginsをサポートします。
この新しいgeneric ephemeral volumes のアルファ機能では、ダイナミックプロビジョニングをサポートする既存のストレージドライバーをボリュームのライフサイクルがPodに結び付けられたephemeral volumeとして使用できるようになりました。
これを利用して、rootディスクが異なるスクラッチストレージ(例えば persistent memory)や、ノード上で分かれているローカルディスクを提供できます。
ボリュームプロビジョニングのためのStorageClassの全てのパラメータはサポートされています。
Storage capacity trackingやSnapshot/Restore, Volumeのサイズ変更など、PersistentVolumeClaimの全ての機能はサポートされています

Immutable Secrets and ConfigMaps (beta)

SecretとConfigMap volumeはimmutableとしてマークできます。
これにより、クラスタ内に多くのSecretとConfigMap volumeがある場合に、API サーバの負荷を大幅に削減できます。
詳細については、ConfigMapとSecretをご参照ください。

CSI Proxy for Windows

Windows向けCSI Proxyが1.19でベータに昇格しました。
CSI Proxyは、Windowsのコンテナが特権のストレージ操作を実行できるようにすることで、CSI ドライバーがWindwos上で実行できるようにしました。
ベータでは、Windows用のCSI Proxyはダイレクトアタッチトディスク(DAS)とSMBを使用するストレージドライバーをサポートしました。

Dashboard v2

SIG UIはKubernetes Dashboardのv2をリリースしました。kubernetes/dashboardリポジトリに最新のリリースがあります。Kubernetes DashboardはCRDはCRDをサポートし、新たな翻訳、そしてAngularJSのバージョンアップを含みます。

Windowsのcontainerd サポートがbetaへ

Kubernetes v1.18で最初に導入されたWindowsのcontainerdサポートはこのリリースでbetaとなります。これはWindows Server version 2004のサポート追加を含みます。(完全なバージョンの互換性はWindowsのためのドキュメントにあります)

SIG Windowsはこのリリースにもいくつかの追加を含んでいます。

• DSR(Direct Server Return)モードをサポートし、大量のサービスを効率的にスケールアップ可能
• Windows ContainerでCPU Limitを利用可能になりました
• メトリクスの収集と様りのパフォーマンスを向上しました

Kubernetesのサポートウィンドウを1年へ増やす

Kubernetes 1.19時点では、Kubernetesのマイナーリリースのパッチリリースによるバグ修正のサポートは9ヶ月から1年に増加しています。

Long Term Support WGの2019初頭に実施した調査では、かなりの数のKubernetesエンドユーザが以前の9ヶ月のサポート期間内のアップグレードできていません。１年間のサポート期間は、エンドユーザが望んでいるように思われるクッションを提供し、おなじみの年間プランニングサイクルとより調和しています。