Kubernetes 1.22における新機能は?

本文の内容は、2021年7月29日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/kubernetes-1-22-whats-new）を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.22のリリースが間近に迫っています。どこから始めましょうか？
今回のリリースでは、Kubernetes 1.21の50件、Kubernetes 1.20の43件から増加し、56件の機能強化が行われました。56の機能強化のうち、13はステーブル版への移行、24は改善を続ける既存の機能、16は完全な新機能です。

ポッドセキュリティポリシーの置き換え、ルートレスモード、デフォルトでのSeccompの有効化など、セキュリティに焦点を当てた新機能が多いのは素晴らしいことです。

また、今回のバージョンでは、非推奨や削除された機能にも注目してください。

それでは早速、Kubernetes 1.22の新機能を紹介していきましょう。

Kubernetes 1.22 – 編集者の精選：

今回のリリースで最もエキサイティングに見える機能は以下の通りです（ymmv）：

#2579 ポッドセキュリティポリシーの置き換え

Kubernetes 1.21でdeprecatedになった後、Pod Security Policiesの代替品が登場することは知っていましたが、それがどのようなものかは知りませんでした。今回、それが既存のインフラの一部を再利用したAdmission Controllerになることがわかり、嬉しく思っています。

Alvaro Iradier – Software Engineer at Sysdig

#2033 ルートレスモードコンテナ

コンテナをroot権限で実行しないことは、コンテナセキュリティのベストプラクティスのNo.1です。この対策が極限まで進み、Kubernetesのスタック全体をユーザースペースで実行できるようになったのは心強いですね。これで本当にKubernetesのセキュリティが向上しそうです。

Alejandro Villanueva – Product Analyst at Sysdig

#2413 デフォルトでSeccomp

今回のKubernetesのリリースで明らかになったことがあるとすれば、それはセキュリティ第一主義へのシフトです。この追加のセキュリティレイヤーをデフォルトで追加することで、多くの潜在的なエクスプロイトが無意味になります。このようなステップは、人々のKubernetesに対する見方を絶対に変えるでしょう。

Víctor Jiménez – Content Engineering Manager at Sysdig

#2400 ノードスワップサポート

私たちがKubernetesのリリース毎に見たいと思っている小さなディテールの1つで、ヘッドラインにはならないが、生活をずっと楽にしてくれるだろう。Swapはすべての開発者にとって当たり前のことでした。サポートされることで、Kubernetesを使用する際の心配事が一つ減りました。

Michele Zuccala – Director of Open Source Engineering at Sysdig

#2254 #2570 Cgroupsv2

swap と同様に、よりネイティブな Linux の機能がサポートされるのは素晴らしいことです。この場合、Cgroupsv2はMemory QoSの選択肢を増やし、(Kubernetes 1.22では)Kubernetes内で実行されるワークロードのパフォーマンス低下を防ぐことができます。

David de Torres – Manager of engineer at Sysdig

非推奨事項

ベータ版APIと機能の削除

Kat Cosgrove氏が警告したように、Kubernetes 1.22では以下のようないくつかのベータAPIや機能が削除されています：

Ingress
CustomResourceDefinition
ValidatingWebhookConfiguration
MutatingWebhookConfiguration
CertificateSigningRequest

非推奨ではなく、削除されました。つまり、機能フラグで再度有効にすることはできないということです。これらを使用している場合は、ステーブル版に移行する必要があります。

削除の全リストと移行の手順についてはKubernetesブログで確認してください。また、将来のために廃止されたAPIの移行ガイドを近くに置いておきましょう。

#1558 ストリーミングプロキシリダイレクトの非推奨化

機能グループ: ノード

StreamingProxyRedirects機能は、当初、Container Runtime Interfaceの実装によるリクエストのオーバーヘッドを軽減するために開発されました。その理由は、kubeletをバイパスすることで、パフォーマンスに大きな影響を与えないというものでした。

しかし、すべてのリクエストがapiserverに集中しているため、理論的な改善はそれほど重要ではありませんでした。また、セキュリティ上の問題から、ValidateProxyRedirects機能を実装する必要がありました。

1.20で最初に非推奨となったこの機能のゲートは、1.22で無効になりました。Kubernetes 1.24では、これらの機能は削除され、コンテナストリーミングを設定する唯一の方法は、Kubeletプロキシアプローチでローカルリダイレクトを使用することになります。詳細は KEP で確認してください。

