Kubernetes v1.36: ハル (Haru)

By Kubernetes v1.36 Release Team | 翻訳: Taisuke Okamoto (PLAID, Inc.), Takuya Kitamura, Ryota Sawada (Numtide Sàrl), Junya Okabe (Mercari, Inc.) |

編集者: Chad M. Crowell、Kirti Goyal、Sophia Ugochukwu、Swathi Rao、Utkarsh Umre

前回のリリースと同様に、Kubernetes v1.36のリリースでは新しいGA、ベータ、アルファの機能が導入されます。 高品質なリリースの継続的な提供は、私たちの開発サイクルの強さとコミュニティからの活発なサポートを示しています。

このリリースは70個の機能改善で構成されています。 それらのうち、GAへの昇格が18個、ベータへの移行が25個、アルファとしての導入が25個です。

また、このリリースにはいくつかの非推奨化と削除があります。 これらに必ず目を通してください。

Kubernetes v1.36で2026年の幕を開けます。 このリリースは季節が移り変わり、山の光が変化する時に届きました。 ハルは日本語で多くの意味を持つ響きです。 その中で最も大切にしているのは、春、晴れ(澄んだ空)、そして遥か(遠く離れた)です。 季節と空と地平線。 この先にある内容には、その3つすべてが見つかるでしょう。

ロゴはavocadoneko / Natsuho Ideによって作成され、葛飾北斎の『富嶽三十六景』からインスピレーションを得ています。 これは『神奈川沖浪裏』を世界に送り出したのと同じシリーズです。 v1.36のロゴは、シリーズの中で最も有名な作品の一つである『凱風快晴』、赤富士とも呼ばれる作品を再解釈しています。 夏の夜明けに赤く染まった山が、長い雪解けの後に雪のない姿を見せる光景です。 三十六の景色はv1.36にふさわしい数であり、北斎もそこで止まらなかったことを思い起こさせます。1 その風景を見守るのはKubernetesの舵輪で、山の傍らの空に配置されています。

富士の麓にはStella(左)とNacho(右)という2匹の猫が座っています。 首輪にKubernetesの舵輪が付いた彼らは、日本の神社を守る一対の狛犬の役割を担っています。 一対であるのは、何事も一人では守れないからです。 StellaとNachoは、はるかに大きな仲間を代表しています。 SIGとワーキンググループ、メンテナーとレビュアー、ドキュメント、ブログ、翻訳の担当者、リリースチーム、初めての一歩を踏み出す新規コントリビューター、そして季節ごとに戻ってくる長年のコントリビューターです。 Kubernetes v1.36は、いつものように多くの手によって支えられています。

ロゴの赤富士の峰に沿って「晴れに翔け」という書が描かれています。 これは山に収まりきらなかった対句の前半です:

晴れに翔け、未来よ明け
「澄んだ空へ翔け、明日の夜明けに向かって」

これが、このリリースに込めた願いです。 澄んだ空へ翔けること。 リリースそのもののため、プロジェクトのため、そしてそれを共に届けるすべての人のために。 赤富士に差す朝日は終わりではなく、通過点です。 このリリースは次のリリースへ、そのリリースはまたその次へと、一つの視点では捉えきれない遥かな地平線に向かって続いていきます。

1. このシリーズは非常に人気があったため、北斎はさらに10枚の版画を追加し、合計46枚になりました。

主なアップデート情報

Kubernetes v1.36は新機能と改善点が満載です。 このセクションでは、リリースチームが特に注目して欲しい、選りすぐりのアップデート内容をご紹介します！

安定版: きめ細かなAPI認可

Kubernetes SIG AuthおよびSIG Nodeを代表して、きめ細かなkubelet API認可がKubernetes v1.36でGA(General Availability)に昇格したことをお知らせします！

KubeletFineGrainedAuthzフィーチャーゲートは、Kubernetes v1.32でオプトインのアルファ機能として導入され、v1.33でベータ(デフォルトで有効)に昇格しました。 現在、この機能はGAになりました。 この機能は、kubeletのHTTPS APIに対してより精密な最小権限のアクセス制御を可能にし、一般的な監視や可観測性のユースケースにおいて過度に広範なnodes/proxy権限を付与する必要性を排除します。

この取り組みは、SIG AuthとSIG Nodeが主導したKEP #2862の一環として行われました。

ベータ: リソースヘルスステータス

v1.34のリリース以前は、Kubernetesには割り当てられたデバイスの健全性を報告するネイティブな方法がなく、ハードウェア障害によるPodのクラッシュを診断することが困難でした。 Device Pluginに焦点を当てたv1.31での最初のアルファリリースを基に、Kubernetes v1.36では各Podの.status内のallocatedResourcesStatusフィールドをベータに昇格させることでこの機能を拡張しています。 このフィールドは、すべての専用ハードウェアに対する統一されたヘルスレポート機構を提供します。

ユーザーはkubectl describe podを実行して、コンテナのクラッシュループがUnhealthyまたはUnknownのデバイスステータスによるものかどうかを判断できるようになりました。 これは、ハードウェアが従来のプラグインまたは新しいDRAフレームワークのどちらで提供されているかに関係なく機能します。 この可視性の向上により、管理者と自動化されたコントローラーは故障したハードウェアを迅速に特定し、高性能ワークロードのリカバリを効率化できます。

