Kubernetes 1.32 の新機能は？

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

SHARE:

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

Kubernetes 1.32がもうすぐリリースされます。ホリデー シーズンに向けて、かなり多くの変更が準備されています。では、1.32 の新機能は何でしょうか?

Kubernetes 1.32には、この Kubernetes リリースで  ‘Graduating’  として追跡されている 39 の変更点を含む、多数の便利な機能強化が含まれています。これらのうち、 StatefulSet によって作成された PVC を自動削​​除する機能を含む20 の機能強化がステーブルに移行しています。この機能は、ボリュームが使用されなくなったときに StatefulSet によって作成された PVC を自動的に削除する新機能を提供し、無期限に存続しない StatefulSet の管理を容易にします。

37の新しいアルファ機能も今回初登場となり、その中でも特に注目されているのが、CrashLookBackOff の微調整が可能になることです。この機能により、プラットフォームエンジニアは、実際に発生する負荷に合わせてポッドの再起動バックオフロジックを改善できるようになります。これにより、バックオフ設定の減少が原因となるノードの安定性へのリスクを定量化するといった、新たなユースケースに対応することが可能になるでしょう。

今回のリリースとそのすべての機能に、私たちは大いに期待しています！Kubernetes 1.32がもたらす魅力的な新機能を詳しく見ていきましょう。

Kubernetes 1.32 – 編集者のおすすめ:

今回のリリースで私たちにとって最も興味深い変更点をいくつかご紹介します。

#4802 Windows ノード gracefully シャットダウン

Kubernetes v1.32で個人的に期待している大きな改善の一つは、Windowsノードのシャットダウン時におけるポッドの終了プロセスの改良です。これにより、長らく存在していたポッドライフサイクルの欠陥が解消されます。これまで、ノードがシャットダウンすると、ポッドが重要なライフサイクルイベント（例えば、pre-stop hooks）をスキップして突然終了することが多くありました。その結果、リソースのクリーンアップや状態の保存に依存しているワークロードに問題が発生することがありました。

今回のアップデートにより、Windowsノード上のkubeletが基盤となるノードのシャットダウンイベントを認識し、ポッドに対して適切なシャットダウンシーケンスを開始するようになります。これにより、ポッドが設計者の意図した通りに終了されることが保証されます。この変更は、信頼性やワークロードの一貫性を向上させるだけでなく、クラウドプロバイダーに依存しない形で実現されています。

Nigel Douglas – OSS Security Researcher

#2644 常に PersistentVolume の Reclaim Policy を尊重する

Kubernetes v1.32で個人的にお気に入りの改善点は、ストレージ管理における重要なギャップを解消した点です。この改善により、Persistent Volume (PV) に関連付けられたリクレイムポリシーが一貫して適用されることが保証されます。以前は、Persistent Volume Claim (PVC) より先に PV が削除された場合にリクレイムポリシーが無視され、外部インフラストラクチャに不要なストレージリソースが残る問題がありました。この挙動により非効率が生じ、未使用のストレージを手動でクリーンアップする必要がありました。

今回の改善では、kubernetes.io/pv-controller や external-provisioner.volume.kubernetes.io/finalizer のようなファイナライザーを PV に導入することで、PV のライフサイクル管理がより信頼性の高いものになりました。CSI ドライバーやインツリープラグインを使用する場合でも、リクレイムのワークフローが削除タイミングの問題に対して強化され、リソースリークを防ぎ、ユーザーの期待に沿った動作を実現します。この改善により、ストレージ管理が簡素化されるだけでなく、Kubernetes がステートフルなワークロードを処理する際の信頼性が向上し、管理者と開発者の双方にメリットをもたらします。

さらに、この変更はフィーチャーゲートの背後に導入されており、移行を円滑に進めることができます。これにより、リスクを最小限に抑えつつ、従来の不整合な挙動を段階的に廃止することが可能です。

Alex Boylan – Senior Escalation Management

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

ソフトウェアエンジニアとして、カスタムプロファイリングサポートを備えた kubectl debug コマンドの改善により、デバッグのワークフローが大幅に効率化されました。この機能により、事前定義されたプロファイルに頼ったり、ポッド仕様を手動で修正したりする必要がなくなり、環境変数、ボリュームマウント、セキュリティコンテキストなど、自分のデバッグ要件に合わせた設定をカスタムJSONプロファイルとして定義し、再利用できるようになりました。この柔軟性により、時間を節約し、繰り返し作業を減らし、追加のコマンドフラグによる混乱を排除できます。

