2026.10.12 Kubernetes・コンテナ

Kubernetes 1.37の新機能｜注目機能の要点とkindで試す機能ゲート設定

Kubernetes 1.37は2026年8月26日に公開され、コードネームはインド・ヒマラヤの地名にちなむ「Garhwal」です。変更は67件あり、HPAのゼロスケールが既定で有効になったこと、約9年Betaだったmetrics.k8s.io APIがStableへ上がったこと、ノードコンポーネントを非rootで動かすRootlessモードがBetaになったことが実務への影響の大きい変更です。本記事では1.37の新機能を、手元のkindクラスタで試すコマンドと設定ファイルつきで整理し、本番へ入れる順番と、まだ有効にしないほうがよい機能を判断できる形にまとめます。版番号と日付は2026年10月12日時点で一次情報を確認したものです。

まとめ：Kubernetes 1.37で試すべき新機能と本番投入の順番

規模：67件の変更のうちStable 16件、Beta 23件、Alpha 27件、非推奨・削除1件。最新パッチは1.37.1（2026-09-15）、サポート終了は2027-10-28です。
最初に試す：kind v0.33.0の既定ノードイメージがv1.37.0なので、kind create clusterだけで検証環境が立ちます。既定で無効な機能は設定ファイルのfeatureGatesで有効化します。
すぐ使える：HPAのゼロスケール（Beta・既定有効）は外部指標かオブジェクト指標を使うキュー処理やバッチで効きます。CPU・メモリ指標では使えません。
上げる前に確認：SELinuxMountの既定有効化、Memory QoSの既定有効化、kube-proxyのipvsモード非推奨の3点は、何もしなくても挙動や警告が変わります。
見送る：Pod単位のチェックポイント、StatefulSetのRecreate戦略などAlpha機能は、検証クラスタで触るにとどめ本番では有効にしません。

どの版が最新か、使用中クラスタの版をどう確かめるか、EOL一覧とアップグレード手順はKubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順にまとめています。本記事は「1.37で何が増え、どう試すか」に絞ります。

Kubernetes 1.37 Garhwalのリリース概要と67件の変更内訳

1.37のリリースサイクルは2026年5月18日から8月26日までの15週間で、212社・1,754人が貢献したと公式リリースブログ（Kubernetes v1.37: Garhwal）に記されています。日本語で読みたい場合は公式ブログの日本語訳も公開されています。

1.37のリリース日とサポート期限・1.37.1パッチの提供状況（2026年10月時点）

公式のReleasesページでは、1.37の最新パッチは1.37.1（2026-09-15リリース）、End of Lifeは2027-10-28と掲載されています。保守対象は1.37・1.36・1.35の3系統で、1.34は2026-10-27にEOLを迎えます。

1.34系を運用している場合、残り期間は2週間ほどしかありません。1.34で入った変更はKubernetes 1.34の変更点とEOL、1.35の機能はKubernetes 1.35の新機能と変更点で扱っています。複数マイナー版をまたぐ場合は、間の版の変更も読んでから計画を立ててください。

Stable16件・Beta23件・Alpha27件の内訳と既定で有効な機能

新機能を読むときに見るべきは段階より「既定で有効かどうか」です。Betaでも既定無効のものが混ざっています。実務で影響の出やすい機能を既定値で並べると次のとおりです。

機能	段階	既定
HPAのゼロスケール	Beta	有効
Memory QoS	Beta	有効
Rootlessモード	Beta	有効
PVCの未使用時刻	Beta	有効
etcdのRangeStream	Beta	有効
Pod単位のリソース管理	Beta	無効
CRI経由のPod統計	Beta	無効
StatefulSetのRecreate	Alpha	無効
SELinuxマウント	Stable	有効

機能ゲート名と版ごとの既定値はFeature Gatesの公式リファレンスで引けます。表の「有効」は、アップグレードしただけで挙動が変わりうるという意味です。

kindでKubernetes 1.37の検証クラスタを起動して新機能を試す手順

新機能を本番で初めて触るのは避けます。Docker上にクラスタを作るkindなら、1.37を数分で用意でき、機能ゲートも設定ファイルで切り替えられます。

kind v0.33.0の既定イメージv1.37.0で検証クラスタを起動するコマンド

kind v0.33.0のリリースノート（2026-08-26公開）では、既定のノードイメージがkindest/node:v1.37.0です。イメージ指定なしでも1.37が起動しますが、チームで揃えるなら明示しておくと版ずれが起きません。

# kind のバージョン確認（v0.33.0 以上）
kind version

# 1.37 の検証クラスタを作成
kind create cluster --name k137 --image kindest/node:v1.37.0

# サーバー側の版を確認
kubectl version
kubectl get nodes -o wide

別のパッチ版を使うときは、kindのリリースノートに載ったイメージを指定します。ノートに無いタグを推測で書くとpullに失敗します。