#536 トポロジーAPI

機能グループ: ネットワーク

前回のリリースで述べたように、#2433 Topology Aware Hints の強化は、Kubernetes 1.17 で導入された ServiceTopology フィーチャーゲートを置き換えるものです。

#281 DynamicKubeletConfigの非推奨化

機能グループ: ノード

Kubernetes 1.11からベータ版として提供されていたDynamicKubeletConfigについて、Kubernetesチームは開発を継続せずに非推奨とすることを決定しました。

Kubernetes 1.22 API

#555 サーバーサイドの適用

ステージ：ステーブルへ移行
機能グループ: api-machinery

この機能は、ロジックを kubectl apply から apiserver に移行することを目的としています。現在のワークフローの落とし穴のほとんどを修正し、また kubectl や Golang の実装を厳密に必要とせずに、API から直接操作にアクセスできるようにします (例えば curl を使用して)。

詳しくは、”Kubernetes 1.14 – What’s new?“

#1693 警告の仕組み

ステージ：ステーブルへ移行
機能グループ: api-machinery

今後、APIサーバはdeprecation情報を含む警告ヘッダを含むようになります。これには、APIがいつ導入されたか、いつ廃止されるか、いつ削除されるかが含まれます。

詳しくは “Kubernetes 1.19 – What’s new? “の記事をご覧ください。

#2161 全てのネームスペースでのイミュータブルラベルセレクター

ステージ：ステーブルへ移行
機能グループ: api-machinery

すべてのネームスペースに新しいイミュータブルラベル kubernetes.io/metadata.name が追加され、その値はネームスペード名です。このラベルは、前述のNetworkPolicyオブジェクトのように、あらゆるネームスペースセレクターで使用することができます。

詳しくは、”Kubernetes 1.21の新機能は?”

#1040 APIサーバーリクエストの優先度と公平性

ステージ：ベータへ移行
機能グループ: api-machinery

APIPriorityAndFairness機能ゲートは、APIサーバの新しいmax-in-flightリクエストハンドラを有効にします。FlowSchemaオブジェクトで異なるタイプのリクエストを定義し、RequestPriorityオブジェクトでリソースを割り当てることで、KubernetesのAPIサーバーが高負荷時の管理・保守作業に確実に対応できるようになります。

詳しくは、”Kubernetes 1.18の新機能は?“

Kubernetes 1.22におけるApps

#2307 ポッドを長引かせることなくジョブを追跡

ステージ：アルファへ移行
機能グループ: apps

この機能強化により、ジョブが完了したPodを早期に削除できるようになり、クラスター内のリソースが解放されます。

現在のジョブコントローラは、完了したジョブを追跡するために、終了後もPodをLingering状態にしておきます。ジョブが終了して初めてPodが削除され、リソースが解放されます。

新しいアプローチでは、ジョブコントローラは完了したジョブを追跡する一方で、完了したPodを削除することができます。

実装の詳細については、KEPをご覧ください。

#2599 StatefulsetsにminReadySecondsを追加

ステージ：アルファへ移行
機能グループ: apps

この機能強化により、Deployments、DaemonSets、ReplicasSets、およびReplication Controllersですでに利用可能なオプションのminReadySecondsフィールドがStatefulSetsに追加されました。

宣言されていると、新しく作成されたPodは、そのコンテナが指定された秒数の間、クラッシュすることなく準備ができるまで、利用可能とはみなされません。

#19 CronJobs

ステージ：ステーブルへ移行
機能グループ: apps

Kubernetes 1.4で導入され、1.8からはベータ版となっていたCronJobsが、ついにステーブルへの道を歩み始めました。

CronJobsは、UNIX系システムのcronに似た周期的なタスクをKubernetesクラスター内で実行します。

詳しくは、”Kubernetes 1.20の新機能は?“

#85 PodDisruptionBudget eviction

ステージ：ステーブルへ移行
機能グループ: apps

Kubernetes 1.4で導入され、1.5からベータ版が提供されているPodDisruptionBudgetがついにステーブルへ移行しました。

このAPIでは、Podに対してminAvailableなレプリカ数を定義することができます。minAvailableの値に違反する方法でPodを自発的に削除しようとしても、そのPodは削除されません。