最終的に、この機能はKubernetesアプリケーションのトラブルシューティングをより効率的にし、自分のワークロードの特有の要件に沿ったデバッグプロセスを実現します。

Shane Dempsey – Staff Software Engineer

Kubernetes 1.32 Apps

#1847 StatefulSet によって作成された PVC を自動削​​除する

Stage: Graduating to Stable
Feature group: sig-apps

Kubernetes 1.32のリリースでは、StatefulSetによって作成されたPVC（Persistent Volume Claim）を自動的に削除するオプトイン機能が導入され、リソース管理が大幅に改善されました。これまで、StatefulSetに関連付けられたPVCは、StatefulSet自体が削除されても残り続けるため、手動でクリーンアップする必要があり、リソースの無駄が発生する可能性がありました。この改善により、ボリュームが使用されなくなった際にPVCを自動的にクリーンアップできるようになり、永続データを必要としないStatefulSetのワークフローが簡素化されます。

さらに、この機能はローリングアップデートやノードドレインといった通常のメンテナンス作業中にアプリケーションの状態が維持されるように設計されており、StatefulSetユーザーにとって便利で信頼性の高い機能となっています。

#4026ジョブアノテーションにジョブ作成タイムスタンプを追加

Stage: Graduating to Stable
Feature group: sig-apps

Kubernetes CronJob エクスペリエンスは、ジョブの元のスケジュールされたタイムスタンプを保存するアノテーションの導入によって大幅に改善されました。タイムスタンプをジョブのメタデータとして設定することで、ユーザーとツールは、ジョブが最初に実行される予定だった時間に簡単にアクセスして追跡できます。これにより、特に遅延や再スケジュールを伴うシナリオで、CronJob ワークロードの透明性とデバッグ機能が向上します。重要なのは、この追加によって既存のワークロードが中断されないため、Kubernetes コミュニティ全体の開発者とオペレーターの両方にメリットをもたらすシームレスな改善となることです。

#4368Job APIの「managed-by」メカニズム

Stage: Graduating to Beta
Feature group: sig-app

Job仕様に新たに追加されたmanagedByフィールドは、特にMultiKueueのようなマルチクラスターのジョブオーケストレーションに向けた取り組みにおいて、Kubernetesにとって非常に優れた改善点です。この機能により、Kueueコントローラーのような外部コントローラーにジョブの同期処理を委任できるようになり、複数のクラスターにまたがるジョブの管理がシームレスに行えるようになります。

責任を負うコントローラーを明確に指定することで、この改善はワークフローを簡素化し、競合する更新を回避し、より信頼性の高いステータス同期を実現します。

この機能が、分散環境におけるバッチワークロードのスケーラビリティと柔軟性を高めながら、堅牢なマルチクラスタージョブ管理の能力を提供し、Kubernetesコミュニティに大きなメリットをもたらすと確信しています。

Kubernetes 1.32 CLI

#3104 kubectl ユーザー設定をクラスター構成から分離する

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

Kubernetes CLI にkubercファイル (~/.kube/kuberc)が組み込まれると、クラスターの認証情報とサーバー構成がユーザー固有の設定から明確に分離され、使いやすさが向上します。この機能強化により、ユーザーはクラスター固有の kubeconfig ファイルとは独立して、コマンドエイリアス、デフォルトフラグ、新しい動作設定などの個人設定を管理できます。アクティブな構成に関係なく単一の設定セットを適用することで、特に複数の kubeconfig ファイルを管理するユーザーのワークフローが簡素化されます。 

このアプローチにより、下位互換性を維持し、kubeconfig 構造の複雑さを軽減しながら、新しいユーザー中心の機能の実装が容易になり、CLI の将来性が確保されます。

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

#4827すべてのKubernetesコアコンポーネント向けのStatusZページ

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

Kubernetesにおけるstatusz機能を通じたz-pagesの導入は、分散システムのリアルタイムの可観測性とデバッグにおいて大きな利点をもたらします。z-pagesは、サーバー内に直接統合されたインターフェースを提供し、ビルドバージョン、Goバージョン、互換性の詳細といった重要な情報を正確でアクセスしやすい形式で統合します。これにより、外部ツールやログ、複雑なセットアップが不要になり、トラブルシューティングの時間を短縮し、潜在的な遅延の問題を最小化します。