既定で無効なBeta機能をkindのfeatureGatesで有効化する設定ファイル

既定無効のBetaやAlphaを試すには、kindの設定ドキュメントにあるfeatureGatesキーを使います。ここに書いたゲートはクラスタ内の全コンポーネントに一括で渡ります。

# kind-k137.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  "PodLevelResourceManagers": true
  "StatefulSetRecreateStrategy": true
nodes:
- role: control-plane
- role: worker

kind create cluster --name k137-gates --image kindest/node:v1.37.0 --config kind-k137.yaml

ゲートを有効にしただけでは、Pod単位のリソース管理の効果は見えません。割り当てを確かめるにはkubelet側のCPUマネージャ等のポリシー設定も要ります。

HPAのゼロスケールを外部メトリクスで動かすマニフェストと前提条件

1.37で一番すぐ効く変更がこれです。HPAのゼロスケールはv1.16でAlphaとして入ってから長く既定無効でしたが、1.37でBetaになり既定で有効になりました（KEP-2021）。

minReplicas 0を書ける指標の条件とCPU・メモリ指標で使えない理由

spec.minReplicas: 0が意味を持つのは、Objectメトリクスか Externalメトリクスで伸縮するHPAだけです。CPUとメモリの使用率は動いているPodから計測する値なので、Podがゼロになると計測元そのものが消え、復帰の判断ができません。キューの滞留件数のように、Podの外側に数値があるワークロードが対象です。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages_ready
        selector:
          matchLabels:
            queue: jobs
      target:
        type: AverageValue
        averageValue: "30"

External指標をHPAへ渡すには、external.metrics.k8s.ioを提供するアダプタ（Prometheus AdapterやKEDAなど）が別途必要です。指標名queue_messages_readyはアダプタ側の定義に合わせて書き換えます。HPA全体の仕様はHorizontal Pod Autoscalingの公式ドキュメントが基準になります。

ScaledToZero条件で自動のゼロ化と手動停止を見分ける確認コマンド

HPAがワークロードをゼロに保っている間、ステータスにScaledToZero条件がTrueで記録されます。人がレプリカ数を0にして止めたものと区別するための印で、再びスケールアウトするとFalse、理由はNotScaledToZeroに変わります。

kubectl get hpa queue-worker \
  -o jsonpath='{.status.conditions[?(@.type=="ScaledToZero")]}{"\n"}'

詰まりやすいのは監視側です。レプリカ数0を「停止」としてアラートにしていると、ゼロ化のたびに通知が飛びます。この条件の値を見て、HPAが意図して止めたものは除外してください。

Stableに昇格したKYAML・metrics.k8s.io・Pod証明書の実務影響

ここで挙げる3つは既存のマニフェストを壊しませんが、ツールや運用手順の側で扱いを決めておきます。

KYAMLとmetrics.k8s.io v1の安定化で利用者側が見直す2つの点

KYAMLはKubernetes向けに曖昧さを減らしたYAMLのサブセットで、1.34でAlpha、1.35でBetaを経て1.37でStableになりました（KEP-5295）。KYAMLは正しいYAMLでもあるため、既存のマニフェストを書き換える必要はなく、出力形式が1つ増えたと捉えれば足ります。

kubectl get deployment queue-worker -o kyaml

もう一つはmetrics.k8s.ioです（KEP-5207）。kubectl topやHPAのCPU・メモリ指標の土台になっているAPIで、v1が定義されました。v1beta1は非推奨ポリシーに沿った移行期間中も使えるため、即時の書き換えは不要です。自前のツールがv1beta1を直に呼んでいるなら、kubectl api-versionsで提供版を確かめ、移行の予定を台帳に載せておきます。指標設計全体はKubernetes監視・モニタリングの設計を参照してください。

Pod証明書とClusterTrustBundleでサービス間mTLSを組む構成の要件

Pod証明書とClusterTrustBundleは、どちらも1.37でStableになりました（KEP-4317・KEP-3257）。Podへ秘密鍵とX.509証明書、検証用の信頼アンカーを配る仕組みをKubernetes本体が持つ形です。

使うには、PodCertificateRequestを監視して証明書を発行・更新する署名コントローラを自分たちで用意し、ワークロード側はその署名者名を指定したpodCertificateの投影ボリュームを宣言します。署名コントローラが要る点は見落とされがちです。cert-managerやサービスメッシュで証明書を回している構成なら、急いで置き換える理由は薄いと判断します。

ノードの安全性と資源管理を変えるRootless・Memory QoS・Pod単位管理

ノード側の変更は、同じ1.37でもOSやcgroupの版によって効き方が変わります。

RootlessモードがBeta既定有効でも既存クラスタが変わらない理由