Kubernetes 1.21ではPodDisruptionBudgetがGAに移行しましたが、Kubernetes 1.22ではEvictionサブリソースが移行しています。

{
  "apiVersion": "policy/v1",
  "kind": "Eviction",
  "metadata": {
    "name": "quux",
    "namespace": "default"
  }
}

#1591 グラデュエート DaemonSet maxSurge をベータへ

ステージ：ベータへ移行
機能グループ: apps

ローリングアップデートを実行する際に、古いポッドを置き換えるために作成される新しいポッドの数を指定できるようになりました。

この指定は、オプションのspec.strategy.rollingUpdate.maxSurgeフィールドで行います。絶対的な数値を割り当てることで、希望するPodの数を超えて作成されるPodの最大数を伝えることができます。この値には、希望するPod数に対するパーセンテージを指定することもできます。以前の動作に合わせて、デフォルト値は25%です。

#2185 グラデュエート LogarithmicScaleDownをベータへ

ステージ：ベータへ移行
機能グループ: apps

LogarithmicScaleDown機能ゲートを有効にすると、ポッドの半ランダムな選択が、ポッドのタイムスタンプの対数バケットに基づいてReplicaSetsをダウンスケールするために使用されます。

詳しくは”Kubernetes 1.21における新機能は？“の記事をご覧ください。

#2255 PodDeletionCostをベータへ

ステージ：ベータへ移行
機能グループ: apps

controller.kubernetes.io/Pod-deletion-cost=10でPodをアノテーションできるようになり、0がデフォルト値となりました。スケールダウンの際には、削除コストが低いPodを削除するように最善の努力が払われます。

詳しくは “Kubernetes 1.21における新機能は？“の記事をご覧ください。

#2214 ジョブAPIにおけるインデックス付きジョブのセマンティクス

ステージ：ベータへ移行
機能グループ: apps

インデックス付きジョブはKubernetes 1.21で導入され、並列性の高いジョブのスケジューリングを容易にしました。

今回の機能強化では、完了数が固定されたジョブのポッドに完了インデックスを追加し、あきれるほどの並列プログラムの実行をサポートします。

この方法では、環境変数を介してポッドにジョブインデックスを渡すことができ、また、インデックスから構築されたホスト名でポッドが互いにアドレスを指定できるインデックス付きジョブを作成することもできます。

[...]
    spec:
      subdomain: my-job-svc
      containers:
      - name: task
        image: registry.example.com/processing-image
        command: ["./process",  "--index", "$JOB_COMPLETION_INDEX", "--hosts-pattern", "my-job-{{.id}}.my-job-svc"]

#2232 ジョブAPIにサスペンドフィールドを追加

ステージ：ベータへ移行
機能グループ: apps

Kubernetes 1.21から、ジョブの.spec.suspendフィールドをtrueにすることでジョブを一時的に中断し、後でfalseに戻すことで再開することができるようになりました。

Kubernetes 1.22 認証

#2579 ポッドセキュリティポリシーの置き換え

ステージ：アルファへ移行
機能グループ: auth

Kubernetes 1.21で非推奨となったPod Security Policiesを置き換えるために、新しいPodSecurity admission controllerが利用できます。

この新しいアドミッションコントローラーは、ネームスペースごとにPod Security Standardsを強制することができるようになります。エンフォースは3つのレベルで行うことができます：

enforce：ポリシー違反があった場合、ポッドが拒否されます。
audit：ポリシー違反があると、監査アノテーションが追加されますが、それ以外は許可されます。
warn：ポリシー違反があると、ユーザーに警告が表示されますが、それ以外は許可されます。

これはAdmissionConfigurationファイルで設定できるようになります：

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    defaults:  # Defaults applied when a mode label is not set.
      enforce:         <default enforce policy level>
      enforce-version: <default enforce policy version>
      audit:         <default audit policy level>
      audit-version: <default audit policy version>
      warn:          <default warn policy level>
      warn-version:  <default warn policy version>
    exemptions:
      usernames:         [ <array of authenticated usernames to exempt> ]
      runtimeClassNames: [ <array of runtime class names to exempt> ]
      namespaces:        [ <array of namespaces to exempt> ]

この機能強化の理由や今後の展開については、KEPを参照してください。

#541 External client-goクレデンシャルプロバイダー

ステージ：ステーブルへ移行
機能グループ: auth