さらに、statuszは重要なコンポーネントデータの一貫した提示を保証し、Kubernetesエコシステム全体でモニタリングやデバッグを効率化する標準を確立します。この改善により、開発者や運用担当者は即時の洞察を得られるようになり、複雑なシステムの管理において効率性と信頼性が向上します。

#4828すべてのコア Kubernetes コンポーネント向けの Flagz ページ

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

StatusZページと同様に、flagzエンドポイントの改善は、Kubernetesのコアコンポーネント全体の内省およびデバッグ機能を向上させることを目的としています。この機能は、アクティブなコマンドラインフラグをリアルタイムで可視化することで、ユーザーが設定の問題を診断し、フラグの変更を検証できるようにし、システムの安定性を確保しつつ、予期しない動作に対するトラブルシューティングの時間を短縮します。

メトリクス、ログ、トレースがパフォーマンスや運用状況の洞察を提供するのに対し、flagzはコンポーネントのランタイム設定に特化しており、独自かつ補完的な視点を提供します。特に、この改善は既存のモニタリングツールを置き換えることを目的としておらず、ネットワーク制限のためにアクセスできないコンポーネントへの可視性を提供するものでもありません。その代わり、Kubernetesコアコンポーネントの動的フラグ検査に焦点を当てています。

Kubernetes 1.32 ネットワーク

#2681 ポッドにフィールドstatus.hostIPsが追加

Stage: Graduating to Stable
Feature group: sig-network

この機能強化により、特に IPv4 アドレスと IPv6 アドレスの両方が使用されるデュアルスタック環境で、ポッドがノードのアドレスを取得しやすくなるため、Kubernetes ネットワークが改善されます。ポッド ステータスに status.hostIPs フィールドを導入し、これに対する Downward API サポートを有効にすることで、アプリケーションは外部の回避策なしで、ホスティングノードの IPv4 アドレスと IPv6 アドレスの両方に動的にアクセスできるようになります。 

これは、互換性を簡素化し、デュアルスタック移行フェーズ中のシームレスな通信を保証するため、IPv4 から IPv6 に移行するアプリケーションにとって特に有益です。これにより、開発者は、高度にスケーラブルなクラウドネイティブ展開で非常に重要な、より堅牢で柔軟なネットワーク機能を使用できるようになります。

#1860 KubernetesにLoadBalancerの動作を認識させる

Stage: Graduating to Stable
Feature group: sig-network

Kube-proxy は、 Serviceの loadBalancer ステータスに構成可能な ipMode フィールドを取得し、クラウドプロバイダーが kube-proxy の動作をロードバランサーの実装に合わせることができるようになります。現在、kube-proxy はデフォルトで外部 IP をノードにバインドするため、ヘルス チェックの失敗や、TLS 終了やPROXYプロトコルなどのロード バランサー機能のバイパスなどの問題が発生する可能性があります。新しい ipMode 設定により、プロバイダーはプロキシモードを選択して直接 IP バインディングをバイパスし、これらの問題を解決しながら、既存の VIP モードをデフォルトとして保持できます。

この場合の目標は、クラウドプロバイダーが Cloud Controller Manager を介して kube-proxy の LoadBalancer 外部 IP の処理を​​構成できるようにし、既存の回避策に代わるクリーンで構成可能なソリューションを提供することです。kube-proxy の既存のデフォルトの動作を変更したり、非推奨にしたりすることは意図していませんでした。

#4427 DNS検索文字列の検証を緩和

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

この提案は、Kubernetes の dnsConfig.searches フィールドの DNS 検索文字列の検証を緩和して、従来の命名規則や特殊なユースケースを持つワークロードをサポートすることを目的としています。現在、Kubernetes はRFC-1123に基づいて厳格な検証を実施しており、アンダースコア (_) とシングルドット (.) の検索文字列を許可していません。この制限により、SRV レコード (_sip._tcp.abc_d.example.com) などの短い DNS 名を解決する必要があるワークロードや、不要な内部 DNS ルックアップを回避するワークロードで問題が発生します。RelaxedDNSSearchValidation 機能ゲートを導入することで、この提案ではアンダースコアとシングルドットの検索文字列を許可し、従来のシステムとの互換性を高め、DNS 構成の柔軟性を高めます。

