Kubernetes 1.31 – 新機能は？

By 清水 孝郎 - JULY 28, 2024
Topics: オープンソース

SHARE:

本文の内容は、2024年7月26日に Nigel Douglas が投稿したブログ(https://sysdig.com/blog/whats-new-kubernetes-1-31/)を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.31が間もなく登場します。このリリースでは、プロジェクトに大きな変更が加えられます。では、このリリースの新機能は何でしょうか?

Kubernetes 1.31には、このリリースで「 Graduating 」として追跡されている 37 項目を含む、多数の機能強化が含まれています。これらのうち、待望の Kubernetes 向け AppArmor サポートを含む11 の機能強化がステーブルに移行します。これには、API でコンテナまたはポッドの AppArmor プロファイルを指定し、そのプロファイルをコンテナランタイムによって適用する機能が含まれます。 

34 の新しいアルファ機能もデビューし、ポッドレベルのリソースリミットをサポートする初期設計に注目が集まっています。セキュリティ チームは、この機能の進捗状況を追跡することに特に興味を持つでしょう。

KubeProxy Ingressの接続信頼性の向上(終了ノードでの接続ドレイン機能の向上) や、それをサポートするロードバランサーなど、主要な変更点にご注目ください。

セキュリティをさらに強化するために、ポッドレベルのリソースリミットがNet New から Alpha に移行し、Kubernetes のリソース制約と同様の機能を提供して、運用効率と堅牢なセキュリティのバランスをうまく取っています。

また、ReplicaSet をダウンスケールする際のPod 選択のランダム化アルゴリズムなど、Kubernetes をよりユーザーフレンドリーかつ効率的にするというトレンドを継続する、生活の質を向上させる数多くの改善も行われています。

私たちはこのリリースに興奮しています。ここでは解明すべきことがたくさんあるので、Kubernetes 1.31 が提供するものを詳しく見ていきましょう。

編集者のおすすめ:

今回のリリースで私たちにとって最も興味深い変更点は次のとおりです。

#2395 ツリー内クラウドプロバイダーコードの削除

おそらく、v.1.31 で最もエキサイティングな進歩は、クラウドプロバイダーとのツリー内統合がすべて削除されたことです。v.1.26 以降、Kubernetes が真にベンダー中立のプラットフォームになるための大きな取り組みが行われてきました。この外部化プロセスにより、エンド ユーザーと開発者への影響を最小限に抑えながら、k8s.io/kubernetes リポジトリからクラウド プロバイダー固有のコードがすべて削除されます。

Nigel Douglas – Sr. Open Source Security Researcher

#2644 PersistentVolume 回収ポリシーを常に尊重する

この機能強化は、削除保護ファイナライザーを通じてユーザーが PersistentVolume 再要求ポリシーを尊重できるようになったため、非常に気に入っています。HonorPVReclaimPolicy はデフォルトで有効になりました。ファイナライザーを PersistentVolume に追加して、削除再要求ポリシーを持つ PersistentVolume が、バックアップ ストレージが削除された後にのみ削除されるようにすることができます。


新しく導入されたファイナライザー kubernetes.io/pv-co​​ntroller と external-provisioner.volume.kubernetes.io/finalizer は、環境内で動的にプロビジョニングされたボリュームにのみ追加されます。

Pietro Piutti – Sr. Technical Marketing Manager

#4292 kubectl デバッグのカスタムプロファイル


Kubectl Debug コマンドに新しいカスタムプロファイル オプションがようやく導入されたことを嬉しく思います。この機能は、シェルレスベースイメージでビルドされたアプリケーションをデバッグする際にチームが定期的に直面していた課題に対処します。デバッグコンテナ内でデータボリュームやその他のリソースをマウントできるようにすることで、この機能強化により、ほとんどの組織に大きなセキュリティ上のメリットがもたらされ、デバッグ機能を犠牲にすることなく、より安全なシェルレスベースイメージの採用が促進されます。

Thomas Labarussias – Sr. Developer Advocate & CNCF Ambassador

Kubernetes 1.31 のApps

#3017 PodDisruptionBudget の PodHealthyPolicy

Stage: Graduating to Stable
Feature group: sig-apps

Kubernetes 1.31 では、PodDisruptionBudget (PDB) 用の PodHealthyPolicy が導入されています。現在、PDB には 2 つの目的があります。中断中に利用可能なポッドの最小数を確保することと、データが複製されるまでポッドの削除をブロックしてデータ損失を防ぐことです。

現在の実装には問題があります。実行中だが正常 (準備完了) ではないポッドは、その数が PDB しきい値を超えても削除されない可能性があり、cluster-autoscaler などのツールの動作を妨げます。さらに、データ損失を防ぐために PDB を使用することは安全ではないと考えられており、本来の用途ではありません。

これらの問題にもかかわらず、多くのユーザーは両方の目的で PDB に依存しています。したがって、両方のユースケースをサポートせずに PDB の動作を変更することは現実的ではありません。特に、Kubernetes にはデータ損失を防ぐための代替ソリューションがないため、これは実現不可能です。

#3335 StatefulSet がレプリカの開始順序番号を制御できるようにする

Stage: Graduating to Stable
Feature group: sig-apps

この機能の目的は、アプリケーションを中断することなく、ネームスペース、クラスター、またはセグメント間で StatefulSet を移行できるようにすることです。バックアップや復元などの従来の方法ではダウンタイムが発生し、ポッドレベルの移行では手動での再スケジュールが必要です。StatefulSet をスライスで移行すると、レプリカのサブセットのみを一度に移動することで、段階的で中断の少ない移行プロセスが可能になります。

#3998ジョブの成功/完了ポリシー

Stage: Graduating to Beta
Feature group: sig-apps

ジョブ API が改善され、インデックス ジョブを成功と宣言できる条件を設定できるようになりました。これは、ジョブの成功にリーダーインデックスのみを考慮する必要がある MPI や PyTorch などのバッチ ワークロードに特に役立ちます。以前は、インデックスジョブは、すべてのインデックスが成功した場合にのみ完了としてマークされていました。Kubeflow Training Operator や Flux Operator などの一部のサードパーティフレームワークでは、同様の成功ポリシーが実装されています。この改善により、ユーザーは宣言されたポリシーに基づいてジョブを成功としてマークし、ジョブが成功基準を満たすと残っているポッドを終了できるようになります。

Kubernetes 1.31 の CLI

#4006 SPDY から WebSocket への移行

Stage: Graduating to Beta
Feature group: sig-cli

この機能強化では、kubectl CLI ツールに WebSocketExecutor を追加し、新しいサブプロトコル バージョン (v5.channel.k8s.io) を使用して、クライアント/サーバー バージョンの不一致を処理する FallbackExecutor を作成することを提案しています。 FallbackExecutor は、最初に WebSocketExecutor を使用して接続を試み、失敗した場合は従来の SPDYExecutor にフォールバックします。これにより、2 回の request/response のトリップが必要になる可能性があります。 追加のラウンドトリップがあるにもかかわらず、このアプローチは正当化されます。1 回のハンドシェイクのために低レベルの SPDY および WebSocket ライブラリを変更すると複雑になりすぎるため、ストリーミング操作のコンテキストでは追加の IO 負荷は最小限です。 さらに、リリースが進むにつれて、WebSocket 対応の kubectl が古い非 WebSocket API サーバーと対話する可能性は低くなります。

#4706 kubectl から kustomize を非推奨にして削除

Stage: Net New to Alpha
Feature group: sig-cli

このアップデートは、Kubernetes 1.31 リリースから延期されました。Kustomize は当初、Kubernetes オブジェクトの宣言型サポートを強化するために kubectl に統合されました。しかし、長年にわたるさまざまなカスタマイズおよびテンプレート ツールの開発により、kubectl のメンテナーは、あるツールを他のツールよりも推奨することは適切ではないと考えるようになりました。Kustomize を kubectl から分離することで、各プロジェクトが独自のペースで進化できるようになり、kubectl ユーザーが Kustomize の古いバージョンで作業することにつながるリリース サイクルの不一致の問題を回避できます。さらに、Kustomize を削除すると、依存関係グラフと kubectl バイナリのサイズが削減され、コア Kubernetes プロジェクトに影響を与えてきたいくつかの依存関係の問題に対処できます。

#3104 kubectlユーザープリファレンスをクラスタ構成から分離

Stage: Net New to Alpha
Feature group: sig-cli

Kubernetes プロジェクトの最も初期のコンポーネントの 1 つである Kubectl は、下位互換性への強いコミットメントを維持しています。ユーザーが新しい機能 (削除の確認など) を選択できるようにすることを目指していますが、そうしないと既存の CI ジョブやスクリプトが中断される可能性があります。kubeconfig には、あまり活用されていない設定フィールドがありますが、この目的には適していません。新しいクラスターは通常、認証情報とホストの詳細を含む新しい kubeconfig ファイルを生成します。これらのファイルはマージすることも、パスで指定することもできますが、サーバー構成とユーザー設定は明確に分離する必要があると考えています。

これらのニーズに対応するために、Kubernetes のメンテナーはクライアント設定用の kuberc ファイルの導入を提案しました。このファイルはバージョン管理され、ユーザーが新しい動作や設定を簡単に取り入れられるように構造化されます。また、ユーザーは kubectl コマンドのエイリアスとデフォルトフラグを定義できるようになります。この変更に伴い、kubeconfig 設定フィールドを廃止する予定です。この分離により、ユーザーは –kubeconfig フラグや $KUBECONFIG 環境変数に関係なく、一貫して設定を管理できるようになります。

Kubernetes 1.31 インストルメンテーション

#2305 メトリクスカーディナリティのエンフォースメント

Stage: Graduating to Stable
Feature group: sig-instrumentation

メトリクスがメモリリークになると、特に修正のために Kubernetes バイナリ全体を再リリースする必要がある場合、重大な問題が発生します。これまで、私たちはこれらの問題に一貫性なく取り組んできました。たとえば、コーディングの間違いにより、意図しない ID がメトリクス ラベル値として使用されることがあります。 

他にも、メトリクスが誤って使用されたためにメトリクスを完全に削除しなければならなかったケースがあります。最近では、メトリクスラベルを削除するか、メトリクスの許容値を遡及的に定義しました。これらの問題を修正するには、標準化されたソリューションがなければ、手作業で手間と時間がかかるプロセスになります。

この安定したアップデートでは、Kubernetes コードのリリースとは関係なく、メトリクスディメンションを既知の値のセットにバインドできるようにすることで、これらの問題に対処します。

Kubernetes 1.31 のネットワーク

#3836 Kube-Proxy の Ingress 接続信頼性の向上

Stage: Graduating to Stable
Feature group: sig-network

この機能強化により、eTP:Cluster サービスに重点を置き、終了ノードおよび正常でない Kube プロキシを持つノード上のエンドポイントの入力接続を処理するための、より信頼性の高いメカニズムが最終的に導入されます。現在、Kube プロキシの応答は、eTP:Cluster サービスの healthz 状態と、eTP:Local サービスの準備完了エンドポイントの存在に基づいています。この KEP は前者に対応します。

提案された変更は次のとおりです。

  1. 終了するノードの接続ドレイン:
    Kube-proxy は ToBeDeletedByClusterAutoscaler taint を使用して終了するノードを識別し、healthz チェックに失敗してロード バランサーに接続ドレインのシグナルを送ります。.spec.unschedulable などの他のシグナルも検討されましたが、直接的ではないと判断されました。
  2. /livez パスの追加:
    Kube-proxy は、古い healthz セマンティクスを反映するために、ヘルスチェック サーバーに /livez エンドポイントを追加し、データ プレーン プログラミングが古くなっているかどうかを示します。
  3. クラウドプロバイダーのヘルスチェック:
    クラウドプロバイダーのヘルス チェックを eTP:Cluster サービスに合わせて調整するわけではありませんが、KEP では、Kubernetes の公式サイトにドキュメントを作成し、クラウド プロバイダーにガイドして知識を共有し、ヘルス チェックの実践を改善することを提案しています。

#4444サービスへのトラフィック分散

Stage: Graduating to Beta
Feature group: sig-network

Kubernetes でのトラフィックルーティングを強化するために、この KEP では、サービス仕様に新しいフィールド、trafficDistribution を追加することを提案しています。このフィールドを使用すると、ユーザーはルーティング設定を指定でき、以前の topologyKeys メカニズムよりも制御性と柔軟性が向上します。trafficDistribution は、厳密な保証は提供せずに、ルーティングの決定で考慮する基礎となる実装のヒントを提供します。

新しいフィールドは、トポロジー的に近いエンドポイントにトラフィックをルーティングする優先順位を示す PreferClose などの値をサポートします。値がない場合、特定のルーティング優先順位がなく、実装に決定が委ねられることを示します。この変更の目的は、革新的なルーティング戦略のために、強化されたユーザー制御、標準ルーティング優先順位、柔軟性、拡張性を提供することです。

#1880複数のサービス CIDR

Stage: Graduating to Beta
Feature group: sig-network

この提案では、ServiceCIDR と IPAddress という 2 つの新しい API オブジェクトを使用する新しいアロケーターロジックが導入され、ユーザーは新しい ServiceCIDR を作成することで、利用可能なサービス IP を動的に増やすことができます。アロケーターは、ストレージシステムにディスクを追加して容量を増やすのと同様に、利用可能な ServiceCIDR から IP を自動的に消費します。

シンプルさと下位互換性を維持し、Gateway API などの他の API との競合を回避するために、いくつかの制約が追加されています。

  • ServiceCIDR は作成後は変更できません。
  • ServiceCIDR は、サービス IP が関連付けられていない場合にのみ削除できます。
  • 重複する ServiceCIDR は許可されます。
  • API サーバーは、サービス CIDR フラグと「kubernetes.default」サービスをカバーするためにデフォルトの ServiceCIDR が存在することを確認します。
  • すべての IP アドレスは定義された ServiceCIDR に属している必要があります。
  • ClusterIP を持つすべてのサービスには、関連付けられた IPAddress オブジェクトが必要です。
  • 削除される ServiceCIDR では新しい IP を割り当てることができません。

これにより、サービスと IP アドレスの間に 1 対 1 の関係が、ServiceCIDR と IP アドレスの間に 1 対多の関係が作成されます。重複する ServiceCIDR はメモリ内でマージされ、IP アドレスはその IP を含む任意の ServiceCIDR から取得されます。新しいアロケータ ロジックは、Gateway API などの他の API でも使用できるため、将来的にサービス範囲に対する管理操作やクラスター全体の操作が可能になります。

Kubernetes 1.31 ノード

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

Stage: Graduating to Stable
Feature group: sig-node

この機能強化により、Kubernetes にスワップメモリサポートが統合され、パフォーマンスチューニングを行うノード管理者と、アプリにスワップを必要とするアプリ開発者という 2 つの主要なユーザー グループに対応できるようになります。 

焦点は、ノードレベルでのスワップの使用を制御しやすくすることで、kubelet によって Kubernetes ワークロードが特定の構成でスワップ領域を利用できるようにすることでした。最終的な目標は、スワップを使用して Linux ノードの操作を強化し、管理者がワークロードのスワップ使用量を決定できるようにすることです。当初は、個々のワークロードが独自のスワップ制限を設定することは許可されていませんでした。

#4569 cgroup v1 サポートをメンテナンス モードに移行

Stage: Net New to Stable
Feature group: sig-node

この提案は、Kubernetes の cgroup v1 サポートをメンテナンスモードに移行し、ユーザーに cgroup v2 の採用を促すことを目的としています。cgroup v1 サポートはすぐに削除されることはありませんが、その廃止と最終的な削除は将来の KEP で対処される予定です。Linux カーネル コミュニティと主要なディストリビューションは、強化された機能、一貫したインターフェース、改善されたスケーラビリティのため、cgroup v2 に注目しています。したがって、Kubernetes は互換性を維持し、cgroup v2 の進歩の恩恵を受けるために、この移行に合わせる必要があります。

この移行をサポートするために、提案にはいくつかの目標が含まれています。まず、cgroup v1 には新しい機能は追加されず、その機能は完全かつ安定しているとマークされます。既存の機能の継続的な検証を確実にするために、エンドツーエンドのテストが維持されます。Kubernetes コミュニティは、リリースがサポートされている限り、cgroup v1 に関連する重要な CVE のセキュリティ修正を提供する場合があります。主要なバグは評価され、可能であれば修正されますが、依存関係の制約により、一部の問題は未解決のままになる可能性があります。

移行サポートは、ユーザーが cgroup v1 から v2 に移行できるように提供されます。さらに、既知のバグをすべて修正して cgroup v2 サポートを強化し、ユーザーが切り替えるのに十分な信頼性と機能性を確保する取り組みも行われます。この提案は、より広範なエコシステムの cgroup v2 への移行を反映しており、Kubernetes がそれに応じて適応する必要性を強調しています。

#24 AppArmor サポート

Stage: Graduating to Stable
Feature group: sig-node

Kubernetes に AppArmor サポートを追加することで、コンテナ化されたワークロードのセキュリティポスチャーが大幅に強化されます。AppArmor は、システム管理者が特定のアプリケーションまたはコンテナに添付されたプロファイルを使用してプログラムの特定の機能を制限できるようにする Linux カーネル モジュールです。AppArmor を Kubernetes に統合することで、開発者はアプリ構成内で直接セキュリティ ポリシーを定義できるようになりました。

この機能の初期実装では、Kubernetes API 内で個々のコンテナまたはポッド全体の AppArmor プロファイルを指定できるようになります。このプロファイルは、定義されるとコンテナ ランタイムによって強制され、プロファイルで定義されたルールに従ってコンテナのアクションが制限されるようになります。この機能は、侵害されたコンテナが他のワークロードや基盤となるホストに影響を及ぼす可能性があるマルチテナント環境で、安全で制限されたアプリケーションを実行するために不可欠です。

Kubernetes でのスケジューリング

#3633 PodAffinity と PodAntiAffinity に MatchLabelKeys と MismatchLabelKeys を導入

Stage: Graduating to Beta
Feature group: sig-scheduling

これは7月23日付けでコードフリーズとして追跡されました。この強化機能により、PodAffinityTermのMatchLabelKeysが導入され、PodAffinityおよびPodAntiAffinityを改善し、ローリングアップグレードなどのシナリオにおいてPodの配置をより正確に制御できるようになります。

ユーザーがPodの共存を評価するスコープを指定できるようにすることで、新旧のPodバージョンが同時に存在する際に生じるスケジューリングの課題、特に飽和状態やアイドル状態のクラスターでの課題に対処します。この機能強化は、スケジューリングの効果とクラスターリソースの利用効率を向上させることを目指しています。

Kubernetes ストレージ

#3762 PersistentVolume の最終フェーズ遷移時間

Stage: Graduating to Stable
Feature group: sig-storage

Kubernetes のメンテナーは、API サーバーを更新して、PersistentVolumes の新しいタイムスタンプ フィールドをサポートする予定です。このフィールドは、ボリュームが別のフェーズに移行するタイミングを記録します。このフィールドは、新しく作成されたすべてのボリュームとフェーズを変更するボリュームの現在の時刻に設定されます。このタイムスタンプは、クラスター管理者の利便性のみを目的としていますが、これにより、移行時間に基づいて PersistentVolumes を一覧表示および並べ替えることができるため、手動でのクリーンアップと管理が容易になります。

この変更は、削除保持ポリシーを使用しているユーザーが経験した問題に対処します。この問題により、データ損失が発生し、多くのユーザーがより安全な保持ポリシーに戻すようになりました。保持ポリシーでは、要求されていないボリュームはリリース済みとしてマークされ、時間の経過とともにこれらのボリュームが蓄積されます。タイムスタンプ フィールドにより、管理者はボリュームが最後にリリース フェーズに移行した時期を特定できるため、クリーンアップが容易になります。 

さらに、すべてのフェーズ遷移のタイムスタンプの一般的な記録により、保留フェーズとバインド フェーズ間の時間を測定するなど、貴重なメトリクスと洞察が得られます。目標は、このタイムスタンプ フィールドを導入し、ボリュームのヘルス監視やタイムスタンプに基づく追加のアクションを実装せずに、フェーズ遷移ごとに更新することです。

#3751 Kubernetes VolumeAttributesClass ボリュームの変更

Stage: Graduating to Beta
Feature group: sig-storage

この提案では、新しいKubernetes APIリソースであるVolumeAttributesClassの導入を提案しており、アドミッションコントローラーとボリューム属性保護コントローラーも導入します。このリソースにより、ユーザーはIOPSやスループットなどのボリューム属性を容量から独立して管理できるようになります。現在のStorageClass.parametersの不変性がこの新しいリソースを必要とする理由であり、クラウドプロバイダーAPIを直接使用せずにボリューム属性の更新を可能にすることで、ストレージリソース管理を簡素化します。

VolumeAttributesClassは、ボリュームの作成時および既存のボリュームに対してボリューム属性を指定および変更することを可能にし、変更がワークロードに影響を与えないようにします。StorageClass.parametersとVolumeAttributesClass.parametersの間に矛盾が生じた場合、ドライバーからエラーが返されます。

主な目標は、クラウドプロバイダーに依存しないボリューム属性の仕様を提供し、これらの属性をストレージ全体で強制し、ワークロード開発者がそれらを変更してもワークロードに影響を与えないようにすることです。この提案は、OSレベルのIO属性、ポッド間のボリューム属性、またはノード固有のボリューム属性の制限に基づくスケジューリングについては扱っていませんが、将来的な拡張として検討される可能性があります。

#3314ブロックボリュームの CSI 差分スナップショット

Stage: Net New to Alpha
Feature group: sig-storage

この機能強化はKubernetes 1.31のマイルストーンから削除されましたが、CSI仕様を強化することを目的としています。新しいオプションのCSI SnapshotMetadata gRPCサービスを導入することで、Kubernetesが単一スナップショットの割り当てられたブロックのメタデータや、同じブロックボリュームのスナップショット間で変更されたブロックのメタデータを取得できるようにします。このサービスはコミュニティ提供のexternal-snapshot-metadataサイドカーによって実装され、CSIドライバーによって展開される必要があります。Kubernetesのバックアップアプリケーションは、Kubernetes APIサーバーへの負荷を最小限に抑える安全なTLS gRPC接続を通じてスナップショットメタデータにアクセスできます。

external-snapshot-metadataサイドカーは、プライベートなUNIXドメインソケットを介してCSIドライバーのSnapshotMetadataサービスと通信します。サイドカーは、Kubernetes認証トークンの検証、バックアップアプリケーションの認証、RPCパラメータの検証、および必要なプロビジョナーシークレットの取得などのタスクを処理します。CSIドライバーは、SnapshotMetadataサービスの存在を、サービスのTCPエンドポイント、CA証明書、およびトークン認証のためのオーディエンス文字列を含むSnapshotMetadataService CRを介してバックアップアプリケーションに通知します。

バックアップアプリケーションは、サービスのオーディエンス文字列を使用してKubernetes TokenRequest APIを使用して認証トークンを取得し、SnapshotMetadataサービスにアクセスする前に指定されたCAと信頼を確立する必要があります。これにより、指定されたTCPエンドポイントへのgRPC呼び出しにトークンを使用します。この設定により、Kubernetes APIサーバーに過負荷をかけずに、安全かつ効率的なメタデータの取得が可能になります。

この機能強化の目標は、ボリュームスナップショットの割り当て済みおよび変更されたブロックを特定するための安全なCSI APIを提供し、ストレージプロバイダーから大量のスナップショットメタデータを効率的に伝達することです。このAPIは、CSIフレームワークのオプションコンポーネントです。

Kubernetes 1.31 その他の機能強化

#4193バインドされたサービスアカウントトークンの改善

Stage: Graduating to Beta
Feature group: sig-auth

この提案は、バインドされたノード情報をトークンに埋め込み、トークンの機能を拡張することで、Kubernetes のセキュリティを強化することを目的としています。kube-apiserver は、TokenRequest 中に生成されたトークンに、Pod に関連付けられたノードの名前と UID を自動的に含めるように更新されます。これには、Pod および Secret オブジェクトの既存のプロセスと同様に、ノードの UID を取得するための Node オブジェクトの Getter を追加する必要があります。

さらに、TokenRequest API が拡張され、トークンをノードオブジェクトに直接バインドできるようになり、ノードが削除されると、関連付けられたトークンが無効になります。SA 認証子は、ノードの存在を確認し、トークン内の UID を検証することで、ノードオブジェクトにバインドされたトークンを検証するように変更されます。これにより、Pod にバインドされたトークンの現在の動作が維持され、ノードにバインドされたトークンの新しい検証チェックが最初から強制されます。

さらに、発行された各 JWT には、そのトークンを使用して API サーバーに行われたリクエストを追跡するための UUID (JTI) が含まれ、監査ログに記録されます。これには、トークンの発行中に UUID を生成し、この識別子をキャプチャするために監査ログ エントリを拡張することが含まれており、追跡可能性とセキュリティ監査が強化されます。

#3962ミューテーティングアドミッションポリシー

Stage: Net New to Alpha
Feature group: sig-api-machinery

KEP-3488で始まった作業を引き継ぎ、プロジェクトのメンテナはCEL式を使用してミューテーティングアドミッションポリシーを追加することを提案しています。これはミューテーティングアドミッションウェブフックの代替手段として提案されています。このアプローチは、KEP-3488で確立されたアドミッションポリシーの検証APIを基にしており、CELのオブジェクトインスタンシエーションとサーバーサイド適用のマージアルゴリズムを利用してミューテーションを実行します。

この機能強化の動機は、ラベルの設定やサイドカーコンテナの追加などの一般的なミューテーション操作を簡単に表現できるCELの簡潔さにあります。これにより、ウェブフックの管理の複雑さと運用上の負担が軽減されます。さらに、CELベースのミューテーションは、kube-apiserverがミューテーションを内省し、ポリシー適用の順序を最適化して再呼び出しの必要性を最小限に抑えるなどの利点を提供します。インプロセスミューテーションはウェブフックよりも高速であり、すべての操作が適用された後に一貫性を確保するためにミューテーションを再実行することも可能です。

この機能強化の目標は、ほとんどの使用ケースに対してミューテーティングウェブフックの有力な代替手段を提供すること、ウェブフックを必要としないポリシーフレームワークを可能にすること、古いKubernetesバージョンとの互換性を持つアウトオブツリー実装を提供すること、およびGitOps、CI/CDパイプライン、監査シナリオで使用するためのライブラリとしてのコア機能を提供することです。

#3715Elastic Indexed ジョブ

Stage: Graduating to Stable
Feature group: sig-apps

この機能はStableに昇格され、Indexed Jobsのspec.parallelismに合わせてspec.completionsを変更できるようになります。spec.completionsが変更されないジョブの場合、成功と失敗のセマンティクスは変更されませんが、spec.completionsが変更されたジョブでは、失敗は常にジョブのbackoffLimitにカウントされます。たとえspec.completionsが縮小され、失敗したポッドが新しい範囲外になったとしても同様です。status.Failedのカウントは減少しませんが、status.Succeededは新しい範囲内で成功したインデックスを反映するように更新されます。以前に成功したインデックスがスケールダウンによって範囲外になり、その後スケールアップによって再び範囲内に戻った場合、そのインデックスは再起動されます。

このブログを気に入った方は、ぜひ過去の『Kubernetesの新機能』エディションもチェックしてみてください。

Kubernetes プロジェクトに参加しましょう: