本文の内容は、2022年8月16日にDaniel Simionatoが投稿したブログ(https://sysdig.com/blog/kubernetes-1-25-whats-new/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes 1.25がリリースされようとしています。どこから始めましょうか？
今回のリリースでは、Kubernetes 1.24の46、Kubernetes 1.23の45と同レベルの40の機能強化が行われました。この40の機能強化のうち、13はStableへ移行、10は改善を続ける既存機能、15は完全な新規機能、そして2つは非推奨の機能となっています。
このリリースのハイライトは、PodSecurityPoliciesが最終的に削除され、PodSecurity admissionに置き換えられ、最終的にStableへの移行が行われることです。このバージョンでは、すべての非推奨と削除に注意してください！
ユーザーネームスペースのサポート、フォレンジック分析のためのチェックポイント、ボリュームマウント時のSELinuxの改善、NodeExpansion シークレット、公式CVEフィードの改善など、本当に歓迎すべき新しいセキュリティ機能がいくつか追加されています。また、他の機能はクラスター管理者の生活を楽にします。例えば、復帰不可能なPodフェイル、KMS v2の改善、よりクリーンなIPTablesチェーンの所有、PVC上のStorageClassデフォルトのより良い処理などです。
最後に、このリリースのケーキの上のトッピングは、GAステートに到達しているすべての素晴らしい機能です。CSI の移行は、3 年以上続いてきたプロセスであり、ついに最終段階に入ったということで大きな賞賛を浴びています。また、NetworkPolicies のポートレンジ、Ephemeral ボリューム、そして Cgroups v2 のサポートです。
話すことがたくさんあるので、Kubernetes 1.25の最新情報をはじめましょう。
Kubernetes 1.25 - エディターズピック:
今回のリリースで最もエキサイティングに見える機能は、以下の通りです（人によって違うかもしれません）:#127 ユーザーネームスペースのサポート追加
この機能強化は、約6年前に初めてKubernetesに要求されたものです。Kubernetes 1.5でalpha版をターゲットにしていました。この機能を実装するために必要な技術は、しばらく前から存在していました。そしてついに、少なくともalpha版ではありますが、ここに登場しました。Kubernetesのユーザーネームスペースは、ワークロードに課される制約の多くを緩和するのに役立ち、この機能がなければとても安全ではないと考えられている機能を使用できるようになります。願わくば、これによって攻撃者の生活がより困難なものになることも期待しています。
Miguel Hernández – Security Content Engineer at Sysdig
#2008 フォレンジック・コンテナ・チェックポインティング
コンテナチェックポインティングは、特定のコンテナからスナップショットを作成し、そのコピーに対して分析や調査を行うことができるようにします。潜在的な攻撃者に通知することなく、コンテナが破壊される前にキャプチャーすることができれば、これはコンテナのフォレンジック分析にとって素晴らしいツールとなるでしょう。これは、Kubernetesのフォレンジックを永遠に変えるだけでなく、Kubernetesのセキュリティとインシデントレスポンスを提供するすべてのツールを変えることになるでしょう。
Javier Martínez – DevOps Content Engineer at Sysdig
#3329 ジョブに対するRetriableおよびNon-RetriableのPodフェイル
これはKubernetesのJobsに必要な改善点です。現在、ジョブがフェイルし、そのrestartPolicyがOnFailureに設定されている場合、Kubernetesは最大のバックオフ制限まで、そのジョブの再実行を試みます。しかし、フェイルの原因がアプリケーションのエラーであり、それ自体では修正されない場合、これは意味を成しません。今回の機能強化により、フェイルの原因別にポリシーを設定できるようになることで、フェイルすることが決まっているものを無駄に実行することなく、Kubernetesをより効率的に利用できるようになります。また、ジョブが pod evictionに対してより信頼できるようになり、リソースに制約のあるクラスターにおいて管理者が調査しなければならないフェイルしたジョブの数を劇的に減らすことができるようになるのです。
Daniel Simionato – Security Content Engineer at Sysdig
#625 CSIマイグレーション - コア
全く新しい機能ではありませんが、ストレージSIGはこのマイグレーションについて大きな賞賛を受けるに値します。彼らは3年以上にわたってKubernetesコアからCSIドライバーを精力的に移行しており、私たちはリリースに次ぐリリースで彼らのアップデートを追ってきました。そして今、ようやく移行が終わりに近づきました。長期的には、Kubernetesのコードがよりメンテナンスしやすくなり、ストレージ周りの機能がよりクールになることを意味します。次に何が出てくるか、楽しみですね。
Víctor Jiménez Cerrada – Content Manager Engineer at Sysdig
#3299 KMS v2 の改善
この機能強化により、暗号化キーの管理が容易になり、手作業が少なくなります。同時に、暗号鍵のオペレーションも高速化されます。このようなセキュリティの改善は、私たちが望むところです。セキュリティの向上、パフォーマンスの改善、そして管理者の負担軽減です。Devid Dokash – DevOps Content Engineer at Sysdig
#5 PodSecurityPolicy + #2579 Pod Security Control
PodSecurityPolicyは、特別で最後の言及に値すると私は思います。おそらくKubernetesのエコシステムで最も誤解されているコンポーネントの1つでしたが、ついにそれがなくなりました。上流のプロジェクト、この場合はKubernetesの変更は、Red Hat OpenShiftのような他のKubernetesディストリビューションにも影響することを忘れてはなりません。そのため、新しい admission controller Pod Security Control の進め方を説明するアップデートを公開していますが、おそらく複数のエンジニアに頭痛の種がもたらされることでしょう。
PSP、ありがとうございました。
Vicente J. Jiménez Miras – Security Content Engineer at Sysdig
非推奨事項
APIと機能の削除
Kubernetes 1.25では、以下のようないくつかのBeta APIと機能が削除されました。- 提供されなくなった非推奨APIバージョン（より新しいもの）:
- CronJob
batch/v1beta1 - EndpointSlice
discovery.k8s.io/v1beta1 - Event
events.k8s.io/v1beta1 - HorizontalPodAutoscaler
autoscaling/v2beta1 - PodDisruptionBudget
policy/v1beta1 - PodSecurityPolicy
policy/v1beta1 - RuntimeClass
node.k8s.io/v1beta1
- CronJob
- その他のAPIの変更:
-
k8s.io/component-baseは、k8s.io/component-base/logs/api/v1（ログ設定用のGo API）へ移動しました。
-
- その他の変更点:
-
kubectl runコマンドから未使用のフラグを削除しました。 - エンドツーエンドのテストが Ginkgo v1 から v2 に移行されました。
-
Ginkgo.Measureは非推奨になりました。代わりにgomega/gmeasureを使ってください。 - いくつかのapiserverメトリクスが変更されました。
- APIサーバーの
--service-account-api-audiencesフラグを非推奨とし、代わりに--api-audiencesを採用しました。 - seccompのアノテーションを一部削除しました。
- コマンドラインフラグ
enable-taint-managerを非推奨としました。 - 最近再び実装されたschedulability predicateを削除しました。
- Kube-scheduler
ComponentConfigv1beta2 を非推奨としました。 - kubeletは、cAdvisorを介したアクセラレータメトリクスの収集をサポートしなくなりました。
変更点の全リストは、Kubernetes 1.25のリリースノートで確認することができます。また、Kubernetes Removals and Deprecations In 1.25 の記事、および非推奨のAPI移行ガイドを今後のために近くに置いておくことをお勧めします。
#5 PodSecurityPolicy
Stage: 非推奨Feature group: auth
Pod Security Policies (PSP) は、デプロイを制限するための素晴らしいKubernetesネイティブツールです。例えば、実行をユーザーリストに制限したり、ネットワークやボリュームなどのリソースへのアクセスを制限したりできます。
Kubernetes 1.23 - What's new? の記事で取り上げたように、この機能は非推奨となり、#2579 PodSecurity admissionに置き換えられます。ビルトインのPodSecurity admissionプラグインに移行するには、こちらのガイドをご確認ください。
#3446 利用可能なインツリードライバーからGlusterFSプラグインを非推奨にしました
Stage: 非推奨Feature group: ストレージ
#625 CSI migration - coreに続き、Kubernetesコア（in-tree）に含まれていたいくつかのCSIプラグインは、別プロジェクト（out-of-tree）に移行されます。この移行が進むにつれて、インツリーの対応するプラグインも非推奨となります。
GlusterFS以外では、flocker、quobyte、storageosのサポートも終了しています。
Kubernetes 1.25におけるApps
#3329 ジョブのPod障害に対する復帰可能・不可能の設定
Stage: Alpha への新規追加Feature group:apps
Feature gate:
JobBackoffPolicy Default value: false現在、ジョブの再試行を制限するために利用できる唯一のオプションは
.spec.backoffLimitを使うことです。このフィールドはジョブの最大再試行回数を制限し、それ以降は失敗したとみなされます。しかし、これではコンテナの失敗の原因を特定することができません。もし回復不可能なエラーを示す既知の終了コードがあれば、失敗する運命にあるものを再実行するために計算時間を浪費する代わりに、そのジョブを失敗とマークすることが望ましいでしょう。一方、インフラストラクチャーのイベント（Podの先取り、メモリープレッシャーの回避、ノードの消耗など）によりコンテナが失敗した場合、
backoffLimitにカウントされることも好ましくありません。この機能拡張により、Jobs の spec に
.spec.backoffPolicy を設定し、失敗した場合に再試行するかどうかを決定できるようになりました。障害の原因によって異なる動作をさせることで、Kubernetesはインフラストラクチャー障害やアプリケーションエラーの場合にバックオフ時間の増加を避け、早期にジョブを終了させることができます。#1591 DaemonSetsは、ワークロードの可用性を向上させるためにMaxSurgeをサポートする必要があります
Stage: Stableへの移行Feature group: apps
Feature gate:
DaemonSetUpdateSurge Default value: trueローリングアップデートを行う際に、
ec.strategy.rollingUpdate.maxSurge フィールドで、古いPodを置き換えるために新しいPodをいくつ作成するか指定できるようになりました。詳しくは「Kubernetes 1.22の最新情報」の記事でご確認ください。
#2599 StatefulsetsにminReadySecondsを追加しました
Stage: Stableへの移行Feature group: apps
Feature gate:
StatefulSetMinReadySeconds Default value: trueこの機能強化により、
Deployments、 DaemonSets、 ReplicasSets、レプリケーションコントローラーですでに利用可能なオプションの minReadySeconds フィールドが StatefulSets に追加されます。詳しくは「Kubernetes 1.22の最新情報」の記事でご確認ください。
#3140 CronJobのTimeZoneサポート
Stage: Betaへの移行Feature group: apps
Feature gate:
CronJobTimeZone Default value: trueこの機能は、
CronJob リソースでタイムゾーンをサポートするという、遅れていたリクエストに対応するものです。これまで、 CronJobsによって作成されたジョブは、 kube-controller-managerのプロセスが基づいていたタイムゾーンと同じに設定されていました。詳しくは「Kubernetes 1.24の最新情報」記事でご確認ください。
Kubernetes 1.25 Auth
#3299 KMS v2 の改善
Stage: Net Alpha への新規追加Feature group: Auth
Feature gate:
KMSv2 Default value: falseこの新機能は、Key Management Systemのパフォーマンスとメンテナンス性を向上させることを目的としています。
この機能拡張が対処する主な問題の1つは、オブジェクトごとに異なるDEK（Data Encryption Key）を管理しなければならないことによるパフォーマンスの低さです。特に、キャッシュを空にするkube-apiserverプロセスを再起動した後、すべてのシークレットをLISTする操作を行った場合に深刻です。解決策は、ローカルKEKを生成し、KMSのレート制限に当たるのを遅らせることです。
現在、キーをローテートさせるようなタスクは、各kube-apiserverインスタンスの複数回の再起動を伴います。これは、すべてのサーバーが新しいキーを使用して暗号化および復号化できるようにするために必要です。さらに、クラスター内のすべてのシークレットを無差別に再暗号化することは、クラスターを数秒間サービス停止させたり、古い鍵に依存させたりする、リソースを消費するタスクです。本機能により、最新の鍵の自動ローテーションが可能になります。
また、この機能により、現時点ではリソースの暗号化・復号化によって行われるためクラウド環境ではコストのかかる観測可能性やヘルスチェック操作を向上させる機能が追加されます。
クラスターのセキュリティ確保に少しでも貢献できる、とてもエキサイティングな変更です。
詳しくはそのKEPから。
#2579 PodSecurity admission(PodSecurityPolicyの置き換え)
Stage: Stableへの移行Feature group: auth
Feature gate:
PodSecurity Default value: trueKubernetes 1.21で非推奨となったPod Security Policiesに代わり、新しい PodSecurity admission controller がデフォルトで有効化されるようになりました。
詳細はKubernetes 1.22 - What's new?の記事で、さらに詳しい情報は新しいチュートリアルをご覧ください。
Kubernetes 1.25におけるNetwork
#2593 複数のClusterCIDR
Stage: Alphaへ移行Feature group: Network
Feature gate:
ClusterCIDRConfig Default value: falseKubernetesクラスターを作成した後のスケーリングは、本当に難しいものです。ネットワークがオーバーディメンションであれば、多くのIPアドレスを無駄にすることになります。逆に、クラスターをアンダーディメンションにすると、ある時点でクラスターを廃止して、より新しいクラスターを作成しなければならなくなります。
今回の機能強化により、クラスター管理者はより柔軟な方法でネットワーク範囲（
PodCIDR セグメント）を追加してKubernetesクラスターを拡張することができるようになります。KEPでは、3つの明確なユーザーストーリーを定義しています。- セグメントを使い果たし、クラスターをスケールアップすることになった場合に備えて、クラスターにさらにPod IPを追加する。
- 将来のノードで割り当て可能な最大Pod数を2倍にするなど、より高いまたはより低い機能を持つノードを追加する。
- 不連続な範囲のプロビジョニング。ネットワークセグメントが均等に分配されておらず、新しいノードをデプロイするためにそれらの多くをグループ化する必要がある場合に便利です。
ClusterCIDRConfig を作成することで、ノードアロケータで CIDR セグメントを制御できるようになります。この設定は、すでにプロビジョニングされたクラスターに影響を与えたり、再設定したりしないことに注意してください。目標は、Kubernetesに含まれる NodeIPAM の機能を拡張することであり、変更することではありません。#3178 IPTables チェーンの所有権をクリーンアップする
Stage: Alphaへ移行Feature group: Network
Feature gate:
IPTablesOwnershipCleanup Default value: falseクリーンアップは常に、特にあなたのコードにおいて推奨されます。
kubelet は歴史的に、 dockershim や kube-proxyなどのコンポーネントをサポートするためにIPTablesにチェーンを作成してきました。Dockershimの削除はKubernetesにおける大きな一歩でしたが、今はその背後を掃除する時期なのです。kube-proxy はまた別の話です。 kube-proxy が作成したチェーンは、その kube-proxy の所有物ではなく、 kubeletの所有物であると言えるでしょう。あるべきところにあるべきものを置き、kubeletが不要なリソースを作るのを止め、 kube-proxy がそれらを自分で作るようにする時期が来たのです。機能的には大きな変化はありませんが、よりクリーンなクラスターを管理できるようになります。
#2079 NetworkPolicyのポート範囲
Stage: Stableへ移行Feature group: Network
Feature gate:
NetworkPolicyEndPort Default value: trueこの機能拡張により、NetworkPolicyのすべてのポートを範囲として定義できるようになります：
spec:
egress:
- ports:
- protocol: TCP
port: 32000
endPort: 32768
詳細はKubernetes 1.21 - What's new?をご覧ください。#3070 ダイナミックおよびスタティックなIP割り当てのためのサービスIPレンジの確保
Stage: Betaへ移行
Feature group: Network
Feature gate:ServiceIPStaticSubrangeDefault value:true
この--service-cluster-ip-rangeフラグのアップデートにより、静的および動的な IP 割り当てを使用しているサービス間で IP が競合するリスクが低下し、同じタイプで後方互換性が保たれます。
詳しくは、What’s new in Kubernetes 1.24をご覧ください。Kubernetes 1.25 Nodes
#127 ユーザーネームスペースのサポート追加
Stage: Alphaへ移行
Feature group: node
Feature gate:UserNamespacesSupportDefault value:false
非常に待ち望まれていた機能です。Podに与えられた過剰な特権のために、ホストが侵害される脆弱性はたくさんあります。
ユーザーネームスペースは、以前からLinux Kernelでサポートされています。さまざまなコンテナランタイムを通じて、それらをテストすることが可能です。Kubernetesエコシステムに導入することで、新たな可能性が開けることは間違いありません。例えば、あまりにも要求レベルの高いコンテナに対して特権モードで動作していると思わせたり、コンテナイメージのサーフェイスアタックを軽減することなどは、多くの人にとってまだ課題のようです。
最後に誰かがCAP_SYS_ADMIN機能を要求した時のことを覚えていますか？もしあなたが私たちのような人なら、それを与えることを躊躇したことでしょう。さて、今回の機能強化により、これらのパーミッションはPodでは利用できますが、ホストでは利用できなくなります。FUSEファイルシステムをマウントしたり、コンテナ内でVPNを起動したりするのが頭痛の種でなくなるのです。
まだイメージできていないのであれば、もっとわかりやすい言葉で言いましょう。コンテナ内のプロセスは、2つのID（UID/GID）を持つことになります。1つはPodの内部で、もう1つは外部の、より有害な可能性を秘めたホスト上でです。
もう使い始めたいですか？Feature gateUserNamespacesSupportを有効にし、Pod内部のspec.hostUsersの値をfalseに設定します（trueまたはunsetの場合は、現在のKubernetesと同様にホストユーザが使用されます）。ただし、この機能はまだ実運用には適していません。
この機能の詳細については、KEPに追加情報と、この機能がないことで影響を受けるCVEの網羅的なリストがあります。#2008 フォレンジックコンテナチェックポインティング
Stage: Alpha へ移行
Feature group: node
Feature gate:ContainerCheckpointRestoreDefault value:false
コンテナチェックポインティングは、実行中のコンテナのスナップショットを取ることを可能にします。
このスナップショットは、フォレンジック調査を開始する別のノードに転送することができます。解析は影響を受けるコンテナのコピーで行われるため、オリジナルにアクセスできる攻撃者は、このような解析に気づくことはありません。
この機能は、新しく導入されたCRI APIを使用しているため、kubeletはチェックポイントを作成するための1回限りの呼び出しを要求することができます。
スナップショットの作成は/checkpointエンドポイント経由で要求され、--root-dir(デフォルトは/var/lib/kubelet/checkpoints) の下に .tar 形式 (i.e.,checkpoint-<podFullName>-<containerName>-<timestamp>.tar) で格納されることになります。#2831 Kubelet OpenTelemetry トレース
Stage: Alpha へ移行
Feature group: node
Feature gate:KubeletTracingDefault value:false
APIServer の KEP-647 と同様に、この機能拡張では、kubeletで行われる GRPc コールに OpenTelemetry トレースが追加されます。
これらのトレースにより、ノードレベル、たとえば、kubeletとコンテナランタイム間の相互作用に関する洞察を得ることができます。
これは、管理者が Pod の作成または削除、コンテナへのボリュームのアタッチなどの際にノード レベルで発生する待ち時間の問題を調査するのに役立ちます。#3085 pod sandbox ready condition
Stage: Alphaへ移行
Feature group: node
Feature gate:PodHasNetworkConditionDefault value:false
Podサンドボックスが作成され、CRIランタイムがそのネットワークを構成したことをKubeletに示させるために、新しい条件、PodHasNetworkがPod定義に追加されました。この条件は、ContainersReadyやReady条件と同様に、Podのライフサイクルにおける重要なマイルストーンとなります。
これまでは、たとえばPodが正常にスケジュールされてPodScheduled条件がトリガーされると、ネットワークの初期化に関する他の特定の条件は存在しませんでした。
この新しい条件は、CSIプラグイン、CRIランタイム、CNIプラグインなどのような、Podサンドボックスの作成でコンポーネントを設定するクラスターオペレーターに有益です。#3327 CPU Manager ポリシー: ソケットアライメント
Stage: Alpha への新規追加
Feature group: node
Feature gate:CPUManagerPolicyAlphaOptionsDefault value:false
これにより、新しい静的ポリシーであるalign-by-socketが CPUManager に追加され、NUMA境界でCPUの割り当てを調整すると、異なるソケットからCPUを割り当てることになる場合、予測可能なパフォーマンスを達成することができます。
これは、ワークロードが本当に実行される CPU コアをより制御できるようにするためのこれまでの取り組みを補完するものです。
#2254 cgroup v2
Stage: Stableへ移行
Feature group: node
Feature gate: N/A
この機能拡張は、Kubernetes を Cgroups v2 と互換性を持たせるために行われた作業をカバーしており、まず設定ファイルから始まります。
値の範囲にいくつかの変更があるため、新しい設定値を確認してください。例えば、cpu.weightの値は[2-262144]から[1-10000]に変更される予定です。
詳しくは、 “What’s new in Kubernetes 1.22” の記事をご覧ください。#277 エフェメラルコンテナ
Stage: Stableへ移行
Feature group: node
Feature gate:EphemeralContainers Default value: true
エフェメラルコンテナは、実行中のPodをデバッグするのに最適な方法です。作成後のPodに通常のコンテナを追加することはできませんが、kubectl debugでエフェメラルコンテナを実行することは可能です。
詳しくは Kubernetes 1.16 – What’s new? の記事をご覧ください。#1029 エフェメラルストレージクォータ
Stage: Betaへ移行
Feature group: node
Feature gate:LocalStorageCapacityIsolationFSQuotaMonitoring
Default value:true
エフェメラルボリュームを定期的にスキャンするよりも効率的で正確なクォータを計算するための新しいメカニズムです。
詳しくは Kubernetes 1.15 – What’s new? の記事でご確認ください。#2238 プローブに設定可能なgrace periodを追加
Stage: Betaにおけるメジャーチェンジ
Feature group: node
Feature gate:ProbeTerminationGracePeriodDefault value:true
この機能拡張は、2つの状況を区別するために、livenessProbeオブジェクトの内部に2番目のterminationGracePeriodSecondsフィールドを導入します。Kubernetesは、通常の状況下でコンテナをkillするためにどれくらい待つべきか、そしてlivenessProbeの失敗が原因でkillされるのはいつか？
詳しくは Kubernetes 1.21 - What's new? をご覧ください。#2413 デフォルトでseccomp
Stage: Betaへ移行
Feature group: node
Feature gate:SeccompDefaultDefault value:true
Kubernetesはコンテナのセキュリティを向上させ、デフォルトでSeccompプロファイルを使用してコンテナを実行するようになりました。
詳しくは、What’s new in Kubernetes 1.22 の記事をご覧ください。Kubernetes 1.25におけるスケジューリング
#3094 PodTopologySpread Skewの計算時にテイント/トレランスを考慮するようになりました
Stage: Alphaへ移行
Feature group: scheduling
Feature gate:NodeInclusionPolicyInPodTopologySpreadDefault value:false
Kubernetes 1.16 - What's new? の記事で説明したように、topologySpreadConstraintsフィールドでは、ノード間でワークロードを分散できます。これはmaxSkewと一緒に行われ、2つの与えられたトポロジードメイン間のPod数の最大差を表します。
新しく追加されたフィールドNodeInclusionPoliciesでは、NodeAffinityとNodeTaint（値：Respect/Ignore）の両方の値を設定して、このPodトポロジー スプレッド skew の計算時にテイントとトレランスを考慮することができます。-
NodeAffinity: Respectは、nodeAffinityとnodeSelectorに一致するノードがskew プロセスに含まれることを意味します。 -
NodeAffinity: Ignore(default) は、すべてのノードが含まれることを意味します。 -
NodeTaint: Respectは、incoming Podを許容するテイントノードと、通常のノードがskew プロセスに含まれることを意味します。 -
NodeTaint: Ignore(default) は、すべてのノードが含まれることを意味します。
#3243 ローリングアップグレード後のPodTopologySpreadの尊重(レビュー)
Stage: Alpha への新規追加
Feature group: scheduling
Feature gate:MatchLabelKeysInPodTopologySpreadDefault value:falsePodTopologySpreadは、互いに関連するPodがどのように均等に分散されるかをよりよく制御することを容易にします。しかし、新しいPodのセットをデプロイするとき、既存の（すぐになくなる）Podが計算に含まれるため、将来のPodの分布が不均一になる可能性があります。
今回の機能強化では、Podの仕様とその計算アルゴリズムに新しいフィールドを追加し、Podの定義に含まれる任意のラベルを考慮する柔軟性を持たせ、コントローラーがより正確なPodのセットを作成してからスプレッド計算を行うことを可能にしました。
以下の構成では、labelSelectorとmatchLabelKeysという2つの関連フィールドを見ることができます。これまで、labelSelectorだけがトポロジー・ドメイン内のPodの数を決定していました。既知のpod-template-hashのような1つ以上のキーをmatchLabelKeysに追加することで、コントローラーは同じデプロイの下にある異なるReplicaSetからのPodを区別し、より正確な方法でスプレッドを計算することができるようになります。apiVersion: v1 kind: Pod Metadata: name: example-pod Spec: -
- protocol: TCP
Configure a topology spread constraint
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer> # optional; alpha since v1.24
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
matchLabelKeys: <list> # optional; alpha since v1.25
other Pod fields go here
この機能によってあなたの生活が変わることはないかもしれませんし、クラスターのパフォーマンスが変わることもないかもしれません。しかし、もしあなたが自分のPodが思い通りに分散されないことを不思議に思ったなら、ここにその答えがあります。
#785 kube-scheduler ComponentConfigをGAに移行する
Stage: Stableへ移行
Feature group: scheduling
Feature gate: NA
ComponentConfigは、コンポーネント設定をよりダイナミックにし、Kubernetes APIを通じて直接到達できるようにするための継続的な取り組みです。
詳しくは Kubernetes 1.19 – What’s new? の記事をご覧ください。
このバージョンでは、いくつかのプラグインが削除されました：
- KubeSchedulerConfiguration
v1beta2 は非推奨となりますので、 v1beta3 または v1に移行してください。
- スケジューラープラグインの
SelectorSpread が削除されましたので、代わりに PodTopologySpreadを使用してください。
以前の非推奨情報については、 What’s new in Kubernetes 1.23 記事をご覧ください。
#3022 PodTopologySpreadの最小ドメイン数
Stage: Betaへ移行
Feature group: scheduling
Feature gate: MinDomainsInPodTopologySpread Default value: true
新しい minDomains サブリソースは、新しいPodをスケジューリングする時点では存在しないかもしれないけれども、利用可能としてカウントすべきドメインの最小数を確立します。したがって、必要なときにドメインはスケールアップされ、そのドメイン内の新しいノードがクラスターオートスケーラによって自動的に要求されます。
詳しくは、 What’s new in Kubernetes 1.24 の記事でご覧ください。
Kubernetes 1.25 ストレージ
#1710 マウントオプションによるSELinuxの再ラベリング
Stage: Alphaへ移行
Feature group: storage
Feature gate: SELinuxMountReadWriteOncePod Default value: false
この機能は、SELinuxを使用した PersistentVolumes のマウントを高速化するためのものです。マウント時に contextオプションを使用することで、Kubernetesはファイル上で再帰的にコンテキストを変更するのではなく、ボリューム全体にセキュリティコンテキストを適用します。この実装にはいくつかの注意点があり、最初のフェーズでは、 ReadWriteOncePodを持つPersistentVolumeClaims によってバックアップされたボリュームにのみ適用されます。
#3107 NodeExpansion シークレット
Stage: Alphaへ移行
Feature group: storage
Feature gate: CSINodeExpandSecret Default value: false
ストレージはステートフルなアプリケーションだけでなく、クラスターノードにも必要なものです。クレデンシャルを使用してボリュームを拡張することは、StorageClasses Secretsを使用してKubernetesの以前のバージョンですでに可能でした。しかし、ノードにストレージをマウントして、 NodeExpandVolume 操作を行う際にそれらのクレデンシャルを渡すメカニズムがありませんでした。
これらの新しい機能拡張は、StorageClass 定義の 2 つの新しいアノテーションを活用することで、CSI ドライバに secretRef フィールドを渡すことを可能にします。
apiVersion: storage.k8s.io/v1
v1beta2 は非推奨となりますので、 v1beta3 または v1に移行してください。SelectorSpread が削除されましたので、代わりに PodTopologySpreadを使用してください。apiVersion: storage.k8s.io/v1kind: StorageClass
metadata:
name: csi-storage-sc
parameters:
csi.storage.k8s.io/node-expand-secret-name: secret-name
csi.storage.k8s.io/node-expand-secret-namespace: mysecretsns
近日中にKubernetesのサイトでより詳細な情報を記載したブログ記事を掲載する予定ですので、ご期待ください。それまでは、KEPを参照して詳細を確認してください。
#3333 PersistentVolumeClaims (PVCs) のデフォルト StorageClass を調整する
Stage: Alpha への新規追加Feature group: storage
Feature gate:
RetroactiveDefaultStorageClass Default value: falseこの機能拡張は、PVCがStorageClassなしで作成された場合の動作を統合し、デフォルト・クラスを使用するPVCに明示的なアノテーションを追加するものです。これにより、クラスター管理者がデフォルトのストレージクラスを変更し、古いストレージクラスを削除してから新しいストレージクラスを設定するまでの間に、デフォルトのストレージクラスがない状態がしばらく続く場合、その管理に役立ちます。
この機能を有効にすると、新しいデフォルトが設定されたときに、 StorageClass を持たないすべての PVC は、デフォルトの StorageClass に遡及的に設定されます。
#361 ローカルエフェメラルストレージリソース管理
Stage: Stableへ移行Feature group: storage
Feature gate:
LocalStorageCapacityIsolation Default value: trueKubernetes 1.7のAlphaで初めて導入されて以来、長い間待ち望まれていたこの機能は、CPUとメモリに対して行われたのと同様の方法で
requests.ephemeral-storage とlimits.ephemeral-storage を設定することにより、Podが使用するエフェメラルストレージを制限できるようにするものです。Kubernetesは、設定したリミットやリクエストを超えたコンテナを持つPodをevictさせます。CPUとメモリについては、ノード上でPodをスケジューリングする前に、スケジューラーがPodのストレージ要件を利用可能なローカルストレージと照らし合わせてチェックします。さらに、管理者はResourceQuotasを設定してネームスペースの総リクエスト/リミットを制限したり、LimitRangesを設定してPodのデフォルトリミットを設定したりすることができます。
#625 CSIマイグレーション - コア
Stage: Stableへ移行Feature group: storage
Feature gate:
CSIInlineVolume Default value: true“Kubernetes 1.15 – What’s new?”の記事で取り上げたように、ストレージプラグインはもともとKubernetesコードベース内のインツリーであり、ベースコードの複雑さを増し、拡張性の妨げになっていました。
このコードをすべて、Container Storage Interfaceを通じてKubernetesと対話できるローダブルプラグインに移行する取り組みが進行中です。
PersistentVolume タイプのほとんどは非推奨となり、以下のものが残っています。- cephfs
- csi
- fc
- hostPath
- iscsi
- local
- nfs
- rbd
この作業はいくつかのタスクに分割されています: #178, #1487, #1488, #1490, #1491, #1491, #2589
#1488 CSI マイグレーション - GCE
Stage: Stableへ移行Feature group: storage
Feature gate:
CSIMigrationGCE Default value: trueGCE (Google Container Engine) の Persistent Disk サポートをアウトオブツリーの
pd.csi.storage.gke.io Container Storage Interface (CSI) Driver (これはクラスターにインストールする必要があります) に移動します。この機能拡張は、 #625 In-tree storage plugin to CSI Driver Migration の一部として行われます。
#596 CSI エフェメラルボリューム
Stage: Stableへ移行Feature group: storage
Feature gate:
CSIInlineVolume Default value: trueCSIボリュームは現在、PV/PVC経由でのみ参照できます。これは、リモートの永続的なボリュームのためにうまく機能します。この機能により、CSIボリュームをローカルのエフェメラルボリュームとして使用する可能性が出てきました。
詳細は、What’s new in Kubernetes 1.14 記事をご覧ください。
#1487 CSIマイグレーション - AWS
Stage: Stableへ移行Feature group: storage
Feature gate:
CSIMigrationAWS Default value: true“What’s new in Kubernetes 1.23”でも取り上げましたが、AWS EBS Container Storage Interface (CSI) ドライバに対するすべてのプラグイン操作は、アウトオブツリーの 'ebs.csi.aws.com' ドライバーにリダイレクトされるようになりました。
この機能強化は、 #625 In-tree storage plugin to CSI Driver Migration の取り組みの一部です。
#1491 CSI マイグレーション - vSphere
Stage: Betaへ移行Feature group: storage
Feature gate:
CSIMigrationvSphere Default value: false“What’s new in Kubernetes 1.19”の記事で取り上げたように、vSphere用のCSIドライバは以前からstableです。現在、
vspherevolume に対するすべてのプラグイン操作は、アウトオブツリーの 'csi.vsphere.vmware.com' ドライバーにリダイレクトされるようになりました。この機能強化は、 #625 In-tree storage plugin to CSI Driver Migration の取り組みの一部です。
#2589 CSI マイグレーション - Portworx
Stage: Betaへ移行Feature group: storage
Feature gate:
CSIMigrationPortworx Default value: false“What’s new in Kubernetes 1.23” の記事で取り上げたように、Portworx Container Storage Interface（CSI）ドライバのすべてのプラグイン操作は、アウトオブツリーの 'pxd.portworx.com' ドライバーにリダイレクトされるようになった。
この機能強化は、 #625 In-tree storage plugin to CSI Driver Migration の取り組みの一部です。
Kubernetes 1.25のその他の強化点
#2876 CRD validation expression language
Stage: Betaへ移行Feature group: api-machinery
Feature gate:
CustomResourceValidationExpressions Default value: trueこの機能拡張は、Webhooksに基づく既存のものを補完する形で、Custom Resource Definitions (CRD)の検証メカニズムを実装しています。
これらの検証ルールは Common Expression Language (CEL) を使用し、
x-kubernetes-validations extensionを使用して CustomResourceDefinition スキーマに含まれます。コンパイルと評価の時間を追跡するために、
cel_compilation_duration_seconds と cel_evaluation_duration_secondsという 2 つの新しいメトリクスが提供されます。詳細は What’s new in Kubernetes 1.23 記事でご確認ください。
#2885 サーバーサイドunknown field validation
Stage: Betaへ移行Feature group: api-machinery
Feature gate:
ServerSideFieldValidation Default value: true現在、
kubectl –validate=true を使用すると、リクエストがオブジェクト上の未知のフィールドを指定した場合に失敗することを示すことができます。この機能拡張は、 kube-apiserverにバリデーションを実装するための作業をまとめたものです。詳しくは Kubernetes 1.23 – What’s new? の記事をご覧ください。
#3203 公式CVEフィードの自動更新(レビュー)
Stage: Alphaへ移行Feature group: security
Feature gate: N/A
例えば、Kubernetesに関する関連情報を持つCVEsのリストが必要で、それをプログラム的に取得したいとしましょう。あるいは、安心感を保つために、K8sの公式チームが公開していることを知っていて、修正された脆弱性のリストを閲覧したいとします。
さらに一歩進んで、最近発表されたCVEや修正が必要なCVEなどをお客様にお知らせしたいKubernetesプロバイダーの方もいるかもしれません。
いずれにせよ、この機能拡張はクラスターで有効にするものではなく、Webリソースを介してコンシュームするものです。脆弱性の発表の中から
official-cve-feed というラベルを探せばいいだけです。この成果を説明したKEPはこちらです。すぐに読みに行く必要はありませんが、いつか役に立つ日が来るかもしれません。
#2802 API アドミッション レベルで Windows ポッドを正式に識別する
Stage: Stable へ移行Feature group: windows
Feature gate:
IdentifyPodOS Default value: trueこの機能拡張は、PodSpecに
OSフィールドを追加し、PodがどのOS上で実行されるべきかを定義できるようにします。そうすることで、KubernetesはPodを管理するためのより良いコンテキストを持つことができます。詳しくは Kubernetes 1.23 – What’s new? の記事をご覧ください。
以上、Kubernetes 1.25についてでした。これらの機能のいずれかを使用する予定がある場合は、クラスターのアップグレードの準備をしておいてください。
もしこの記事が気に入ったのであれば、以前の「Kubernetesの新機能」編もチェックしてみてください：
Kubernetesのコミュニティに参加してみませんか？
- プロジェクトのホームページをご覧ください。
- GitHubでKubernetesプロジェクトをチェックする。
- Kubernetesコミュニティに参加しましょう。
- Kubernetes Slackでメンテナに会いましょう。
- Twitterで@KubernetesIOをフォローする。
また、Kubernetesエコシステムの最新情報を楽しみたい方は、クラウドネイティブエコシステムで起こっている最もクールなトピックを毎月お届けするコンテナニュースレターを購読してください。