Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor 著 | 2026年7月31日（金）

Kubernetes v1.37 のリリース日が近づくにつれ、プロジェクトは開発・成熟を続け、プロジェクト全体の健全性のため、機能の非推奨化、削除、またはより良い機能への置き換えが行われる可能性があります。このブログでは、Kubernetes v1.37 リリースに向けた計画的な変更のうち、リリースチームが Kubernetes 環境の継続的なメンテナンスと最新の変更への追随のために知っておくべきものを概説します。以下に示す情報は v1.37 リリースの現在の状況を反映しており、実際のリリース日までに変更される可能性があります。

Kubernetes v1.37 の非推奨化と削除

Kubectl: kubectl run --filename/-f の非推奨化

kubectl run の --filename（または -f）フラグが非推奨化されます。これは、生成される Pod が常に NAME や --image などの CLI 引数のみから構築されるためです。

元のイシューおよび議論については kubernetes/kubernetes#138671 を参照してください。

Kubelet: Static Pod が Secret または ConfigMap を参照できなくなる

Static Pod は API サーバーを介して作成されないため、API リソースを直接読み取ることを想定していません。しかしバグにより、configMapRef や secretRef などのフィールドで Secret や ConfigMap を参照できました。このバグは修正され、v1.37 以降はこれらの参照が厳格に禁止されます。以前は制限をオプトアウト可能だった PreventStaticPodAPIReferences フィーチャーゲートも削除されました。

元のイシューおよび議論については kubernetes/kubernetes#140226 を参照してください。

kube-proxy の ipvs モードサポートの非推奨化

kube-proxy の ipvs モードサポートは、iptables のパフォーマンスボトルネックを解消するために v1.8 で導入されました。しかし、カーネルの ipvs API だけでは Kubernetes Service を完全に実装できないため、ipvs モードは引き続き iptables を使用します（KEP-3866、「The ipvs mode of kube-proxy will not save us」）。

kube-proxy を ipvs モード（または KubeProxyConfiguration の mode: ipvs）で実行しているクラスターは、起動時に非推奨警告をログ出力するようになります。非推奨化のタイムラインは以下の通りです。

  • v1.40 までに、kube-proxy の ipvs モードはデフォルトで無効化される予定（フィーチャーゲート経由で選択可能）
  • v1.43 までに、ipvs モードのサポートは完全に削除される予定 KEP-5495、Graduation Criteria。 現在のモードを確認するには以下を実行します。
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

この非推奨化の背景については KEP-5495: Deprecate ipvs mode in kube-proxy を参照してください。

進行中の主要な変更

cgroup v1 サポートの将来的な削除

最新の Linux ディストリビューションやコンテナランタイムが cgroup v2 をデフォルトで使用する中、レガシーな cgroup v1 のサポートは公式に段階的に廃止されています。v1.35 リリース以降、failCgroupV1 設定はデフォルトで true となっています。そのため、cgroup v1 に依存するノードでは、明示的な設定上書きを適用しない限り、kubelet の初期化に失敗します。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # temporary override

この上書きは短期的な対策とみなすべきです。In-Place Pod Resizing や Tiered Memory Protection などの高度なリソース管理機能は、cgroup v2 に完全に依存しています。この上書きは Kubernetes v1.37 でも利用可能ですが、cgroup v1 のサポートは将来のリリースで削除される予定のため、cgroup v2 への移行を推奨します。

この非推奨化の詳細については KEP-5573: Remove cgroup v1 support を参照してください。

Kubernetes v1.37 の破壊的変更

SELinux ボリューム再ラベル付け（「SELinuxMount」）の GA 昇格

SELinuxMount は v1.37 で GA に到達し、デフォルトで有効化される予定です。ボリュームは再帰的な再ラベル付けではなく、-o context=<label>（マウントオプションのデフォルト）でマウントされます。ただし、CSIDriver の .spec seLinuxMount: true を設定してオプトインした CSI ドライバーの場合に限ります。

1 つのマウントは 1 つの SELinux コンテキストしか保持できないため、同じノード上で異なる SELinux ラベルを持つ Pod がボリュームを共有する場合（以前は再帰的な再ラベル付けで共存可能でした）、Pod の起動に失敗する可能性があります。特定のワークロードで以前の再帰的動作を維持するには、Pod spec に seLinuxChangePolicy: Recursive を設定します。