この機能拡張により、Go クライアントは、キーマネージメントシステム (KMS)、トラステッドプラットフォームモジュール (TPM)、またはハードウェアセキュリティモジュール (HSM) のような、外部のクレデンシャルプロバイダーを使用して認証できるようになります。

これらのデバイスは、すでに他のサービスに対する認証に使用されており、ローテートさせることが容易で、ディスク上にファイルとして存在しないため、より安全性が高くなっています。

Kubernetes 1.10で導入されたこの機能は、1.20と1.21で行われた作業を終了するものです。

#542 バウンドサービスアカウントトークンボリューム

ステージ：ステーブルへ移行
機能グループ: auth

ワークロードがAPIの認証に使用する現在のJSON Web Tokens (JWT)には、セキュリティ上の問題があります。この機能強化は、JWTのためのより安全なAPIを作成するための作業を構成しています。

詳しくは、”Kubernetes 1.20における新機能は？”をご覧ください。

#2784 CSRの期間

ステージ：ベータへ移行
機能グループ: auth

これまで、Certificates APIのクライアントは、発行された証明書の期間を指定してリクエストすることができませんでした。

この期間のデフォルトは、新しい証明書ごとに1年となっており、ユースケースによっては長すぎる場合がありました。

CetificateSigningRequestSpecに新しいExpirationSecondsフィールドが追加され、600秒（10分）の最小値を受け入れるようになりました。

Kubernetes 1.22 ネットワーク

#1669 kube-proxy がターミネートするエンドポイントを扱うようになりました

ステージ：アルファへ移行
機能グループ: network

この機能強化は、externalTrafficPolicy=Local を持つサービスが、エンドポイントの数が 0 に変わるとロードバランサーからのすべてのトラフィックをドロップするというエッジケースに対応するものです。この動作により、このようなサービスではゼロダウンタイムのローリングアップデートが不可能になります。

実装された解決策は、影響を受けるノード上のすべての外部トラフィックを、準備ができているエンドポイントと準備ができていないエンドポイントの両方に送信することです（準備ができているエンドポイントを優先します）。

このエッジケースや実装の詳細については、KEPを参照してください。

#2595 DNS設定の拡張

ステージ：アルファへ移行
機能グループ: network

この機能拡張により、Kubernetes は最近の DNS リゾルバに追いつくために、より多くの DNS 検索パス、およびより長い DNS 検索パスのリストを許可します。

MaxDNSSearchPathsExpanded機能ゲートを有効にすると、2つのDNS設定の制限が変更されます。

MaxDNSSearchPathsが6から32にジャンプします。
MaxDNSSearchListCharsが256から2048に増加します。

#752 EndpointSlice API

ステージ：ステーブルへ移行
機能グループ: network

新しい EndpointSlice API は、エンドポイントを複数の Endpoint Slice リソースに分割します。これにより、大きなEndpointsオブジェクトに関連する現在のAPIの多くの問題が解決されます。また、この新しいAPIは、ポッドごとの複数のIPのような、他の将来の機能をサポートするように設計されています。

Kubernetes 1.22で注目すべき点は、Endpointsリソースが1,000以上のエンドポイントを持つ場合、クラスターはそれらをendpoints.kubernetes.io/over-capacity: truncatedでアノテーションします。

詳しくは “Kubernetes 1.20における新機能は？“の記事をご覧ください。

#1507 サービスとエンドポイントにAppProtocolフィールドが追加されました

ステージ：ステーブルへ移行
機能グループ: network

1.20からステーブルだったServiceAppProtocol機能のゲートが今回削除されました。

詳しくは “Kubernetes 1.18 – What’s new? “の記事をご覧ください。

#1864 LBノードポートを無効にするサービス

ステージ：ベータへ移行
機能グループ: network

LoadBalancer APIの実装の中には、MetalLBやkube-routerのように、Kubernetesによって自動的に割り当てられるノードポートを消費しないものがあります。しかし、このAPIでは、使用していない場合でもポートを定義して割り当てる必要があります。

Service.SpecのフィールドallocateLoadBalancerNodePortにfalseを設定すると、新しいノードポートの割り当てを停止します。

詳しくは、”Kubernetes 1.20における新機能は？”の記事をご覧ください。

#1959 Service LoadBalancer Class

ステージ：ベータへ移行
機能グループ: network