この取り組みは、SIG Nodeが主導したKEP #4680の一環として行われました。

アルファ: Workload Aware Scheduling(WAS)機能

従来、KubernetesスケジューラーとJobコントローラーはPodを独立したユニットとして管理していたため、複雑な分散ワークロードにおいて断片的なスケジューリングやリソースの浪費が発生することがよくありました。 Kubernetes v1.36では、Workload Aware Scheduling(WAS)機能の包括的なスイートをアルファとして導入し、Jobコントローラーを改訂されたWorkload APIと新しい分離されたPodGroup APIにネイティブに統合することで、関連するPodを単一の論理エンティティとして扱えるようにしています。

Kubernetes v1.35では、Podがノードにバインドされる前にスケジュール可能な最小数のPodを要求することで、すでにGangスケジューリングをサポートしていました。 v1.36では、グループ全体をアトミックに評価する新しいPodGroupスケジューリングサイクルを導入し、さらに進化しています。 グループ内のすべてのPodがまとめてバインドされるか、一つもバインドされないかのどちらかです。

この取り組みは、SIG SchedulingとSIG Appsが主導した複数のKEP(#4671、#5547、#5832、#5732、#5710を含む)の一環として行われました。

GAに昇格した機能

これはv1.36リリース後にGAとなった改善点の一部です。

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

数回のベータサイクルを経て、VolumeGroupSnapshotサポートがKubernetes v1.36でGA(General Availability)に到達しました。 この機能により、複数のPersistentVolumeClaimにわたるクラッシュ整合性のあるスナップショットを同時に取得できます。 ボリュームグループスナップショットのサポートは、グループスナップショット用の拡張APIのセットに依存しています。 これらのAPIにより、ユーザーは一連のボリュームに対してクラッシュ整合性のあるスナップショットを取得できます。 主な目的は、そのスナップショットのセットを新しいボリュームに復元し、クラッシュ整合性のあるリカバリポイントに基づいてワークロードを復旧できるようにすることです。

この取り組みは、SIG Storageが主導したKEP #3476の一環として行われました。

変更可能なボリュームアタッチ制限

Kubernetes v1.36では、変更可能なCSINodeのAllocatable 機能がGAに昇格しました。 この機能強化により、Container Storage Interface(CSI)ドライバーがノードで処理可能なボリュームの最大数を動的に更新できるようになります。

この更新により、kubeletはノードのボリューム制限と容量情報を動的に更新できるようになりました。 kubeletは、定期的なチェックまたはCSIドライバーからのリソース枯渇エラーに応じて、コンポーネントの再起動を必要とせずにこれらの制限を調整します。 これにより、Kubernetesスケジューラーはストレージの可用性に関する正確な情報を維持し、古いボリューム制限によるPodスケジューリングの失敗を防止します。

この取り組みは、SIG Storageが主導したKEP #4876の一環として行われました。

ServiceAccountトークンの外部署名API

Kubernetes v1.36では、ServiceAccountの 外部トークン署名 機能がGAに昇格し、Kubernetes APIとのクリーンな統合を維持しながらトークン署名を外部システムに委譲できるようになりました。 クラスターは、標準的なServiceAccountトークン形式に従うProjected ServiceAccountトークンの発行に外部JWT署名者を使用でき、必要に応じて延長された有効期限もサポートします。 これは、すでに外部のIDまたは鍵管理システムに依存しているクラスターにとって特に有用で、コントロールプレーン内で鍵管理を重複させることなくKubernetesを統合できます。

kube-apiserverは外部署名者から公開鍵を検出し、キャッシュし、自身が署名していないトークンを検証するように構成されているため、既存の認証・認可フローは期待通りに動作し続けます。 アルファおよびベータフェーズを通じて、外部署名者プラグインのAPIと設定、パス検証、およびOIDCディスカバリは、実際の本番環境のデプロイメントとローテーションパターンに安全に対応できるよう強化されました。

v1.36でのGA昇格により、外部ServiceAccountトークン署名は、IDと署名を一元管理するプラットフォームにとって完全にサポートされたオプションとなり、外部IAMシステムとの統合が簡素化され、コントロールプレーン内で署名鍵を直接管理する必要性が軽減されます。

この取り組みは、SIG Authが主導したKEP #740の一環として行われました。

GAに昇格したDRA機能

Dynamic Resource Allocation(DRA)エコシステムの一部が、Kubernetes v1.36で主要なガバナンスと選択機能のGA昇格により本番環境で利用可能な成熟度に達しました。 DRA管理者アクセス のGA移行により、クラスター管理者がハードウェアリソースにグローバルにアクセスして管理するための永続的でセキュアなフレームワークが提供され、優先順位付きリスト の安定化により、リソース選択ロジックがすべてのクラスター環境で一貫性と予測可能性を保つようになりました。

これにより、組織は長期的なAPIの安定性と後方互換性の保証のもとで、ミッションクリティカルなハードウェア自動化を安心してデプロイできます。 これらの機能により、大規模GPUクラスターやマルチテナントAIプラットフォームに不可欠な高度なリソース共有ポリシーと管理オーバーライドの実装が可能になり、次世代リソース管理のコアアーキテクチャ基盤の完成を示しています。

この取り組みは、SIG AuthとSIG Schedulingが主導したKEP #5018および#4816の一環として行われました。

Mutating Admissionポリシー

Kubernetes v1.36では、MutatingAdmissionPolicyのGA昇格により、宣言的なクラスター管理がより洗練されたものとなりました。 このマイルストーンは、管理者がCommon Expression Language(CEL)を使用してAPIサーバー内でリソースの変更を直接定義できるようにすることで、従来のWebhookに代わるネイティブで高性能な代替手段を提供し、多くの一般的なユースケースにおいて外部インフラストラクチャの必要性を完全に排除します。

これにより、クラスターオペレーターはカスタムAdmission Webhookの管理に伴うレイテンシや運用の複雑さなしに、受信リクエストを変更できます。 変更ロジックを宣言的でバージョン管理されたポリシーに移行することで、組織はより予測可能なクラスター動作、ネットワークオーバーヘッドの削減、そして長期的なAPIの安定性が完全に保証された堅牢なセキュリティモデルを実現できます。

この取り組みは、SIG API Machineryが主導したKEP #3962の一環として行われました。

validation-genによるKubernetesネイティブ型の宣言的バリデーション

Kubernetes v1.36では、宣言的バリデーション (validation-genを使用)のGA昇格により、カスタムリソースの開発がさらに効率的なものとなりました。 このマイルストーンは、Common Expression Language(CEL)を使用してGoの構造体タグ内に高度なバリデーションロジックを直接定義できるようにすることで、複雑なOpenAPIスキーマを手動で記述するという手間がかかりエラーが発生しやすい作業を置き換えます。

カスタムバリデーション関数を記述する代わりに、Kubernetesコントリビューターは+k8s:minimumや+k8s:enumなどのIDLマーカーコメントを使用して、APIの型定義(types.go)内にバリデーションルールを直接定義できるようになりました。 validation-genツールはこれらのコメントを解析し、コンパイル時に堅牢なAPIバリデーションコードを自動生成します。 これにより、メンテナンスのオーバーヘッドが削減され、APIバリデーションがソースコードと一貫性を保ち同期された状態を維持できます。

この取り組みは、SIG API Machineryが主導したKEP #5073の一環として行われました。

Kubernetes API型からのgogo/protobuf依存関係の削除

Kubernetes v1.36では、gogoprotobufの削除が完了し、Kubernetesコードベースのセキュリティと長期的な保守性が大きく前進しました。 この取り組みにより、メンテナンスされていないgogoprotobufライブラリへの重大な依存関係が排除されました。 このライブラリは、潜在的なセキュリティ脆弱性の原因となり、最新のGo言語機能の採用を妨げる要因となっていました。

Kubernetes API型に互換性のリスクをもたらす標準的なProtobuf生成への移行ではなく、プロジェクトは必要な生成ロジックをk8s.io/code-generator内にフォークして内部化することを選択しました。 このアプローチにより、既存のAPIの動作とシリアライゼーションの互換性を維持しながら、Kubernetesの依存関係グラフからメンテナンスされていないランタイム依存関係を排除することに成功しました。 Kubernetes APIをGo言語で利用する開発者にとって、この変更は技術的負債を削減し、標準protobufライブラリとの誤った併用を防止します。

この取り組みは、SIG API Machineryが主導したKEP #5589の一環として行われました。

ノードログクエリ

以前は、Kubernetesではコントロールプレーンやワーカーノードに関連する問題のデバッグのために、クラスター管理者がSSH経由でノードにログインするか、クライアント側のリーダーを実装する必要がありました。 特定の問題では依然として直接のノードアクセスが必要ですが、kube-proxyやkubeletの問題はログを検査することで診断できます。 ノードログは、Podやコンテナのデバッグと同様に、kubelet APIとkubectlプラグインを使用してノードにログインせずにトラブルシューティングを簡素化する方法をクラスター管理者に提供します。 この方法はオペレーティングシステムに依存せず、サービスまたはノードが/var/logにログを出力する必要があります。

この機能は、本番ワークロードでの徹底的なパフォーマンス検証を経てKubernetes v1.36でGAに到達し、NodeLogQueryフィーチャーゲートを通じてkubeletでデフォルトで有効になっています。 さらに、enableSystemLogQuery kubelet設定オプションも有効にする必要があります。

この取り組みは、SIG Windowsが主導したKEP #2258の一環として行われました。

Podにおけるユーザー名前空間のサポート

Kubernetes v1.36では、ユーザー名前空間のサポートがGAに昇格し、コンテナの分離とノードセキュリティが主要な成熟度のマイルストーンに到達しました。 この待望の機能は、コンテナのrootユーザーをホスト上の非特権ユーザーにマッピングすることで多層防御の重要なレイヤーを提供し、プロセスがコンテナから脱出したとしても、基盤となるノードに対する管理権限を持たないことを保証します。

これにより、クラスターオペレーターはコンテナブレイクアウトの脆弱性の影響を軽減するため、本番ワークロードに対してこの堅牢な分離を安心して有効にできます。 コンテナの内部IDをホストのIDから切り離すことで、Kubernetesはマルチテナント環境と機密性の高いインフラストラクチャを不正アクセスから保護するための堅牢で標準化されたメカニズムを提供し、すべて長期的なAPIの安定性が完全に保証されています。

この取り組みは、SIG Nodeが主導したKEP #127の一環として行われました。

cgroupv2ベースのPSIサポート

Kubernetes v1.36では、Pressure Stall Information(PSI)メトリクスのエクスポートがGAに昇格し、ノードリソース管理と可観測性がより精密になりました。 この機能は、CPU、メモリ、I/Oの「圧力」メトリクスを報告する能力をkubeletに提供し、従来の使用率メトリクスよりもきめ細かなリソース競合のビューを提供します。

クラスターオペレーターとオートスケーラーは、これらのメトリクスを使用して、単に処理が集中しているシステムとリソース枯渇により実際にストールしているシステムを区別できます。 これらのシグナルを活用することで、ユーザーはPodのリソースリクエストをより正確に調整し、垂直オートスケーリングの信頼性を向上させ、アプリケーションのパフォーマンス低下やノードの不安定化につながる前にノイジーネイバー効果を検出できます。

この取り組みは、SIG Nodeが主導したKEP #4205の一環として行われました。

VolumeSource: OCIアーティファクトおよびイメージ

Kubernetes v1.36では、OCIボリュームソース サポートがGAに昇格し、コンテナデータの配布がより柔軟になりました。 この機能は、外部ストレージプロバイダーやConfigMapからボリュームをマウントするという従来の要件を超え、kubeletがコンテナイメージやアーティファクトリポジトリなどのOCI準拠のレジストリからコンテンツを直接取得してマウントできるようにします。

これにより、開発者やプラットフォームエンジニアはアプリケーションデータ、モデル、静的アセットをOCIアーティファクトとしてパッケージ化し、コンテナイメージに使用しているのと同じレジストリとバージョニングワークフローを使用してPodに配信できます。 このイメージとボリューム管理の統合により、CI/CDパイプラインが簡素化され、読み取り専用コンテンツのための専用ストレージバックエンドへの依存が軽減され、データがどの環境でも移植可能かつセキュアにアクセス可能な状態を維持できます。

この取り組みは、SIG Nodeが主導したKEP #4639の一環として行われました。

ベータの新機能

これはv1.36リリース後にベータとなった改善点の一部です。

コントローラーの陳腐化の軽減

Kubernetesコントローラーにおける陳腐化は、多くのコントローラーに影響を及ぼし、コントローラーの動作に微妙な影響を与える可能性がある問題です。 通常、コントローラーの作成者による何らかの前提に起因して陳腐化が問題であることが発見されるのは、本番環境のコントローラーがすでに誤ったアクションを実行してしまった後、手遅れになってからです。 これにより、キャッシュの陳腐化時にコントローラーの調整において、競合する更新やデータの破損が発生する可能性がありました。

Kubernetes v1.36には、コントローラーの陳腐化を軽減し、コントローラーの動作のより良い可観測性を提供する新機能が含まれていることをお知らせします。 これにより、しばしば有害な動作につながる可能性がある、古いクラスター状態のビューに基づく調整が防止されます。

この取り組みは、SIG API Machineryが主導したKEP #5647の一環として行われました。

IP/CIDRバリデーションの改善

Kubernetes v1.36では、APIのIPおよびCIDRフィールドに対するStrictIPCIDRValidation機能がベータに昇格し、以前はすり抜けていた不正なアドレスやプレフィックスを検出するためにバリデーションが強化されました。 これにより、Service、Pod、NetworkPolicy、またはその他のリソースが無効なIPを参照するという微妙な設定バグを防止でき、混乱するランタイム動作やセキュリティ上の問題を回避できます。

コントローラーは、オブジェクトに書き戻すIPを正規化し、すでに保存されている不正な値に遭遇した場合に警告を出すように更新されているため、クラスターは段階的にクリーンで一貫性のあるデータに収束できます。 ベータでは、StrictIPCIDRValidationはより広範な使用の準備が整い、ネットワークやポリシーが時間とともに進化する中で、オペレーターにIP関連の設定に対するより信頼性の高いガードレールを提供します。

この取り組みは、SIG Networkが主導したKEP #4858の一環として行われました。

kubectlユーザー設定のクラスター設定からの分離

kubectlのユーザー設定をカスタマイズするための.kuberc機能は引き続きベータであり、デフォルトで有効になっています。 ~/.kube/kubercファイルにより、ユーザーはクラスターのエンドポイントと認証情報を保持するkubeconfigファイルとは別に、エイリアス、デフォルトフラグ、その他の個人設定を保存できます。 この分離により、個人の設定がCIパイプラインや共有のkubeconfigファイルに干渉することを防ぎ、異なるクラスターやコンテキスト間で一貫したkubectlエクスペリエンスを維持できます。

Kubernetes v1.36では、.kubercに認証情報プラグインのポリシー(許可リストまたは拒否リスト)を定義する機能が追加され、より安全な認証プラクティスが強制されるようになりました。 必要に応じて、環境変数KUBECTL_KUBERC=falseまたはKUBERC=offを設定することでこの機能を無効にできます。

この取り組みは、SIG CLIが主導し、SIG Authの協力を得たKEP #3104の一環として行われました。

Job一時停止時の変更可能なコンテナリソース

Kubernetes v1.36では、MutablePodResourcesForSuspendedJobs機能がベータに昇格し、デフォルトで有効になりました。 この更新により、Jobのバリデーションが緩和され、Jobが一時停止中にコンテナのCPU、メモリ、GPU、および拡張リソースのリクエストと制限を更新できるようになりました。

この機能により、キューコントローラーやオペレーターはリアルタイムのクラスター条件に基づいてバッチワークロードの要件を調整できます。 例えば、キューイングシステムは受信したJobを一時停止し、利用可能な容量やクォータに合わせてリソース要件を調整してから、一時停止を解除できます。 この機能は、変更可能性を一時停止中のJob(または一時停止時にPodが終了されたJob)に厳密に制限し、アクティブに実行中のPodへの破壊的な変更を防止します。

この取り組みは、SIG Appsが主導したKEP #5440の一環として行われました。

制約付きなりすまし

Kubernetes v1.36では、ユーザーなりすましのConstrainedImpersonation機能がベータに昇格し、歴史的にオール・オア・ナッシングだったメカニズムを、実際に最小権限の原則に沿うものへと強化しています。 この機能が有効な場合、なりすましを行うユーザーは2つの異なる権限セットを持つ必要があります。1つは特定のアイデンティティになりすますための権限、もう1つはそのアイデンティティに代わって特定のアクションを実行するための権限です。 これにより、なりすましのRBACが誤って設定されている場合でも、サポートツール、コントローラー、またはノードエージェントがなりすましを使用して自身に許可されている以上のアクセス権を取得することを防止します。 既存のimpersonateルールは引き続き機能しますが、APIサーバーは新しい制約付きチェックを優先するため、移行は一斉切り替えではなく段階的に行われます。 v1.36のベータでは、ConstrainedImpersonationはテスト済みでドキュメント化されており、デバッグ、プロキシ、またはノードレベルのコントローラーにおいてなりすましに依存するプラットフォームチームによるより広範な採用の準備が整っています。

この取り組みは、SIG Authが主導したKEP #5284の一環として行われました。

ベータのDRA機能

Dynamic Resource Allocation(DRA)フレームワークは、Kubernetes v1.36で複数のコア機能がベータに昇格しデフォルトで有効になることで、さらなる成熟度のマイルストーンに到達しました。 この移行により、パーティション可能なデバイスとConsumable Capacityの昇格によってGPUなどのハードウェアのよりきめ細かな共有が可能になり、DRAは基本的な割り当てを超えて進化しています。 一方、デバイスのTaintとTolerationにより、専用リソースが適切なワークロードによってのみ使用されることが保証されます。

これにより、ユーザーはResourceClaimデバイスステータスとPodスケジューリング前のデバイスアタッチメントの保証を通じて、はるかに信頼性が高く可観測性の高いリソースライフサイクルの恩恵を受けられます。 これらの機能を拡張リソースサポートと統合することで、Kubernetesはレガシーなデバイスプラグインシステムに代わる堅牢な本番対応の代替手段を提供し、複雑なAIおよびHPCワークロードが前例のない精度と運用安全性でハードウェアを管理できるようにします。

この取り組みは、SIG SchedulingとSIG Nodeが主導した複数のKEP(#5004、#4817、#5055、#5075、#4815、#5007を含む)の一環として行われました。

KubernetesコンポーネントのStatusz

Kubernetes v1.36では、コアKubernetesコンポーネントのComponentStatuszフィーチャーゲートがベータに昇格し、各コンポーネントのリアルタイムのビルドおよびバージョン詳細を表示する/statuszエンドポイント(デフォルトで有効)が提供されます。 このオーバーヘッドの低いz-pageは、起動時刻、稼働時間、Goバージョン、バイナリバージョン、エミュレーションバージョン、最小互換バージョンなどの情報を公開し、オペレーターや開発者がログや設定を掘り下げることなく、実行中のものを正確に確認できるようにします。

エンドポイントはデフォルトで人間が読めるテキストビューを提供し、さらに明示的なコンテンツネゴシエーションを介してJSON、YAML、またはCBORでのプログラムアクセス用のバージョン管理された構造化API(config.k8s.io/v1beta1)も提供します。 アクセスはsystem:monitoringグループに付与され、ヘルスおよびメトリクスエンドポイントの既存の保護と整合し、機密データの露出を防止します。

ベータでは、ComponentStatuszはすべてのコアコントロールプレーンコンポーネントおよびノードエージェントでデフォルトで有効になり、ユニットテスト、統合テスト、E2Eテストにより本番環境での可観測性およびデバッグワークフローに安全に使用できます。

この取り組みは、SIG Instrumentationが主導したKEP #4827の一環として行われました。

KubernetesコンポーネントのFlagz

Kubernetes v1.36では、コアKubernetesコンポーネントのComponentFlagzフィーチャーゲートがベータに昇格し、各コンポーネントが起動時に指定された有効なコマンドラインフラグを公開する/flagzエンドポイントが標準化されました。 これにより、クラスターオペレーターと開発者はコンポーネントの設定をクラスター内でリアルタイムに確認できるようになり、予期しない動作のデバッグや、フラグのロールアウトが再起動後に実際に反映されたかの確認が、はるかに容易になります。

エンドポイントは人間が読めるテキストビューとバージョン管理された構造化API(当初はconfig.k8s.io/v1beta1)の両方をサポートしているため、インシデント中にcurlで確認することも、準備ができたら自動化ツールに組み込むこともできます。 アクセスはsystem:monitoringグループに付与され、機密値はマスクできるため、設定の可視化はヘルスおよびステータスエンドポイント周辺の既存のセキュリティプラクティスと整合しています。

ベータでは、ComponentFlagzはデフォルトで有効になり、すべてのコアコントロールプレーンコンポーネントおよびノードエージェントに実装され、ユニットテスト、統合テスト、E2Eテストにより本番クラスターでのエンドポイントの信頼性が確保されています。

この取り組みは、SIG Instrumentationが主導したKEP #4828の一環として行われました。

Mixed Versionプロキシ (別名: バージョン間相互運用プロキシ)

Kubernetes v1.36では、Mixed Versionプロキシ機能がベータに昇格し、v1.28でのアルファ導入を基に、混合バージョンクラスターに対してより安全なコントロールプレーンのアップグレードを提供します。 各APIリクエストは、リクエストされたグループ、バージョン、リソースを提供するapiserverインスタンスにルーティングできるようになり、バージョンの差異による404エラーや障害が軽減されます。

この機能はピア集約ディスカバリに依存しているため、apiserverはどのリソースとバージョンを公開しているかに関する情報を共有し、そのデータを使用して必要に応じてリクエストを透過的に再ルーティングします。 再ルーティングされたトラフィックとプロキシ動作に関する新しいメトリクスにより、オペレーターはリクエストが転送される頻度と転送先のピアを把握できます。 これらの変更により、マルチステップまたは部分的なコントロールプレーンのアップグレードを実行しながら、高可用性の混合バージョンAPIコントロールプレーンを本番環境で実行することがより容易になります。

この取り組みは、SIG API Machineryが主導したKEP #4020の一環として行われました。

cgroups v2によるメモリQoS

Kubernetesは、よりスマートで階層化されたメモリ保護により、Linux cgroup v2ノードでのメモリQoSを強化しました。 カーネルのコントロールをPodのリクエストと制限により適切に整合させ、同じノードを共有するワークロード間の干渉とスラッシングを軽減します。 このイテレーションでは、kubeletがmemory.highとmemory.minをプログラムする方法も改善され、ライブロックを回避するためのメトリクスとセーフガードが追加され、クラスターオペレーターが環境に合わせてメモリ保護の動作を調整できる設定オプションが導入されました。

この取り組みは、SIG Nodeが主導したKEP #2570の一環として行われました。

アルファの新機能

これはv1.36リリース後にアルファとなった改善点の一部です。

カスタムメトリクスに対するHPAのゼロへのスケール

これまでHorizontalPodAutoscaler(HPA)は、実行中のPodからのメトリクス(CPUやメモリなど)に基づいてのみスケーリングの必要性を計算できたため、最低1つのレプリカをアクティブに保つ必要がありました。 Kubernetes v1.36では、ObjectまたはExternalメトリクスを使用する場合に限り、ワークロードをゼロレプリカにスケールダウンできるようにするHPAのゼロへのスケール機能(デフォルトで無効)のアルファでの開発を継続しています。

ユーザーは、保留中のタスクがない場合にリソースを大量に消費するワークロードを完全にアイドル状態にすることで、インフラストラクチャのコストの大幅な削減を試せるようになります。 この機能はHPAScaleToZeroフィーチャーゲートの背後に残っていますが、ゼロの実行中PodでもHPAをアクティブに維持し、外部メトリクス(例: キューの長さ)が新しいタスクの到着を示すとすぐにDeploymentを自動的にスケールアップします。

この取り組みは、SIG Autoscalingが主導したKEP #2021の一環として行われました。

アルファのDRA機能

従来、Dynamic Resource Allocation(DRA)フレームワークは、高レベルのコントローラーとのシームレスな統合が欠如しており、デバイス固有のメタデータや可用性を把握する手段が限られていました。 Kubernetes v1.36では、ワークロード向けのネイティブResourceClaimサポートや、CPU管理にDRAの柔軟性を提供するDRAネイティブリソースなど、一連のDRA強化機能をアルファとして導入しています。

ユーザーはDownward APIを活用して、複雑なリソース属性をコンテナに直接公開できるようになりました。 これにより、リソースの可用性をより正確に把握でき、スケジューリングの予測可能性も向上します。 これらのアップデートは、デバイス属性におけるリスト型のサポートと組み合わさり、DRAを低レベルのプリミティブから、現代のAIおよびハイパフォーマンスコンピューティング(HPC)スタックの高度なネットワーキングとコンピューティング要件を処理できる堅牢なシステムへと変革します。

この取り組みは、SIG SchedulingとSIG Nodeが主導した複数のKEP(#5729、#5304、#5517、#5677、#5491を含む)にわたって行われました。

Kubernetesメトリクスのネイティブヒストグラムサポート

Kubernetes v1.36では、アルファとしてネイティブヒストグラムサポートが導入され、高解像度モニタリングが新たなマイルストーンに到達しました。 従来のPrometheusヒストグラムは事前定義された固定的なバケットに依存しており、データの精度とメモリ使用量の間でトレードオフを強いられることがしばしばありました。 今回のアップデートにより、コントロールプレーンはリアルタイムのデータに基づいて解像度を動的に調整するスパースヒストグラムをエクスポートできるようになります。

クラスターオペレーターは、手動のバケット管理のオーバーヘッドなしに、kube-apiserverやその他のコアコンポーネントの正確なレイテンシ分布をキャプチャできるようになりました。 このアーキテクチャの転換により、より信頼性の高いSLIとSLOを実現でき、予測の難しいワークロードのスパイク時でも精度を保つことが可能な高精度なヒートマップが利用可能になります。

この取り組みは、SIG Instrumentationが主導したKEP #5808の一環として行われました。

マニフェストベースのAdmission Control設定

Kubernetes v1.36では、アルファとしてマニフェストベースのAdmission Control設定が導入され、Admissionコントローラーの管理がより宣言的で一貫性のあるモデルに移行しました。 この変更は、管理者がAdmission Controlの望ましい状態を構造化されたマニフェストを通じて直接定義できるようにすることで、異なるコマンドラインフラグや個別の複雑な設定ファイルを通じてAdmissionプラグインを設定するという長年の課題に対処しています。

クラスターオペレーターは、他のKubernetesオブジェクトに使用されるのと同じバージョン管理された宣言的ワークフローでAdmissionプラグインの設定を管理できるようになり、クラスターアップグレード中の設定のドリフトや手動エラーのリスクが大幅に軽減されます。 これらの設定を統一されたマニフェストに集約することで、kube-apiserverの監査と自動化が容易になり、より安全で再現可能なクラスターデプロイメントへの道が開かれます。

この取り組みは、SIG API Machineryが主導したKEP #5793の一環として行われました。

CRIリストストリーミング

Kubernetes v1.36では、アルファとしてCRIリストストリーミングが導入され、新しい内部ストリーミング操作を使用するようになりました。 この改善は、kubeletとコンテナランタイム間の従来のモノリシックなListリクエストを、より効率的なサーバーサイドストリーミングRPCに置き換えることで、大規模ノードでよく見られるメモリ圧迫とレイテンシスパイクに対処しています。

すべてのコンテナまたはイメージデータを含む単一の大きなレスポンスを待つ代わりに、kubeletはストリーミングされた結果をインクリメンタルに処理できるようになりました。 この移行により、kubeletのピークメモリフットプリントが大幅に削減され、高密度ノードでの応答性が向上し、ノードあたりのコンテナ数が増え続けても流動的なクラスター管理が確保されます。

この取り組みは、SIG Nodeが主導したKEP #5825の一環として行われました。

その他の注目すべき変更点

Ingress NGINXの引退

エコシステムの安全性とセキュリティを優先するため、Kubernetes SIG NetworkとSecurity Response Committeeは2026年3月24日にIngress NGINXを引退させました。 この日以降、新たなリリース、バグ修正、発見されたセキュリティ脆弱性を解決するためのアップデートは行われません。 Ingress NGINXの既存のデプロイメントは引き続き機能し、Helmチャートやコンテナイメージなどのインストールアーティファクトは引き続き利用可能です。

詳細については公式の引退アナウンスをご覧ください。

ボリュームに対するSELinuxラベリングの高速化(GA)

Kubernetes v1.36では、SELinuxボリュームマウントの改善がGAに昇格しました。 この変更は、再帰的なファイルのラベル再設定をmount -o context=XYZオプションに置き換え、マウント時にボリューム全体に正しいSELinuxラベルを適用します。 これにより、より一貫したパフォーマンスが実現し、SELinuxが有効なシステムでのPod起動時の遅延が軽減されます。

この機能はv1.28でReadWriteOncePodボリュームに対するベータとして導入されました。 v1.32では、メトリクスと競合を検出するためのオプトアウトオプション(securityContext.seLinuxChangePolicy: Recursive)が追加されました。 v1.36では安定版に到達し、すべてのボリュームにデフォルトで適用され、PodまたはCSIDriverがspec.seLinuxMountを介してオプトインします。

ただし、この機能は将来のKubernetesリリースで破壊的変更のリスクを生み出す可能性があります。 これは、同じノード上で特権Podと非特権Podの間で1つのボリュームを共有する場合に発生する可能性があります。

開発者はPodにseLinuxChangePolicyフィールドとSELinuxボリュームラベルを設定する責任があります。 Deployment、StatefulSet、DaemonSet、またはPodテンプレートを含むカスタムリソースのいずれを作成する場合でも、これらの設定を慎重に行わないと、Podがボリュームを共有する際にPodが正しく起動しないなどの様々な問題が発生する可能性があります。

Kubernetes v1.36はクラスターを監査するのに最適なリリースです。 詳細についてはSELinux Volume Label Changes goes GA (and likely implications in v1.37)のブログ記事をご覧ください。

この機能強化の詳細については、KEP-1710: Speed up recursive SELinux label changeをご参照ください。

v1.36での昇格、非推奨、削除

GAへの昇格

これは安定版(一般提供、GAとも呼ばれる)に昇格したすべての機能を一覧にしたものです。 アルファからベータへの昇格や新機能を含む更新の完全なリストについては、リリースノートをご覧ください。

このリリースには、GAに昇格した合計18の機能強化が含まれています:

非推奨、削除、コミュニティの更新

Kubernetesの開発と成熟に伴い、プロジェクト全体の健全性を向上させるために、機能が非推奨になったり、削除されたり、より良いものに置き換えられたりすることがあります。 このプロセスの詳細については、Kubernetesの非推奨と削除のポリシーをご覧ください。 Kubernetes v1.36にはいくつかの非推奨が含まれています。

Serviceの.spec.externalIPsの非推奨化

このリリースでは、Service specのexternalIPsフィールドが非推奨になりました。 これは、機能自体は存在しますが、Kubernetesの将来のバージョンでは機能しなくなることを意味します。 このフィールドに依存している場合は、移行を計画する必要があります。 このフィールドは長年にわたりセキュリティ上の既知の問題であり、CVE-2020-8554に記載されているように、クラスタートラフィックに対する中間者攻撃を可能にしていました。 Kubernetes v1.36以降、使用時に非推奨の警告が表示され、v1.43での完全な削除が計画されています。

ServiceがまだexternalIPsに依存している場合は、クラウドマネージドのIngressにはLoadBalancer Service、シンプルなポート公開にはNodePort、外部トラフィックをより柔軟かつ安全に処理するにはGateway APIの使用を検討してください。

このフィールドとその非推奨化の詳細については、External IPsまたはKEP-5707: Deprecate service.spec.externalIPsをご参照ください。

gitRepoボリュームドライバーの削除

gitRepoボリュームタイプはv1.11以降非推奨となっていました。 Kubernetes v1.36では、gitRepoボリュームプラグインが恒久的に無効化され、再度有効にすることはできません。 この変更は、gitRepoの使用により攻撃者がノード上でrootとしてコードを実行できるという重大なセキュリティの問題からクラスターを保護します。

gitRepoは長年にわたり非推奨であり、より良い代替手段が推奨されてきましたが、以前のリリースでは技術的にはまだ使用可能でした。 v1.36以降、その経路は完全に閉鎖されたため、gitRepoに依存している既存のワークロードは、Initコンテナや外部のgit-syncスタイルのツールなどのサポートされているアプローチに移行する必要があります。

この削除の詳細については、KEP-5040: Remove gitRepo volume driverをご参照ください。

リリースノート

Kubernetes v1.36リリースの詳細については、リリースノートをご覧ください。

入手方法

Kubernetes v1.36はGitHubまたはKubernetes公式サイトのダウンロードページからダウンロードできます。

Kubernetesを始めるには、インタラクティブチュートリアルをチェックするか、minikubeを使用してローカルKubernetesクラスターを実行してください。 また、kubeadmを使用して簡単にv1.36をインストールすることもできます。

リリースチーム

Kubernetesは、コミュニティの支援、コミットメント、献身的な努力なくしては成り立ちません。 各リリースチームは、皆さんが利用するKubernetesリリースを構成する様々な要素を協力して構築する、献身的なコミュニティボランティアで構成されています。 これを実現するには、コードそのものからドキュメント作成、プロジェクト管理に至るまで、コミュニティのあらゆる分野の専門スキルが必要です。

Kubernetes v1.36リリースをコミュニティに届けるために多くの時間を費やして取り組んでくれたリリースチーム全体に感謝します。 リリースチームには、初参加のShadow(見習い)から、複数のリリースサイクルで経験を積んだベテランのチームリードまで、様々なメンバーが参加しています。 リリースリードのRyota Sawadaに心より感謝します。 彼の実践的な課題解決のアプローチと、コミュニティを前進させる活力と情熱で、成功したリリースサイクルを導いてくれました。

プロジェクトの活動状況

CNCF K8sのDevStatsプロジェクトは、Kubernetesおよび様々なサブプロジェクトの活動状況に関する興味深いデータポイントを集計しています。 これには個人の貢献から貢献企業数まで含まれ、このエコシステムの発展に費やされる努力の深さと広さを示しています。

v1.36リリースサイクル(2026年1月12日から2026年4月22日までの15週間)において、Kubernetesには最大106の異なる企業と491人の個人から貢献がありました。 より広範なクラウドネイティブエコシステムでは、この数字は370社、合計2235人のコントリビューターに達しています。

なお、「貢献」とはコミットの作成、コードレビュー、コメント、IssueやPRの作成、PRのレビュー(ブログやドキュメントを含む)、またはIssueやPRへのコメントを行うことを指します。 貢献に興味がある場合は、コントリビューター向けWebサイトのはじめにをご覧ください。

データソース:

イベント情報

今後開催予定のKubernetesおよびクラウドネイティブイベント(KubeCon + CloudNativeCon、KCDなど)や、世界各地で開催される主要なカンファレンスについて紹介します。 Kubernetesコミュニティの最新情報を入手し、参加しましょう！

2026年4月

2026年5月

2026年6月

2026年7月

2026年9月

2026年10月

2026年11月

最新のイベント情報はこちらでご確認いただけます。

ウェビナーのご案内

Kubernetes v1.36リリースチームのメンバーと一緒に 2026年5月20日(水)午後4時(UTC) から、このリリースのハイライトについて学びましょう。 詳細および参加登録は、CNCFオンラインプログラム・サイトのイベントページをご覧ください。

参加方法

Kubernetesに関わる最も簡単な方法は、あなたの興味に合ったSpecial Interest Groups(SIGs)のいずれかに参加することです。 Kubernetesコミュニティに向けて何か発信したいことはありますか？ 毎週のコミュニティミーティングや、以下のチャンネルであなたの声を共有してください。 継続的なフィードバックとサポートに感謝いたします。

  • 最新情報はBlueskyの@kubernetes.ioをフォローしてください
  • Discussでコミュニティディスカッションに参加してください
  • Slackでコミュニティに参加してください
  • Stack Overflowで質問したり、回答したりしてください
  • あなたのKubernetesに関するストーリーを共有してください
  • Kubernetesの最新情報はブログでさらに詳しく読むことができます
  • リリースチームについての詳細はKubernetes Release Teamをご覧ください