SELinux が有効化されていないクラスターには影響はありません。詳細については SELinux Volume Label Changes goes GA (and likely implications in v1.37) を参照してください。

Kubernetes v1.37 の注目機能

Metrics API の GA 昇格

metrics.k8s.io API は、約 9 年間 Beta 版であった後、Kubernetes v1.37 で Stable（GA）に昇格する予定です。この API は Pod や Node の CPU・メモリ使用量を取得する標準的な方法を提供し、Horizontal Pod Autoscaler（HPA）や kubectl top などの広く使われている Kubernetes 機能を支えています。

この GA 昇格は API の安定性と広範な採用を認識するもので、機能的な変更は予定されていません。v1 と v1beta1 は移行期間中も利用可能であり、開発者は既存のワークフローを破壊することなく、独自のペースで安定版 API を採用できます。

この機能強化の詳細については KEP-5207: metrics.k8s.io API definition を参照してください。

UserNS での Kubelet（別名 Rootless Mode）

従来、Kubernetes のノードコンポーネント（kubelet など）はホスト上で root 権限で実行されます。これは多くのデプロイメントで必要ですが、これらのコンポーネントの脆弱性が基盤システムに大きな影響を与える可能性もあります。

Kubernetes v1.37 では、User Namespace での Kubelet（Rootless Mode）が Beta に昇格する予定です。この機能により、Kubernetes ノードコンポーネントを Linux ユーザーネームスペース内で非特権ユーザーとしてホスト上で実行しつつ、ネームスペース内では root として動作させることができます。ホストレベルの root 権限の必要性を減らすことで、追加の隔離レイヤーを提供し、ノードコンポーネントに影響する潜在的な脆弱性の影響を制限します。

この機能強化の詳細については KEP-2033: Kubelet in UserNS(aka Rootless Mode) を参照してください。

ボリュームヘルスモニター

従来、Kubernetes には CSI ドライバーがストレージ障害を報告するための API がなく、マウント失敗や I/O ハングを通じてのみ明らかになっていました。修復コントローラーには機械可読な情報がなかったため、障害の根本原因を特定するには Kubernetes オブジェクトと外部ベンダーダッシュボードを相互参照するしかありませんでした。

Kubernetes v1.37 では、この KEP は v1.21 での初期実装後に卒業を Alpha にリセットし、4 つの新しい CSI RPC を導入します。コントローラープラグインは ControllerListVolumeHealth（異常なボリュームを一覧表示）および ControllerGetVolumeHealth（特定のボリュームをチェック）を使用してストレージボリュームの健全性を報告します。コントローラー側のヘルスモニターはこれらの CSI コントローラーをポーリングし、結果を PersistentVolumeClaim.status.healthStatus に保存します。

ノード側では、kubelet が NodeGetVolumeHealth を呼び出してそのノード上の個々のボリュームの健全性を取得し、Pod.status.volumeHealth に記録します。また、NodeGetStorageHealth はノードに登録されたドライバーの健全性を CSINode.status.storageHealth に報告します。

エラー語彙はシンプルで拡張可能、機械解析可能なもの（Inaccessible、Degraded など）に保たれ、reason や message を介してドライバー固有の詳細を追加できます。最後に、コントローラー側とノード側のレポートは独立しており、別々に表示されるため、ストレージ健全性の全体像を消費者に提供します。

この機能強化の詳細については KEP-1432: Volume Health Monitor を参照してください。

さらに詳しく知るには？

新機能や非推奨化は Kubernetes リリースノートでも発表されます。Kubernetes v1.37 の新機能は、該当リリースの CHANGELOG の一部として正式に発表されます。

Kubernetes v1.37 リリースは 2026年8月26日（水） に予定されています。最新情報にご注目ください！

変更の発表は以下のリリースノートで確認できます。

参加するには

Kubernetes に参加する最も簡単な方法は、自身の関心に合った Special Interest Groups（SIGs）に参加することです。

どこから始めればよいかわからない場合は、毎月の New Contributor Orientations に参加してください。プロジェクトの構造を学び、プロジェクトへの最初の貢献方法を案内します。