この機能強化により、1つのクラスターで複数のService Type=LoadBalancerの実装を活用できるようになりました。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#2079 ネットワークポリシー EndPort

ステージ：ベータへ移行
機能グループ: network

この機能拡張により、NetworkPolicyのすべてのポートを範囲として定義できるようになります：

spec:
  egress:
  - ports:
    - protocol: TCP
      port: 32000
      endPort: 32768

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#2086 Service InternalTrafficPolicy

ステージ：ベータへ移行
機能グループ: network

Serviceオブジェクトのspec.trafficPolicyフィールドを設定することで、クラスターのトラフィックを最適化できるようになりました。

Clusterに設定すると、ルーティングは通常通りに動作します。
Topologyに設定すると、トポロジーを考慮したルーティングが使用されます。
PreferLocalに設定すると、同じノード上のサービスにトラフィックがリダイレクトされます。
Localに設定すると、同一ノード上のサービスにのみトラフィックを送信します。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#2365 ネームスペースにスコープされたIngressクラスのパラメータ

ステージ：ベータへ移行
機能グループ: network

この機能強化により、Namespaceスコープを持つIngressClassのパラメーターを指定できるようになりました。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

Kubernetes 1.22 ノード

#2033 ルートレスモードコンテナ

ステージ：アルファへ移行
機能グループ: node

コンテナをrootで実行しないことは、コンテナセキュリティのベストプラクティスのNo.1です。

今回の機能強化により、Kubernetesはさらに一歩進んで、Kubernetesスタック全体を非rootユーザーとして実行できるようになりました。これにより、クラスターが侵害された場合、攻撃者は残りのインフラへのアクセスに苦労することになります。

KubeletInUserNamespace機能ゲートを有効にし、これらの手順に従うことで、Kubernetesをルートレスモードで実行することができます。

ただし、対処しなければならない注意点がたくさんあることを覚えておいてください。

#2254 Cgroupsv2

ステージを：アルファへ移行
機能グループ: node

Cgroups は Linux カーネルの機能で、プロセスの集合体のリソース使用量 (CPU、メモリ、ディスク I/O、ネットワークなど) を制限し、計算し、分離するものです。Cgroupsのv2 APIは2年以上前にステーブルとして発表されており、多くのLinuxディストリビューションではすでにデフォルトで使用されています。

この機能拡張は、KubernetesをCgroups v2と互換性のあるものにするために行われた作業をカバーしており、設定ファイルから始まります。

新しい設定値は、値の範囲にいくつかの変更があるため、確認してください。例えば、cpu.weightの値は[2-262144]から[1-10000]に変更されます。

この機能強化は、v1では利用できないv2の新機能の有効化には対応していません。また、v1の非推奨化にも対応していません。

#2400 ノードスワップのサポート

ステージ：アルファへ移行
機能グループ: node

スワップ(Linuxにおけるディスクメモリ)は最速ではありません。しかし、JavaやNodeアプリケーションのように、その恩恵を受けるワークロードがいくつかあります。

今回の機能強化により、Kubernetesのワークロードがスワップを使用できるようになりました。今のところ、この設定はノード全体のグローバルなもので、ワークロードごとに設定することはできません。使用するには：

対象となるワーカーノードにスワップをプロビジョニングします。
kubeletでNodeMemorySwap機能フラグを有効にします。
–fail-on-swap フラグを false に設定します。
オプションとして、Kubernetesワークロードがスワップを使用できるように、kubeletの設定でMemorySwap.SwapBehavior=UnlimitedSwapを設定します。

実装の詳細については、KEP を参照してください。

#2413 デフォルトでのSeccomp

ステージ：アルファへ移行
機能グループ: node

Kubernetes では現在、Seccomp プロファイルを使用してコンテナを実行することで、コンテナのセキュリティを高めることができます。

今回の機能強化により、このオプションがデフォルトで有効になり、CVEやゼロデイ脆弱性の防止に役立ちます。この動作を有効にするには、既存のRuntimeDefaultプロファイルを任意のコンテナのデフォルトにするSeccompDefaultが必要です。

#2570 cgroupsv2 によるメモリ QoS

ステージ：アルファへ移行
機能グループ: node

Cgroupsv2 がサポートされたので、その新機能のサポートが開始されました。

以下のオプションでMemory QoSを設定できるようになりました。

