--- title: "Kubernetes 1.37の新機能｜注目機能の要点とkindで試す機能ゲート設定" url: "https://www.issoh.co.jp/tech/details/18275/" published: 2026-10-12 updated: 2026-10-12 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # 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一覧とアップグレード手順](https://www.issoh.co.jp/tech/details/17151/)にまとめています。本記事は「1.37で何が増え、どう試すか」に絞ります。 ## Kubernetes 1.37 Garhwalのリリース概要と67件の変更内訳 1.37のリリースサイクルは2026年5月18日から8月26日までの15週間で、212社・1,754人が貢献したと[公式リリースブログ（Kubernetes v1.37: Garhwal）](https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/)に記されています。日本語で読みたい場合は[公式ブログの日本語訳](https://kubernetes.io/ja/blog/2026/08/26/kubernetes-v1-37-release/)も公開されています。 ### 1.37のリリース日とサポート期限・1.37.1パッチの提供状況（2026年10月時点） 公式の[Releasesページ](https://kubernetes.io/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](https://www.issoh.co.jp/tech/details/8967/)、1.35の機能は[Kubernetes 1.35の新機能と変更点](https://www.issoh.co.jp/tech/details/10465/)で扱っています。複数マイナー版をまたぐ場合は、間の版の変更も読んでから計画を立ててください。 ### 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の公式リファレンス](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)で引けます。表の「有効」は、アップグレードしただけで挙動が変わりうるという意味です。 ## kindでKubernetes 1.37の検証クラスタを起動して新機能を試す手順 新機能を本番で初めて触るのは避けます。Docker上にクラスタを作るkindなら、1.37を数分で用意でき、機能ゲートも設定ファイルで切り替えられます。 ### kind v0.33.0の既定イメージv1.37.0で検証クラスタを起動するコマンド [kind v0.33.0のリリースノート](https://github.com/kubernetes-sigs/kind/releases/tag/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の設定ドキュメント](https://kind.sigs.k8s.io/docs/user/configuration/)にある`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](https://github.com/kubernetes/enhancements/issues/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の公式ドキュメント](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)が基準になります。 ### 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](https://github.com/kubernetes/enhancements/issues/5295)）。KYAMLは正しいYAMLでもあるため、既存のマニフェストを書き換える必要はなく、出力形式が1つ増えたと捉えれば足ります。 ``` kubectl get deployment queue-worker -o kyaml ``` もう一つはmetrics.k8s.ioです（[KEP-5207](https://github.com/kubernetes/enhancements/issues/5207)）。`kubectl top`やHPAのCPU・メモリ指標の土台になっているAPIで、v1が定義されました。v1beta1は非推奨ポリシーに沿った移行期間中も使えるため、即時の書き換えは不要です。自前のツールがv1beta1を直に呼んでいるなら、`kubectl api-versions`で提供版を確かめ、移行の予定を台帳に載せておきます。指標設計全体は[Kubernetes監視・モニタリングの設計](https://www.issoh.co.jp/tech/details/15303/)を参照してください。 ### 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化の公式解説](https://kubernetes.io/blog/2026/09/04/kubernetes-v1-37-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](https://github.com/kubernetes/enhancements/issues/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](https://github.com/kubernetes/enhancements/issues/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項目と確認コマンド 検証クラスタで確認する順番は、影響が出たときの止まり方が重い順にします。 1. SELinuxMountの既定有効化（[KEP-1710](https://github.com/kubernetes/enhancements/issues/1710)）。同じボリュームを異なるSELinuxラベルのPodで共有していると、Podが起動しなくなります。 2. cgroup v1のノードが残っていないか。残っていればkubeletが起動しません。 3. kube-proxyのipvsモード。1.37で起動時に非推奨の警告が出るようになり、1.40で既定無効、1.43で削除の予定です（[KEP-5495](https://github.com/kubernetes/enhancements/issues/5495)）。 4. CRDの変換Webhookの同時実行上限（並列デコードの既定有効化）。 5. レプリカ数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永続化ストレージ入門](https://www.issoh.co.jp/tech/details/15294/)が参考になります。 ### 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の標準サポート版リリースノート](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html)にはKubernetes本体と別の変更も載っています。1.37以降、EKS Auto Modeで`consolidationPolicy`を指定していない新規NodePoolは、既定が`WhenEmptyOrUnderutilized`から`Balanced`へ変わります。 Pod退避は減る方向です。ただ、コスト削減のためにノードを積極的に畳んでいた運用では、自前のNodePoolで`consolidationPolicy`を明示しないと集約の頻度が下がる点に気を付けてください。EKSのノード提供形態は[Amazon EKSとは？仕組み・ノード提供形態と料金モデル](https://www.issoh.co.jp/tech/details/15437/)で整理しました。検証環境づくりやNodePool設計を含むクラスタ移行を任せたい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)でご相談を受け付けています。 ## 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が最も手数の少ない方法です。 ## 関連記事 - [Kubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順](https://www.issoh.co.jp/tech/details/17151/)：使用中クラスタの版の確かめ方と、1.37へ上げる手順 - [Kubernetes 1.35の新機能と変更点｜リリース内容とサポート終了日](https://www.issoh.co.jp/tech/details/10465/)：Podリソースのインプレース更新がStableになった版 - [Kubernetes 1.34の変更点とEOL｜EKS・GKE・AKSのサポート期限とDRA GA](https://www.issoh.co.jp/tech/details/8967/)：2026-10-27にEOLを迎える版の変更点 - [Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断](https://www.issoh.co.jp/tech/details/15303/)：metrics.k8s.ioやネイティブヒストグラムを前提にした指標設計 - [コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説](https://www.issoh.co.jp/column/details/13003/)：そもそもKubernetesを自社で持つべきかの判断軸 --- 出典: [Kubernetes 1.37の新機能｜注目機能の要点とkindで試す機能ゲート設定]()（株式会社一創）