Kubernetesクラスタを本番環境で運用する情報システム部門・SREチームが、2026年8月26日リリース予定のKubernetes 1.37で向き合うことになる変更がある[1]。長年使われてきたkube-proxyのIPVSモードが非推奨の警告フェーズに入り、あわせてcgroup v1のフェーズアウトが最終段階に近づく。前者は約2年の猶予があるが、後者はすでにv1.35から実害が出ている変更で、性質がまったく違う。
Kubernetesのマイナーバージョンアップは年3回のペースで進み、多くの企業は数バージョンまとめてアップグレードする運用を取っている。そのため、1つのバージョンで告知された非推奨化のスケジュールを見落としたまま数バージョン先で初めて気づく、という事態が起こりやすい。本記事では1.37まわりの2つの変更を「猶予のあるもの」と「すでに効いているもの」に切り分け、企業クラスタが今のうちに取るべき事前対応を検討する。
予備知識
- kube-proxy: Kubernetesの各ノード上で動作し、Serviceへのアクセスを実際のPodへ振り分けるコンポーネント。IPVS・iptables・nftables等の複数モードで動作できる。
- IPVS（IP Virtual Server）: Linuxカーネルが提供するロードバランシング機能。大規模クラスタでiptablesモードより高いパフォーマンスを発揮するとされてきた。
- cgroup（コントロールグループ）: Linuxカーネルの機能で、プロセスが使えるCPU・メモリ等のリソースを制限する仕組み。v1とv2の2系統があり、Kubernetesは段階的にv2へ移行してきた。
- kubelet: 各ノード上で動作し、Podの起動・停止とコンテナランタイムへの指示を担うコンポーネント。これが起動しないノードはクラスタに参加できない。
kube-proxyやkubeletの内部動作を含めKubernetesの各コンポーネントを体系的に押さえておきたいクラスタ運用担当向けの定番ガイド。
kube-proxy IPVSモードの非推奨化スケジュール
IPVSモードは、カーネルのIPVS APIだけではKubernetesのServiceを完全には実装できず、内部では結局iptablesを併用している。この構造的な理由から非推奨化が決まった[1][2]。
スケジュールは3段階だ。v1.37ではIPVSモード（mode: ipvs）で動作しているkube-proxyが起動時に非推奨警告をログ出力するようになり、v1.40でデフォルト無効化（フィーチャーゲートで選択は可能）、v1.43でサポートを完全削除という計画になっている[1][2]。年3回リリースのペースで数えると、警告開始から完全削除まで約2年の猶予がある。
自クラスタのモードは次のコマンドで確認できる[1]。
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
なお、v1.40の「デフォルト無効化」は自動的に動かなくなるという意味ではなく、フィーチャーゲートでの選択が残る[1]。とはいえフィーチャーゲート頼みの構成を本番で長く維持する判断にはリスクがあるため、実務上はv1.40到達前の移行完了を目標に置くのが妥当だ。
バージョンアップや破壊的変更への対応を含め、本番環境でKubernetesを運用し続けるための実践知をまとめた一冊。
cgroup v1ノードでkubeletが起動しない——これはv1.35からの話
IPVSと並べて語られがちだが、cgroup v1のほうは性質が違う。v1.35の時点ですでに failCgroupV1 のデフォルトが true になっており、cgroup v1に依存するノードではkubeletが初期化に失敗する[1][3]。v1.37で新しく始まる変更ではなく、v1.35から続いている挙動だ。すでにv1.35以降へ上げているクラスタは、この影響を受け終わっているか、あるいは気づかないまま回避設定が入っている。
回避策として、KubeletConfigurationで明示的に無効化はできる[1]。
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # 一時的な回避
ただし公式はこれを短期的な回避策と位置づけている。In-Place Pod Resizing（Podを再作成せずにリソースを変更する機能）やTiered Memory Protectionといった新しいリソース管理機能はcgroup v2に完全に依存しており、v1のままではそもそも使えない。オーバーライド自体はv1.37でも利用できるが、cgroup v1のサポートは将来のリリースで削除される予定だ[1][3]。
長年運用してきたクラスタほど、OSやカーネルのアップグレードが後回しになり、cgroup v1のまま残っているノードが存在しがちだ。この回避設定が「誰かが過去に入れたまま忘れられている」状態になっていないかの確認が、実務上の要点になる。
| 変更点 | 効き始めるバージョン | 影響 | 事前対応 |
|---|---|---|---|
| kube-proxy IPVS 起動時警告 | v1.37 | ログに警告が出る（動作は継続） | 代替モードへの移行計画を立てる |
| kube-proxy IPVS デフォルト無効化 | v1.40 | 明示設定がない限りIPVSが選ばれない（ゲートで選択は可） | v1.40到達前に移行を完了させる |
| kube-proxy IPVS 削除 | v1.43 | IPVSモードが使えなくなる | — |
| cgroup v1ノードのkubelet起動失敗 | v1.35（すでに適用済み） | failCgroupV1: false 未設定だと初期化失敗 | cgroup v2へ移行。回避設定の残存を棚卸し |
etcd（Kubernetesのクラスタ状態を保存する分散キーバリューストア）のv3.7.0が2026年7月8日にリリースされた[1]。目玉は2つある。大容量のレンジクエリをチャンク単位で取得できるRangeStream（結果を分割ストリ[…]
事前対応の進め方——ノード棚卸しから始める
第一歩は、クラスタ内の全ノードのcgroupモードと、kube-proxyの動作モードを棚卸しすることだ。マネージドKubernetesサービス（EKS・AKS・GKE等）を利用している場合でも、ノードイメージのバージョンによっては古いOSベースのままになっている可能性があるため、クラウド事業者側のドキュメントで確認する必要がある。
kube-proxyのモードはConfigMapまたは起動引数を見ればわかる。IPVSモードを使っている場合、代替モード（nftablesベースの新モードなど）への切り替えは単純な設定変更では済まず、Service数やクラスタ規模によってはパフォーマンスへの影響を事前に検証する必要がある[1][2]。
v1.37にはこのほかにも、kubectl run --filename/-f の非推奨化、Static PodからのSecret・ConfigMap参照の全面禁止（PreventStaticPodAPIReferences フィーチャーゲート自体が削除される）、SELinuxボリューム再ラベリングのGA昇格が含まれる[1]。特にStatic Podの制限は、これまでバグとして通っていた参照が動かなくなる変更なので、該当構成があるクラスタは合わせて確認しておきたい。
数千人規模の従業員が使う基幹システムをAmazon EKS（Amazon Elastic Kubernetes Service、AWSのマネージドKubernetesサービス）上で本番稼働させ、年1回の内部監査を受ける情報システム部門のイ[…]
日本企業のKubernetes運用における対応のばらつき
日本企業のKubernetes運用体制は、内製SREチームを持つ企業と、SIerに構築・運用を委託している企業とで、こうしたバージョン変更への対応力に差が出やすい。内製チームを持つ企業は、Kubernetesの公式ブログやリリースノートを継続的に追い、非推奨化のスケジュールを早期に把握できる。一方、SIer委託の場合、契約範囲によっては「言われたことだけ対応する」保守形態になっており、非推奨化の告知自体が発注側に伝わらないまま数年後に緊急対応を迫られるケースがある。
また、既存システムを長年運用してきた企業ほど、初期構築時のOS・カーネルバージョンのままノードが更新されておらず、cgroup v1が残存している可能性が高い。前述のとおりこれはv1.35からの話なので、「まだ先の話」として先送りできる段階をすでに過ぎている。監査や内部統制の観点では、こうしたクラスタ基盤の技術的負債が明文化されていないことが多く、アップグレードのタイミングで初めて表面化する。
| 観点 | 内製SREチームを持つ企業 | SIer委託中心の企業 |
|---|---|---|
| 非推奨化情報の把握 | 公式リリースノートを継続的に確認 | 委託契約の範囲外だと伝わらないことがある |
| cgroup v1残存リスク | 定期的な棚卸しで把握しやすい | 初期構築後に見直されないまま残りやすい |
| 対応の緊急度判断 | 自社でスケジュールを組める | 委託先への追加発注・調整が必要になる |
情シス担当の次の一手は、SIer委託の保守契約範囲にKubernetesの非推奨化情報のキャッチアップが含まれているかを確認すること。決裁側の判断材料は、v1.40（デフォルト無効化）到達前にIPVSモードからの移行を完了させるためのスケジュールと、追加の委託費用が必要かどうかの見極めになる。
オブザーバビリティ層のうち、eBPF（カーネル内で安全に小さなプログラムを動かす仕組み）を使った計装が実用域に入ってきた。対象はKubernetes基盤でアプリの通信を可視化したいプラットフォームチームやSREで、これまでは各サービスにO[…]
まとめ
Kubernetes 1.37まわりの2つの変更は、猶予の長さがまったく違う。kube-proxy IPVSモードはv1.37の警告からv1.43の削除まで約2年あるが、cgroup v1ノードでのkubelet起動失敗はv1.35からすでに効いている。前者は移行計画を立てる話、後者は「回避設定でしのいでいる状態が残っていないか」を今すぐ確認する話だ。情シス担当はノードの棚卸しを、決裁側はSIer委託契約への対応範囲組み込みを、今のうちに進める必要がある。
よくある質問（FAQ）
Q. IPVSモードを使っていなければ今回の変更は無関係ですか？
A. kube-proxyの変更は無関係だが、cgroup v1ノードでのkubelet起動失敗は全てのKubernetesクラスタに影響し得るため、確認が必要になる。またv1.37ではStatic PodからのSecret・ConfigMap参照が全面禁止になるため、該当構成があれば対応が要る[1]。
Q. マネージドKubernetesサービスを使っていれば自動的に対応されますか？
A. コントロールプレーンの更新はクラウド事業者側が行うが、ワーカーノードのOSイメージ更新やcgroupモードの確認は利用者側の責任範囲になることが多い。
Q. v1.37にアップグレードしなければ影響はありませんか？
A. IPVSの警告は出ないが、cgroup v1の件はv1.35以降であれば既に該当する。またv1.36以前のバージョンにはいずれ標準サポート終了が到来する。EKS・AKS等のマネージドサービスでは標準サポート終了後に延長サポート料金が発生する制度があり、バージョンを上げない選択自体がコスト側のリスクになる。