memory.min: Cgroup が常に保持しなければならないメモリの最小量。
memory.max: 最終的な保護メカニズムとして機能する、メモリ使用量のハードリミット。
memory.low:ベストエフォート型のメモリ保護で、cgroup とその子孫すべてがこの閾値を下回っている場合、保護されていない cgroup からメモリを再利用できない場合を除き、cgroup のメモリは再利用されないという「ソフトな保証」です。今のところまだ考慮されていません。
memory.high:Cgroupのメモリ使用量がここで指定された上限を超えた場合、そのCgroupのプロセスがスロットルされ、リクレームのプレッシャーが強くなります。

#2625 新しいCPU Managerポリシー

ステージ：アルファへ移行
機能グループ: node

この機能拡張により、CPU Managerが特定のCPUコアに排他的なワークロードを割り当てることができるようになりました。CPU コアごとにワークロードを分離することで、コンテキストやキャッシュの切り替えを回避できます。これは、レイテンシーを重視するアプリケーションにとって重要です。

CPU Managerには、新しい–cpu-manager-policy-optionsオプションが用意されています。full-pcups-only=trueに設定すると、ノードは物理的なCPUコアごとにワークロードを分離します。ただし、CPU全体を使用するワークロードのみを受け入れることに注意してください。

#1539 HugePageStorageMediumSize

ステージ：ステーブルへ移行
機能グループ: node

Kubernetes 1.18 で HugePages 機能に追加されたこれら 2 つの機能強化がステーブルとなりました。

まず、ポッドが異なるサイズのHugePagesを要求できるようになりました。

そして2つ目は、ポッドが要求された以上のメモリを使用してリソース飢餓に陥る問題を解決するために、HugePagesのコンテナ分離が実施されました。

詳しくは、”Kubernetes 1.18 – What’s new?”の記事をご覧ください。

#1797 Pod FQDN設定

ステージ：ステーブルへ移行
機能グループ: node

ポッドのホスト名をFQDN（Fully Qualified Domain Name）に設定できるようになり、Kubernetesとレガシーアプリケーションの相互運用性が高まりました。

hostnameFQDN: trueを設定すると、Pod内でuname -nを実行すると、単なるfooではなく、foo.test.bar.svc.cluster.localが返されます。

この機能はKubernetes 1.19で導入され、詳細はenhancement proposalに記載されています。

#277 エフェメラルコンテナ

ステージ：ベータへ移行
機能グループ: node

エフェメラルコンテナは、実行中のポッドをデバッグするのに最適な方法です。作成後のポッドに通常のコンテナを追加することはできませんが、kubectl debugでエフェメラルコンテナを実行することができます。

詳しくは、”Kubernetes 1.16 – What’s new?”の記事をご覧ください。

#1769 Memory Manager

ステージ：ベータへ移行
機能グループ: node

新しいMemory Managerコンポーネントがkubeletで利用可能になり、Podのメモリとhugepagesの割り当てを保証します。このコンポーネントは、保証されたQoSクラスのPodに対してのみ動作します。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#1967 メモリバックされたボリュームのサイズ設定のサポート

ステージ：ベータへ移行
機能グループ: node

Podがメモリバックされた空のdirボリューム（tmpfsなど）を定義したとき、すべてのホストがこのボリュームを同じようにサイズ調整するとは限りません。例えば、Linuxホストでは、ホスト上のメモリの50％に合わせてサイズを設定します。今回の機能強化では、ノードの割り当て可能なメモリだけでなく、ポッドの割り当て可能なメモリとemptyDir.sizeLimitフィールドも考慮してボリュームのサイズを決定します。

詳しくは “Kubernetes 1.20における新機能は？ “をご覧ください。

#2238 プローブの猶予期間を設定可能に

ステージ：ベータへ移行
機能グループ: node

この拡張機能により、livenessProbeオブジェクト内に2番目のterminationGracePeriodSecondsフィールドが導入され、2つの状況が区別されます。通常の状況でKubernetesがコンテナーを強制終了するのを待機する時間と、livenessProbeの失敗による強制終了はいつか。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

Kubernetes 1.22 スケジューリング

#785 スケジューラー Component Config API

ステージ：ベータへ移行
機能グループ: scheduling

ComponentConfigは、コンポーネントの設定をよりダイナミックにし、Kubernetes APIから直接アクセスできるようにするための継続的な取り組みです。