その目的は、アンダースコアを含む DNS 名を解決するワークロードをサポートし、単一ドットの検索文字列を使用して外部 DNS ルックアップを優先し、機能が切り替えられたときにスムーズなアップグレードとダウングレードを保証することでした。スプリントのどの時点でも、検索フィールド以外の DNS 名検証の他の側面を変更するという目標はなく、Kubernetes 自体によって管理される名前内でアンダースコアを許可することに重点が置かれていませんでした。

Kubernetes 1.32 ノード

#1967メモリバックアップボリュームサイズ指定のサポート

Stage: Graduating to Stable
Feature group: sig-node

このステーブル版のアップデートでは、Kubernetesにおけるメモリバックアップ型のemptyDirボリュームのサイズを、ポッドの割り当て可能なメモリまたはオプションで指定されたユーザー定義の制限と整合させることで、移植性と使いやすさを向上させています。現在、この種のボリュームはノードの総メモリの50%をデフォルトとしていますが、これにより、異なるノード構成間でポッドの定義の移植性が低下していました。この問題に対処するため、新しいSizeMemoryBackedVolumesフィーチャーゲートを導入し、メモリバックアップ型ボリュームのサイズがポッドレベルのメモリ制限と一貫性を持つようにしました。これにより、メモリバックアップ型ストレージに依存するAI/MLのようなワークロードに対して予測可能性が向上します。

さらに、ユーザーが明示的により小さいボリュームサイズを定義できるようになり、リソース制御の向上を実現しつつ、既存のメモリ計算メカニズムとの互換性も維持します。この変更により、メモリバックアップ型ストレージを活用するワークロードにおいて、信頼性、移植性、および柔軟性が向上します。

#3983ドロップイン形式のkubelet設定ディレクトリのサポートを追加

Stage: Graduating to Beta
Feature group: sig-node

この提案は、KubernetesのKubelet設定管理を改善するため、新しい–config-dirフラグで指定できるドロップイン形式の設定ディレクトリを導入します。ベータフェーズでは、このフラグのデフォルト値が/etc/kubernetes/kubelet.conf.dに設定され、ユーザーは複数の設定ファイルを定義し、それらがアルファベット順に処理されるようになります。このアプローチは標準的なLinuxの慣行に沿っており、Kubeletの設定を複数のエンティティが管理する場合の競合を回避しつつ柔軟性を向上させます。

この機能は、初期段階では KUBELET_CONFIG_DROPIN_DIR_ALPHA 環境変数を通じてテストされていましたが、より効率的なプロセスを実現するために置き換えられました。この改善により、主要な設定ファイル（/etc/kubernetes/kubelet.conf）を上書きすることが可能になり、動的な更新の処理が簡素化されるとともに、競合条件（レースコンディション）などの問題を回避できます。

さらに、Kubeletの有効な設定を確認できるツールも提供され、透明性と保守性が向上します。この変更は、Kubernetes向けOWASP Top 10のベストプラクティスに準拠した設定管理をサポートするものであり、運用の効率化に貢献します。

#4680デバイスプラグインとDRAのポッドステータスにリソースヘルスステータスを追加

Stage: Graduating to Alpha
Feature group: sig-node

デバイスのヘルス情報を ポッドステータスで公開できるようになりました。具体的には、PodStatus.AllocatedResourcesStatus フィールド内です。これにより、障害が発生したデバイスや一時的に正常でないデバイスでの ポッドのトラブルシューティングが向上します。現在、デバイスに障害が発生すると、ワークロードは根本原因を明確に把握できないまま繰り返しクラッシュすることがよくあります。デバイス プラグインまたはデバイス リソース割り当てからのデバイスのヘルス詳細をAllocatedResourcesStatus に統合することで、ユーザーは正常でないデバイスに関連する問題を簡単に特定できます。この機能は、GPU などの割り当てられたリソースのステータスを可視化することで障害処理を改善し、正常なデバイスにワークロードを再割り当てするのに役立ちます。障害としてマークされた ポッドの場合でも、kubelet が ポッドを追跡している限り、デバイスのステータスにアクセスできる状態が維持されるため、デバイス関連の ポッド配置の問題に対処するための包括的なデバッグ情報が確保されます。

Kubernetes 1.32 スケジューリング

#4247 kube-schedulerにおける正確な再キューイングのためのプラグインごとのコールバック関数

Stage: Graduating to Beta
Feature group: sig-scheduling