Rootlessモードは、kubelet・CRIとOCIのランタイム・CNIプラグイン・kube-proxyといったノードコンポーネント全体を、Linuxのユーザー名前空間を使って非rootユーザーで動かす機能です。Rootless Beta化の公式解説によると、1.37で機能ゲートは既定有効になりました。ただし、ゲートを有効にしてもkubeletが自動でユーザー名前空間に入るわけではありません。名前空間はKubernetesの外側で用意する前提なので、既存のrootfulなクラスタには何も起きません。

# ノードがユーザー名前空間で動いているかを確認
kubectl get nodes -o yaml | grep runningInUserNamespace

# rootless Docker 上で kind を起動する例
dockerd-rootless-setuptool.sh install
kind create cluster

Podをユーザー名前空間に入れるhostUsers: falseは1.36でGAになった別機能で、こちらはノードコンポーネントがrootのまま動きます。両者は併用できます。

Memory QoSの既定有効化とcgroup v1ノードが起動しない条件

Memory QoSは、cgroup v2のmemory.min・memory.low・memory.highを使ってメモリの保護と抑制をかける機能で、1.37でBetaかつ既定有効になりました（KEP-2570）。既定値は、既存ワークロードに想定外の抑制がかからないよう設計されています。保護を強めたい場合は、kubeletのmemoryReservationPolicyとmemoryThrottlingFactorで調整します。

本当に注意すべきはcgroup v1です。1.35以降、kubeletのfailCgroupV1は既定でtrueになっており、cgroup v1のノードではkubeletが起動しません。一時的な回避策は次の設定ですが、Memory QoSもメモリ型ボリュームのインプレース拡張もcgroup v2でしか動かないため、延命にとどめてください。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false  # 一時的な回避策。cgroup v2 への移行が前提

Pod単位のリソースマネージャを既定無効のまま様子見すべき構成

Pod-level resource managersは、トポロジ・CPU・メモリの各マネージャが、Pod全体に宣言したリソースを単位にNUMA配置を決められるようにする機能です（KEP-5526）。性能が要るコンテナには専有分を割り当て、サイドカーは残りを共有させる、といった配分がPod 1つで組めます。

恩恵があるのはNUMAを意識するAI/MLやHPCのノードだけで、1.37でも既定無効です。CPUマネージャをstaticで運用していない一般的なWebアプリのクラスタでは得るものがありません。NUMA跨ぎの性能低下を計測できているチームだけが試す対象です。

大規模クラスタ向けのAPIサーバー改善とetcd 3.7前提のRangeStream

コントロールプレーン側の改善は、オブジェクト数が多いクラスタほど効きます。

watchcache初期化の安定化で増えるHTTP 429へのクライアント側の対処

1.37では、watchcache初期化を堅くする作業の残りだったWatchCacheInitializationPostStartHookがStableになり、常時有効に固定されました。キャッシュの温まり中に重いlistやwatchがetcdへ殺到する代わりに、kube-apiserverは処理できる要求だけを委ね、残りをHTTP 429で返します。

影響を受けるのは自作のコントローラやOperatorです。429を受けたらRetry-Afterヘッダを尊重し、指数バックオフで再試行するかを確認してください。独自のHTTPクライアントでAPIを叩く箇所は、429を即失敗扱いにしていることがあります。

EtcdRangeStreamと並列デコードでキャッシュ初期化が約55%縮む条件

EtcdRangeStreamはetcdから大量のキーをチャンク単位でストリーム受信する機能で、kube-apiserverにBetaかつ既定有効で入りました。前提はetcd 3.7以上で、古いetcdでは従来のRange呼び出しへ自動で戻ります。

同じリリースでConcurrentWatchObjectDecodeも既定有効になりました。watchイベントのデコードを10本のワーカーで並列化するもので、公式のベンチマークでは15万Pod規模でキャッシュ初期化がこれ単独で約40%、RangeStreamと組み合わせて約55%短くなっています。副作用はCRDの変換Webhookで、初期化中に最大10件の変換が同時に届きます。Webhook側で同時実行数を10未満に絞っている場合は、上限を見直してください。

1.37の新機能を本番へ入れる判断と見送るべきAlpha機能の線引き

判断の順番は、「何もしなくても変わるもの」を先に潰し、「選んで入れるもの」は効果を測れる場面に限る、です。

アップグレード前に既定で有効になった変更から検証すべき5項目と確認コマンド

検証クラスタで確認する順番は、影響が出たときの止まり方が重い順にします。

SELinuxMountの既定有効化（KEP-1710）。同じボリュームを異なるSELinuxラベルのPodで共有していると、Podが起動しなくなります。
cgroup v1のノードが残っていないか。残っていればkubeletが起動しません。
kube-proxyのipvsモード。1.37で起動時に非推奨の警告が出るようになり、1.40で既定無効、1.43で削除の予定です（KEP-5495）。
CRDの変換Webhookの同時実行上限（並列デコードの既定有効化）。
レプリカ数0を監視している箇所（HPAのゼロスケール）。