詳細は “Kubernetes 1.19 – What’s new? “をご覧ください。

#1923 新しいスケジューリングサイクルでのホーナーノミネイテッドノード

ステージ：ベータへ移行
機能グループ: scheduling

この機能は、大規模なクラスターでのスケジューリングプロセスを高速化するために、Pod内の.status.nominatedNodeNameフィールドで優先ノードを定義することができます。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#2249 ネームスペースセレクターがベータへ

ステージ：ベータへ移行
機能グループ: scheduling

デプロイメントでノードアフィニティを定義することで、ポッドがスケジュールされるノードを制約することができます。たとえば、example-labelのlabel-valueを持つPodをすでに実行しているノードにデプロイします。

この機能強化により、namespaceSelectorフィールドが追加され、名前ではなくラベルでネームスペースを指定できるようになりました。このフィールドを使えば、ネームスペースのセットを動的に定義することができます。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#2458 ノードリソースのための単一のスコアリングプラグイン

ステージ：ベータへ移行
機能グループ: scheduling

デフォルトのスケジューラーの3つのスコアプラグイン(NodeResourcesLeastAllocated, NodeResourcesMostAllocated, RequestedToCapacityRatio)は、優先的なリソース割り当てのための相互に排他的な戦略を実装しています。

今回の機能強化では、これらのプラグインを非推奨とし、LeastAllocated（デフォルト）、MostAllocated、RequestedToCapacityRatioに設定可能なScoringStrategyプロパティを使用して、単一のNodeResourcesFitプラグインにまとめることで、スケジューラを簡素化しています。

Kubernetes 1.22 ストレージ

#2317 FSGroupをKubeletではなくCSI Driverに委ねる

ステージ：アルファへ移行
機能グループ: storage

CSI ボリュームがコンテナ内にバインドマウントされる前に、Kubernetes は fsGroup を介してボリュームの所有権を変更します。ほとんどのボリュームプラグインでは、kubeletはボリューム内のファイルとディレクトリを再帰的にchownおよびchmodすることでこれを行います。しかし、chownおよびchmodはunixのプリミティブであるため、AzureFileのような一部のCSIドライバーでは利用できません。

今回の機能強化では、CSIドライバーにポッドのfsgroupを明示的なフィールドとして提供することを提案していますので、マウント時にCSIドライバーがネイティブに適用することができます。

この動作は、VOLUME_MOUNT_GROUP NodeServiceCapabilityをサポートするドライバーに対して、DelegateFSGroupToCSIDriver機能ゲートで有効にすることができます。fsGroupはsecurityContextで指定する必要があります。

#2485 新しいRWOアクセスモード

ステージ：アルファへ移行
機能グループ: storage

今回の機能拡張により、ReadWriteOncePodモードでPersistenVolumesにアクセスできるようになり、単一ノードの単一ポッドへのアクセスが制限されるようになりました。

既存のReadWriteOnceのアクセスモードでは、1つのノードへのアクセスが制限されますが、そのノード上の多くのポッドからの同時アクセスが可能です。

この新しいモードは、PersistenVolumesのメンテナンス作業に最適です。

#2047 CSIServiceAccountToken

ステージ：ステーブルへ移行
機能グループ: storage

この機能拡張により、CSIドライバーはKubeletからNodePublishVolume関数にサービスアカウントトークンを要求できるようになります。また、Kubeletはどのドライバーがどのトークンを利用できるかを制限できるようになります。そして最後に、ドライバーは RequiresRepublish を true に設定することで、NodePublishVolume を再実行してボリュームを再マウントすることができるようになります。

この最後の機能は、マウントされたボリュームが期限切れになることがあり、再ログインが必要な場合に便利です。例えば、secrets vaultのような場合です。

詳しくは、”Kubernetes 1.20における新機能は？”の記事をご覧ください。

#1495 ボリュームポピュレーターデータソース

ステージ：ベータへ移行
機能グループ: storage

Kubernetes 1.18で導入されたこの機能拡張は、ユーザーが事前に入力されたボリュームを作成できるようにするための基盤を確立します。例えば、仮想マシンのディスクにOSイメージを事前に入力したり、データのバックアップとリストアを可能にしたりします。

これを実現するために、パーシステントボリュームのDataSourceフィールドに対する現在のバリデーションが解除され、任意のオブジェクトを値として設定できるようになります。なお、ボリュームに値を設定する方法の詳細は、目的に応じたコントローラに委ねられます。