スケジューリングSIGは、ポッドの再キューイングを調整することでKubernetesのスケジューリング性能を向上させる新機能「QueueingHint」を導入します。この機能により、プラグインがポッドを再試行するタイミングを提案できるメカニズムを提供し、不要な再試行を回避することでスケジューリングのオーバーヘッドを削減し、スループットを向上させます。具体的には、NodeAffinityのようなプラグインが、成功する可能性が高いタイミング（例: ノードの更新によってスケジューリング可能になった場合）でのみポッドを再キューイングすることを可能にします。

さらに、この提案はDynamicResourceAllocation（DRA）のようなプラグインがバックオフ期間をスキップできるようにし、動的リソースに依存するポッドのスケジューリングを効率化します。これにより、デバイスドライバからの更新を待つことで生じる遅延が軽減されます。この最適化は、特に複数サイクルを必要とするワークロードにおいて、全体的なスケジューリング効率を向上させます。

#3902 TaintManager を NodeLifecycleController から分離する

Stage: Graduating to Stable
Feature group: sig-scheduling

この提案は、KubernetesにおいてNodeLifecycleControllerとTaintManagerを分離し、2つの独立したコントローラーを作成することを目的としています。1つは、不健康なノードに対してテイントを追加するためのNodeLifecycleControllerであり、もう1つは、それらのテイントに基づいてポッドのエビクションを処理するTaintEvictionControllerです。

この分離により、ノードへのテイント付与とポッドのエビクションの責任を分離することで、コードの整理と保守性が向上します。また、各コンポーネントへの将来的な機能拡張が容易になり、テイントベースのエビクションのカスタム実装を可能にします。結果として、ノードの健全性管理やポッドのライフサイクル管理が効率化されます。

#4832スケジューラーにおける非同期プリエンプション

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

この改善では、2 つのコア機能 (具体的には PostFilter 拡張ポイントの後のメインスケジューリング サイクルからのプリエンプションAPI 呼び出し) を切り離して、障害シナリオでのスケジューリングスループットを向上させることも検討しています。現在、プリエンプションタスクは PostFilter フェーズ中に同期的に実行されており、必要な API 呼び出しによりスケジューリング サイクルがブロックされる可能性があります。 

これらの API 呼び出しを非同期にすることで、スケジューラはプリエンプションプロセスによって遅延されることなく、他の ポッドの処理を​​継続できます。この変更により、スケジューラが他のタスクと並行してプリエンプションを処理できるようになり、スケジューリングの効率が向上し、最終的に全体的なスケジューリング スループットが高速化されます。

Kubernetes 1.32 ストレージ

#1790ボリューム拡張障害からの回復をサポート

Stage: Graduating to Beta
Feature group: sig-storage

このsig-storageチームは、PVCの拡張に失敗した後にユーザーが再試行できるように、APIのバリデーションを緩和してリクエストされたサイズを縮小できるようにすることを検討しています。これにより、ストレージプロバイダーの容量を超える拡張など、基盤となるストレージプロバイダーでサポートされていない拡張を修正できるようになります。

新しいフィールドとして、pvc.Status.AllocatedResources が導入され、PVCサイズが縮小された場合でもリソースクォータを正確に追跡できるようになります。また、リクエストされたサイズは pvc.Status.Capacity より大きい値にのみ縮小できるようにシステムが保証し、意図しない縮小を防ぎます。

クォータシステムを保護するために、クォータの計算には pvc.Spec.Capacity と pvc.Status.AllocatedResources のうち最大値を使用します。さらに、割り当てられたリソースの縮小は、拡張の失敗が確定した場合にのみ許可されます。この提案により、拡張失敗からの復旧が簡素化されるとともに、クォータシステムが保護されます。

#3476ボリュームグループスナップショット

Stage: Graduating to Beta
Feature group: sig-storage

この改善により、ラベル セレクターを使用して PVC をグループ化し、複数のボリュームのクラッシュ整合性のあるスナップショットを同時に取得するための Kubernetes API が導入されます。新しい CRD (VolumeGroupSnapshot、VolumeGroupSnapshotContent、および VolumeGroupSnapshotClass) が定義され、ユーザーは複数のボリュームのスナップショットを同じ時点で作成できるようになり、グループ内のすべてのボリューム間で書き込み順序の一貫性が確保されます。 