# SELinuxマウントを使うCSIドライバを洗い出す
kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMount

# kube-proxy の動作モードを確認する
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

SELinuxを有効にしていないノードなら1は無関係です。以前の挙動に戻したいPodにはspec.securityContext.seLinuxChangePolicy: Recursiveを設定し、1.37の間はクラスタ全体での無効化も選べます（固定は1.38から）。なお、PVCに未使用時刻のUnused条件が既定で付くようになったので、放置ボリュームの棚卸しに使えるでしょう。PVCの設計はKubernetes永続化ストレージ入門が参考になります。

Pod単位チェックポイントなどAlpha機能を本番で有効にしない理由

1.37のAlphaには、Pod単位のチェックポイントとリストア（KEP-5823）、StatefulSetのRecreate戦略（KEP-3541）、インプレースのリサイズに伴うスケジューラのプリエンプション（KEP-5836）など、目を引く機能が27件並びます。結論として、本番クラスタでは有効にしません。

Alphaは次の版でAPIの形が変わりうる段階で、マネージドサービスでは機能ゲートの変更自体を受け付けないことが多いからです。Pod単位のチェックポイントは、コンテナランタイムが新しいCRIのRPCを実装していないと動きません。StatefulSetのRecreateは全Podを消してから作り直すため、データベースでは停止時間が延びます。Betaに上がった版で改めて評価します。

EKSで1.37を選ぶ場合のAuto Mode統合ポリシー既定変更への備え

Amazon EKSは1.37の提供を始めており、EKSの標準サポート版リリースノートにはKubernetes本体と別の変更も載っています。1.37以降、EKS Auto ModeでconsolidationPolicyを指定していない新規NodePoolは、既定がWhenEmptyOrUnderutilizedからBalancedへ変わります。

Pod退避は減る方向です。ただ、コスト削減のためにノードを積極的に畳んでいた運用では、自前のNodePoolでconsolidationPolicyを明示しないと集約の頻度が下がる点に気を付けてください。EKSのノード提供形態はAmazon EKSとは？仕組み・ノード提供形態と料金モデルで整理しました。検証環境づくりやNodePool設計を含むクラスタ移行を任せたい場合は、インフラ構築（AWS・Google Cloud・Azure）でご相談を受け付けています。

Kubernetes 1.37の新機能とアップグレードに関するよくある質問

1.37の新機能について、検証や版上げの前によく確認される質問に答えます。

Kubernetes 1.37はいつリリースされ、いつまでサポートされますか？

1.37は2026年8月26日にリリースされ、公式のReleasesページではEnd of Lifeが2027年10月28日です。2026年10月12日時点の最新パッチは1.37.1（2026年9月15日）でした。EKSやGKE、AKSの提供期限は各社が別に定めているため、マネージドサービスを使う場合はそちらの期限も確かめてください。

Kubernetes 1.37で最も影響が大きい既定動作の変更は何ですか？

SELinuxを有効にしたノードでは、SELinuxMountの既定有効化が最も効いてきます。同じボリュームを異なるSELinuxラベルのPodで共有していると、片方がContainerCreatingのまま止まるためです。SELinuxを使っていないクラスタなら、Memory QoSとHPAのゼロスケールの既定有効化が主な変化です。

1.36から1.37へ上げるとき、まず確認すべき非推奨は何ですか？

kube-proxyのipvsモードとkube-dnsの2つです。ipvsモードは1.37から起動時に非推奨の警告が出て、1.40で既定無効、1.43で削除の予定です。kube-dnsは1.40以降に新しいパッケージが作られない見込みで、CoreDNSへの移行が求められます。どちらもすぐ止まるわけではないものの、切り替えの検証には時間がかかるため、今回の版上げ計画に移行予定を組み込んでおきます。

HPAのゼロスケールが既定で使えるならKEDAは不要になりますか？

不要にはなりません。HPAがゼロとの間を行き来できても、キューの長さなどの外部指標をHPAへ渡すアダプタは別途必要です。KEDAはその指標の供給役も担うため、既に使っているなら置き換える理由は薄いでしょう。Prometheus Adapterで外部指標を出せている構成なら、HPAだけでゼロスケールを組めるようになりました。

kind以外でKubernetes 1.37をローカルで試す方法はありますか？

minikubeとk3sでも試せます。公式のRootless解説では、minikubeはrootless Docker上でminikube start --driver=dockerにより起動でき、k3sは外部ランタイムなしでRootlessモードを持つと説明されています。複数ノードのRootless環境なら同じ解説にあるUsernetesも候補です。新機能を触るだけなら、既定イメージが1.37のkind v0.33.0が最も手数の少ない方法です。