Kubernetes 1.22 Windowsサポート

#1981 Windows 特権コンテナ

ステージ：アルファへ移行
機能グループ: Windows

この機能強化により、Linux で利用可能な特権コンテナの機能が Windows ホストにも提供されます。

特権コンテナは、ホスト上で直接実行されているかのように、ホストにアクセスできます。ほとんどのワークロードでは推奨されませんが、管理、セキュリティ、監視の目的では非常に便利です。

クラスターで WindowsHostProcessContainers 機能が有効になっている場合は、pod spec のセキュリティコンテキストに windowsOptions.hostProcess フラグを設定することで、Windows HostProcess ポッドを作成できます。これらのポッド内のすべてのコンテナは、Windows HostProcess コンテナとして実行されなければなりません。

#1122 WindowsでCSIプラグインをサポート

ステージ：ステーブルへ移行
機能グループ: Windows

Container Storage Interface プラグインは、サードパーティのストレージボリュームシステムの開発を可能にするために作成されました。

Kubernetes 1.16以降、Windowsノードは既存のCSIプラグインを使用できるようになりました。現在、この機能はステーブルです。

Kubernetes 1.22 その他の強化点

#647 APIサーバトレーシング

ステージ：アルファへ移行
機能グループ: instrumentation

この機能強化により、API Server が改善され、OpenTelemetry ライブラリや OpenTelemetry フォーマットを使用したリクエストのトレースが可能になりました。

APIServerTracing機能のゲートを経由して、–tracing-config-file=<path-to-config>を指定してapiserverを起動することで、トレースを有効にすることができます（設定ファイルは次のようになります）。

apiVersion: apiserver.config.k8s.io/v1alpha1
kind: TracingConfiguration
# default value
#endpoint: localhost:4317
samplingRatePerMillion: 100

#2568 kubeadmでコントロールプレーンを非rootで実行する

ステージ：アルファへ移行
機能グループ: cluster-lifecycle

#2033 Rootless mode containers に関連して、kubeadm でコントロールプレーンを non-root で実行できるようにするための作業をまとめた機能強化です。

#970 kubeadm: kubeadm configrationのグラデュエート

ステージ：ベータへ移行
機能グループ: cluster-lifecycle

時間の経過とともに、kubeadmの設定ファイルでは、Kubernetesクラスターの作成を設定するためのオプションの数が大幅に増加しましたが、CLIパラメータの数は同じに保たれています。その結果、いくつかの特定のユースケースでクラスターを作成するには、configファイルが唯一の手段となっています。

この機能の目的は、コンフィグの永続化方法を再設計し、現在のバージョンを改善し、すべてのオプションを含む単一のフラットファイルの代わりに、サブストラクチャーを使用した高可用性クラスターのサポートを強化することです。

詳しくは、”Kubernetes 1.15 – What’s new?”の記事をご覧ください。

#2436 クラウドコントローラーマネージャーのリーダーマイグレーション

ステージ：ベータへ移行
機能グループ: cloud-provider

以前から議論してきたように、クラウドプロバイダーに特化したコードをKubernetesのコアコードの外（in-treeからout-of-treeへ）に移す取り組みが活発に行われています。

今回の機能強化では、コントロールプレーンの可用性に関する厳しい要件を持つスターの移行プロセスを確立しています。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

#859 httpリクエストヘッダにkubectlコマンドのメタデータを含める

ステージ：ベータへ移行
機能グループ: cli

今後、kubectl は API サーバへのリクエストに追加の HTTP ヘッダを含めるようになります。どのkubectlコマンドが特定のリクエストを引き起こしたかを知ることで、管理者はトラブルシューティングやベストプラクティスの実施に役立つ情報を得ることができます。

詳しくは、”Kubernetes 1.21における新機能は？”の記事をご覧ください。

以上、Kubernetes 1.22についてお伝えしました。これらの機能のいずれかを使用するつもりであれば、クラスターのアップグレードの準備をしてください。

この記事が気に入ったら、以前の「What’s new in Kubernetes」版もチェックしてみてください。

また、Kubernetesエコシステムの最新情報を楽しみたい方は、クラウドネイティブエコシステムで起こっている最もクールなものを毎月メールでお届けするコンテナニュースレターをご購読ください。