この機能により、アプリケーションの静止や、個々のスナップショットを順番に取得するという時間のかかるプロセスが不要になります。アプリケーションのパフォーマンスに影響を与えずに一貫性のあるグループスナップショットをキャプチャする機能を提供することで、夜間のバックアップや災害復旧などのユース ケースに特に役立ち、アプリケーションのスナップショット作成とバックアップに関する他の提案を補完します。 

API は、CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT 機能を活用して CSI ボリューム ドライバーと連携するように設計されています。

#1710再帰的な SELinux ラベル変更を高速化

Stage: Graduating to Beta
Feature group: sig-storage

ここでの目的は、ファイルの再帰的な再ラベル付けの必要性を排除することで、 SELinux が強制モードのシステムでボリュームを ポッドで使用できるようにするプロセスを高速化することでした。現在、コンテナ ランタイムは、コンテナを起動する前にボリューム上のすべてのファイルを再帰的に再ラベル付けする必要があり、これは多くのファイルを含むボリュームでは時間がかかります。提案されたソリューションは、-o context=XYZ マウントオプションを使用して、再帰的なウォークを必要とせずにボリューム上のすべてのファイルに SELinux コンテキストを設定します。この変更は段階的に展開され、ReadWriteOncePod ボリュームから開始し、最終的にはデフォルトですべてのボリュームに拡張され、特定のケースでユーザーがオプトアウトするオプションが提供されます。このアプローチにより、さまざまなユース ケースに対する柔軟性を維持しながら、パフォーマンスが大幅に向上します。

Kubernetes 1.32 その他の機能強化

#2831 Kubelet OpenTelemetry トレース

Stage: Graduating to Stable
Feature group: sig-node

Status: Deferred

この KEP は v.1.32 に延期され、OpenTelemetry ライブラリを使用してトレース データを OpenTelemetry 形式でエクスポートし、gRPC および HTTP API リクエストのトレースのサポートを追加することで、kubelet を強化することを目的としています。kubernetes/component-base 内で指定された kubelet のオプションの TracingConfiguration を活用することで、クラスター オペレーター、管理者、およびクラウド ベンダーは、kubelet、コンテナ ランタイム、および API サーバー間のやり取りからトレース データを収集するように kubelet を構成できます。 

この機能は、ポッドの作成や CRI、CNI、CSI インターフェースとのやり取りなど、さまざまな kubelet アクションのスパンを生成し、トラブルシューティングと監視に役立つ貴重な情報を提供します。分散トレースの追加により、レイテンシとノードの問題の診断が容易になり、Kubernetes 全体の監視と管理が向上します。

#4017 StatefulSet とインデックスジョブにポッドインデックスラベルを追加

Stage: Net New to Alpha
Feature group: sig-apps
Status: Tracked for code freeze

この KEP を読んでいくと、改善提案では、StatefulSet ポッドのインデックスをアノテーションとラベルの両方として追加することで、インデックスを識別するプロセスを簡素化することがわかります。現在、インデックスはポッド名を解析して抽出されていますが、これは理想的ではありません。インデックスをアノテーションとして設定することで、Downward API を介して環境変数として簡単にアクセスできるようになります。 

さらに、インデックスをラベルとして追加すると、インデックスに基づいてポッドを簡単にフィルタリングおよび選択できるようになります。提案では、ラベルを使用してトラフィックを StatefulSet ポッドの特定のインスタンスにターゲット設定することも提案されており、トラフィックをフィルタリングしたり、セット内の最初のポッドに誘導したりするなどのユースケースの柔軟性が向上します。

#2837ポッドレベルリソース

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

Status: Tracked for code freeze

この機能強化では、Pod API を拡張して、既存のコンテナレベルの設定に加えて、ポッドレベルでリソースリクエストとリミット指定できるようにすることを提案しています。現在、リソース割り当てはコンテナ中心であるため、リソース需要が変化する複数のコンテナの ポッドを管理するのは面倒な場合があります。 

この提案では、ポッドレベルのリソース制約を有効にすることでリソース管理が簡素化され、各コンテナを個別に構成しなくてもポッドの全体的なリソース消費を制御しやすくなります。このアプローチにより、特に密結合アプリケーションやバーストワークロードのリソース使用率が向上し、既存のコンテナレベルの構成や Kubernetes 機能との互換性が維持されます。

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

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

Kubernetes エコシステムの最新情報を知りたい場合は、クラウドネイティブ エコシステムで起こっている最も興味深い出来事を毎月メールでお届けするコンテナ ニュースレターを購読してください。