This article is more than one year old. Older articles may contain outdated content. Check that the information in the page has not become incorrect since its publication.
編集者: Matteo Bianchi, Edith Puclla, William Rizzo, Ryota Sawada, Rashan Smith
Kubernetes v1.32: Penelopeのリリースを発表します!
これまでのリリースと同様に、Kubernetes v1.32では新たなGA、ベータ、アルファの機能が導入されています。 継続的に高品質なリリースを提供できていることは、私たちの開発サイクルの強さと、活発なコミュニティのサポートを示すものです。 今回のリリースでは、44の機能強化が行われました。 そのうち、13の機能がGAに昇格し、12の機能がベータに移行し、19の機能がアルファとして導入されています。

Kubernetes v1.32のリリーステーマは"Penelope"です。
Kubernetesが古代ギリシャ語で「パイロット」または「舵取り」を意味することから始め、このリリースではKubernetesの10年間とその成果を振り返ります。 各リリースサイクルは一つの旅路であり、「オデュッセイア」のペーネロペーが10年の間、昼に織ったものを夜になると解いていったように、各リリースでは新機能の追加と既存機能の削除を行います。 ただしここでは、Kubernetesを継続的に改善するというより明確な目的を持って行われています。 v1.32はKubernetesが10周年を迎える年の最後のリリースとなることから、クラウドネイティブの海の試練や課題を航海してきたグローバルなKubernetesクルーの一員として貢献してくださった全ての方々に敬意を表したいと思います。 これからも共にKubernetesの未来を紡いでいけることを願っています。
今回のリリースでは、前回のリリースと同様に、KubernetesプロジェクトはDynamic Resource Allocation(DRA)に対して多くの機能強化を提案し続けています。 DRAはKubernetesのリソース管理システムの主要なコンポーネントです。 これらの機能強化は、GPU、FPGA、ネットワークアダプターなどの特殊なハードウェアを必要とするワークロードに対するリソース割り当ての柔軟性と効率性を向上させることを目的としています。
これらの機能は、機械学習や高性能コンピューティングアプリケーションなどのユースケースで特に有用です。DRAのStructured parameterサポートを可能にするコア部分はベータに昇格しました。
SIG Nodeでは、KEPの範囲を超えて以下のような改善が行われています:
kubeletのヘルスチェックが失敗した際にkubeletを再起動するために、systemdのwatchdog機能が使用されるようになりました。 また、一定時間内の最大再起動回数も制限されます。 これによりkubeletの信頼性が向上します。 詳細についてはPull Requestの#127566をご覧ください。
イメージプルのバックオフエラーが発生した場合、Podのステータスに表示されるメッセージが改善され、より分かりやすくなり、Podがこの状態にある理由の詳細が示されるようになりました。
イメージプルのバックオフが発生すると、エラーはPod仕様のstatus.containerStatuses[*].state.waiting.messageフィールドに追加され、reasonフィールドにはImagePullBackOffの値が設定されます。
この変更により、より多くのコンテキストが提供され、問題の根本原因を特定するのに役立ちます。
詳細については、Pull Requestの#127918をご覧ください。
サイドカーコンテナ機能は、v1.33でStableへの昇格を目指しています。 残りの作業項目とユーザーからのフィードバックについては、Issueの#753のコメントをご覧ください。
これは、v1.32のリリースに伴いGAとなった改善点の一部です。
カスタムリソースのフィールドセレクターにより、開発者は組み込みのKubernetesオブジェクトで利用できる機能と同様に、カスタムリソースにフィールドセレクターを追加できるようになりました。 これにより、カスタムリソースのより効率的で正確なフィルタリングが可能になり、より良いAPI設計の実践を促進します。
この作業は、SIG API MachineryによりKEP #4358の一部として実施されました。
この機能により、Podのリソース制限に基づいてメモリバックアップボリュームを動的にサイズ設定できるようになり、ワークロードの移植性とノードのリソース使用率の全体的な向上を実現します。
この作業は、SIG NodeによりKEP #1967の一部として実施されました。
サービスアカウントトークンのクレームにノード名を含めることで、認可と認証(ValidatingAdmissionPolicy)の過程でこの情報を使用できるようになりました。 さらに、この改善によりサービスアカウントの認証情報がノードの権限昇格パスとなることを防ぎます。
この作業は、SIG AuthによりKEP #4193の一部として実施されました。
APIサーバーに複数の認可機能を設定できるようになり、webhookでのCELマッチ条件をサポートすることで、構造化された認可の判断が可能になりました。
この作業は、SIG AuthによりKEP #3221の一部として実施されました。
StatefulSetが作成したPersistentVolumeClaim(PVC)は、不要になると自動的に削除されるようになりました。 これはStatefulSetの更新やノードのメンテナンス時にもデータを確実に保持したまま削除処理を行います。 この機能により、StatefulSetのストレージ管理が容易になり、PVCが残されたままになるリスクも減少します。
この作業は、SIG AppsによりKEP #1847の一部として実施されました。
これは、v1.32のリリースに伴いベータとなった改善点の一部です。
JobのmanagedByフィールドがv1.32でベータに昇格しました。
この機能により、外部コントローラー(Kueueなど)がJobの同期を管理できるようになり、高度なワークロード管理システムとのより柔軟な統合が可能になります。
この作業は、SIG AppsによりKEP #4368の一部として実施されました。
この機能により、管理者は匿名リクエストを許可するエンドポイントを指定できるようになりました。
例えば、管理者は/healthz、/livez、/readyzなどのヘルスエンドポイントへの匿名アクセスのみを許可し、ユーザーがRBACを誤設定した場合でも、他のクラスターエンドポイントやリソースへの匿名アクセスを確実に防止できます。
この作業は、SIG AuthによりKEP #4633の一部として実施されました。
この機能は、プラグインごとのコールバック関数(QueueingHint)によってスケジューリングの再試行の判断をより効率的にすることで、スケジューリングのスループットを向上させます。 すべてのプラグインがQueueingHintsを持つようになりました。
この作業は、SIG SchedulingによりKEP #4247の一部として実施されました。
この機能により、ユーザーは小さいサイズで再試行することでボリューム拡張の失敗から回復できるようになりました。 この改善により、ボリューム拡張がより堅牢で信頼性の高いものとなり、プロセス中のデータ損失や破損のリスクが軽減されます。
この作業は、SIG StorageによりKEP #1790の一部として実施されました。
この機能は、VolumeGroupSnapshot APIを導入し、ユーザーが複数のボリュームを同時にスナップショット取得できるようにすることで、ボリューム間のデータ整合性を確保します。
この作業は、SIG StorageによりKEP #3476の一部として実施されました。
Dynamic Resource Allocation(DRA)のコア部分である構造化パラメーターのサポートがベータに昇格しました。 これにより、kube-schedulerとCluster Autoscalerはサードパーティドライバーを必要とせずに、直接クレームの割り当てをシミュレーションできるようになりました。
これらのコンポーネントは、実際に割り当てを確定することなく、クラスターの現在の状態に基づいてリソース要求が満たされるかどうかを予測できるようになりました。 サードパーティドライバーによる割り当ての検証やテストが不要になったことで、この機能はリソース分配の計画と意思決定を改善し、スケジューリングとスケーリングのプロセスをより効率的にします。
この作業は、WG Device Management(SIG Node、SIG Scheduling、SIG Autoscalingを含む機能横断チーム)によりKEP #4381の一部として実施されました。
認可の判断にラベルとフィールドセレクターを使用できるようになりました。 ノードの認可機能は、これを自動的に活用してノードが自身のPodのみをリストやウォッチできるように制限します。 Webhookの認可機能は、使用されるラベルやフィールドセレクターに基づいてリクエストを制限するように更新できます。
この作業は、SIG AuthによりKEP #4601の一部として実施されました。
これは、v1.32のリリースでアルファとして導入された主な改善点の一部です。
Kubernetesスケジューラーは、プリエンプション操作を非同期で処理することでスケジューリングのスループットを向上させる、非同期プリエンプション機能が強化されました。 プリエンプションは、優先度の低いPodを退避させることで、優先度の高いPodに必要なリソースを確保します。 しかし、これまでこのプロセスではPodを削除するためのAPIコールなどの重い操作が必要で、スケジューラーの速度低下を引き起こしていました。 この強化により、そのような処理が並列で実行されるようになり、スケジューラーは他のPodのスケジューリングを遅延なく継続できるようになりました。 この改善は、特にPodの入れ替わりが頻繁なクラスターや、スケジューリングの失敗が頻発するクラスターで有効で、より効率的で堅牢なスケジューリングプロセスを実現します。
この作業は、SIG SchedulingによりKEP #4832の一部として実施されました。
この機能は、CELのオブジェクトインスタンス化とJSONパッチ戦略を、Server Side Applyのマージアルゴリズムと組み合わせて活用します。 これにより、ポリシー定義が簡素化され、変更の競合が削減され、アドミッション制御のパフォーマンスが向上すると同時に、Kubernetesにおけるより堅牢で拡張可能なポリシーフレームワークの基盤が構築されます。
KubernetesのAPIサーバーは、Common Expression Language(CEL)ベースのMutating Admission Policyをサポートするようになり、Mutating Admission Webhookの軽量で効率的な代替手段を提供します。 この強化により、管理者はCELを使用して、ラベルの設定、フィールドのデフォルト値設定、サイドカーの注入といった変更を、シンプルな宣言的な式で定義できるようになりました。 このアプローチにより、運用の複雑さが軽減され、webhookの必要性が排除され、kube-apiserverと直接統合されることで、より高速で信頼性の高いプロセス内変更処理を実現します。
この作業は、SIG API MachineryによりKEP #3962の一部として実施されました。
この機能強化により、Podレベルでリソースの要求と制限を設定できるようになり、Pod内のすべてのコンテナが動的に使用できる共有プールを作成することで、Kubernetesのリソース管理が簡素化されます。 これは特に、リソース需要が変動的またはバースト的なコンテナを持つワークロードにとって有用で、過剰なプロビジョニングを最小限に抑え、全体的なリソース効率を向上させます。
KubernetesはPodレベルでLinuxのcgroup設定を活用することで、これらのリソース制限を確実に適用しながら、密結合したコンテナが人為的な制約に縛られることなく、より効果的に連携できるようにします。 重要なことに、この機能は既存のコンテナレベルのリソース設定との後方互換性を維持しており、ユーザーは現在のワークフローや既存の設定を中断することなく、段階的に採用できます。
これは、コンテナ間のリソース割り当て管理の運用複雑性を軽減するため、マルチコンテナPodにとって重要な改善となります。 また、コンテナがワークロードを共有したり、最適なパフォーマンスを発揮するために互いの可用性に依存したりするサイドカーアーキテクチャなどの密接に統合されたアプリケーションにおいて、パフォーマンスの向上をもたらします。
この作業は、SIG NodeによりKEP #2837の一部として実施されました。
この機能強化により、KubernetesのPreStopライフサイクルフックで0秒のスリープ時間を設定できるようになり、リソースの検証とカスタマイズのためのより柔軟な無操作オプションを提供します。 これまでは、スリープアクションにゼロ値を設定しようとするとバリデーションエラーが発生し、その使用が制限されていました。 この更新により、ユーザーはゼロ秒の時間を有効なスリープ設定として設定でき、必要に応じて即時実行と終了の動作が可能になります。
この機能強化は後方互換性があり、PodLifecycleSleepActionAllowZeroフィーチャーゲートによって制御されるオプトイン機能として導入されています。
この変更は、実際のスリープ時間を必要とせずに、検証やAdmission Webhook処理のためにPreStopフックを必要とするシナリオで特に有効です。
Goのtime.After関数の機能に合わせることで、この更新はKubernetesワークロードの設定を簡素化し、使いやすさを向上させます。
この作業は、SIG NodeによりKEP #4818の一部として実施されました。
この機能強化により、ドライバーがResourceClaimの各割り当てオブジェクトに対して特定のデバイスステータスデータを報告できる新しいフィールドが追加されました。
また、ネットワークデバイス情報を表現するための標準的な方法も確立されました。
この作業は、SIG NetworkによりKEP #4817の一部として実施されました。
コアコンポーネントに対して、2つの新しいHTTPエンドポイント(/statuszと/flagz)を有効にできるようになりました。
これらのエンドポイントは、コンポーネントが実行されているバージョン(Golangのバージョンなど)や、稼働時間、そのコンポーネントが実行された際のコマンドラインフラグの詳細を把握することで、クラスターのデバッグ性を向上させます。
これにより、実行時および設定の問題の診断が容易になります。
この作業は、SIG InstrumentationによりKEP #4827とKEP #4828の一部として実施されました。
Kubernetesクラスターにおいて、Windowsノードの正常なシャットダウンのサポートが追加されました。 このリリース以前、KubernetesはLinuxノードに対して正常なノードシャットダウン機能を提供していましたが、Windowsに対する同等のサポートは欠けていました。 この機能強化により、Windowsノード上のkubeletがシステムのシャットダウンイベントを適切に処理できるようになりました。 これにより、Windowsノード上で実行されているPodが正常に終了され、ワークロードの中断なしでの再スケジュールが可能になります。 この改善により、特に計画的なメンテナンスやシステム更新時において、Windowsノードを含むクラスターの信頼性と安定性が向上します。
さらに、CPUマネージャー、メモリマネージャー、トポロジーマネージャーの改善により、Windowsノードに対するCPUとメモリのアフィニティサポートが追加されました。
この作業は、SIG WindowsによりKEP #4802とKEP #4885の一部として実施されました。
ここでは、GA(一般提供 とも呼ばれる)に昇格したすべての機能を紹介します。新機能やアルファからベータへの昇格を含む完全な更新リストについては、リリースノートをご覧ください。
このリリースでは、以下の13個の機能強化がGAに昇格しました:
status.hostIPs added for PodKubernetesの開発と成熟に伴い、プロジェクト全体の健全性のために、機能が非推奨化、削除、またはより良いものに置き換えられる場合があります。 このプロセスの詳細については、Kubernetesの非推奨化と削除のポリシーをご覧ください。
KEP #3063により、Kubernetes 1.26でDynamic Resource Allocation(DRA)が導入されました。
しかし、Kubernetes v1.32では、このDRAのアプローチが大幅に変更されます。元の実装に関連するコードは削除され、KEP #4381が「新しい」基本機能として残ります。
既存のアプローチを変更する決定は、リソースの可用性が不透明であったことによるクラスターオートスケーリングとの非互換性に起因しており、これによりCluster Autoscalerとコントローラーの両方の意思決定が複雑化していました。 新しく追加されたStructured Parameterモデルがその機能を置き換えます。
この削除により、Kubernetesはkube-apiserverとの双方向のAPIコールの複雑さを回避し、新しいハードウェア要件とリソースクレームをより予測可能な方法で処理できるようになります。
詳細については、KEP #3063をご覧ください。
Kubernetes v1.32では、以下のAPIが削除されます:
flowcontrol.apiserver.k8s.io/v1beta3 APIバージョンが削除されます。
これに備えるため、既存のマニフェストを編集し、v1.29以降で利用可能なflowcontrol.apiserver.k8s.io/v1 APIバージョンを使用するようにクライアントソフトウェアを書き換えることができます。
既存の永続化されたオブジェクトはすべて新しいAPIを通じてアクセス可能です。
flowcontrol.apiserver.k8s.io/v1beta3における主な変更点として、PriorityLevelConfigurationのspec.limited.nominalConcurrencySharesフィールドは未指定の場合にのみデフォルトで30となり、明示的に0が指定された場合は30に変更されないようになりました。詳細については、API廃止に関する移行ガイドを参照してください。
Kubernetes v1.32リリースの詳細については、リリースノートをご確認ください。
Kubernetes v1.32は、GitHubまたはKubernetesダウンロードページからダウンロードできます。
Kubernetesを始めるには、対話式のチュートリアルをチェックするか、minikubeを使用してローカルKubernetesクラスタを実行してください。 また、kubeadmを使用して簡単にv1.32をインストールすることもできます。
Kubernetesは、そのコミュニティのサポート、献身、そして懸命な努力に支えられて実現しています。 各リリースチームは、皆様が頼りにしているKubernetesリリースを構成する多くの要素を構築するために協力して働く、献身的なコミュニティボランティアで構成されています。 これには、コード自体からドキュメンテーション、プロジェクト管理に至るまで、コミュニティのあらゆる分野から専門的なスキルを持つ人々が必要です。
私たちは、Kubernetes v1.32リリースをコミュニティに提供するために多くの時間を費やしてくださったリリースチーム全体に感謝の意を表します。 リリースチームのメンバーは、初めてShadowとして参加する人から、複数のリリースサイクルを経験したベテランのチームリーダーまで多岐にわたります。 リリースリードのFrederico Muñozには、リリースチームを見事に率いて、あらゆる事柄を細心の注意を払って処理し、このリリースを円滑かつ効率的に実行してくれたことに、特別な感謝の意を表します。 最後になりましたが、すべてのリリースメンバー(リードとShadowの双方)、そして14週間のリリース作業期間中に素晴らしい仕事と成果を上げてくれた以下のSIGsに、大きな感謝の意を表します:
CNCFのK8s DevStatsプロジェクトは、Kubernetesと様々なサブプロジェクトの進捗に関する興味深いデータポイントを集計しています。 これには、個人の貢献から貢献している企業の数まで、このエコシステムの進化に関わる取り組みの深さと広さを示す様々な情報が含まれています。
14週間(9月9日から12月11日まで)続いたv1.32リリースサイクルでは、125の異なる企業と559の個人がKubernetesに貢献しました。
クラウドネイティブエコシステム全体では、433の企業から合計2441人の貢献者がいます。 これは前回のリリースサイクルと比較して、全体の貢献が7%増加し、参加企業数も14%増加したことを示しており、クラウドネイティブプロジェクトに対する強い関心とコミュニティの支持が表れています。
このデータの出典:
ここでの貢献とは、コミットの作成、コードレビュー、コメント、IssueやPRの作成、PR(ブログやドキュメントを含む)のレビュー、もしくはIssueやPRへのコメントを指します。
コントリビューターウェブサイトのGetting Startedから、貢献を始める方法をご確認ください。
Kubernetesプロジェクトとコミュニティの全体的な活動状況の詳細については、DevStatsをご確認ください。
2025年3月から6月にかけて開催予定のKubernetesとクラウドネイティブ関連のイベントをご紹介します。 KubeCon、KCD、その他世界各地で開催される注目のカンファレンスが含まれています。 Kubernetesコミュニティの最新情報を入手し、交流を深めましょう。
2025年3月
2025年4月
2025年5月
2025年6月
2025年1月9日(木)午後5時(太平洋時間) に開催されるKubernetes v1.32リリースチームメンバーによるウェビナーにご参加ください。 このリリースの主要な機能や、アップグレード計画に役立つ非推奨化および削除された機能について学ぶことができます。 詳細および参加登録については、CNCFオンラインプログラムサイトのイベントページをご覧ください。
Kubernetesに関わる最も簡単な方法は、あなたの興味に合ったSpecial Interest Groups(SIG)のいずれかに参加することです。 Kubernetesコミュニティに向けて何か発信したいことはありますか? 毎週のコミュニティミーティングや、以下のチャンネルであなたの声を共有してください。 継続的なフィードバックとサポートに感謝いたします。