KUBERNETES / NODE OPERATIONS
cgroupはPodのCPUやメモリーを制御するLinuxの基盤。v1を残したままKubernetesを更新すると、kubeletの起動条件にぶつかる可能性がある。
failCgroupV1が標準でtrueとなり、v1ノードではkubeletが起動しない。[1][2]falseへ戻す設定はあるが恒久策ではない。OS・カーネル・ランタイム・ドライバーを点検してから、ノード単位で移す。[1][2]cgroup（control groups）は、Linuxがプロセス群のCPU・メモリーなどの資源を管理する仕組み。Kubernetesのkubeletとコンテナーランタイムはこれを使い、Podに指定された要求量や上限を適用する。v2では複数の資源を1つの階層で扱い、委譲や資源の会計が整理された。Pressure Stall Information（PSI）など、新しい監視・制御機能の基盤にもなる。[1][2]
10月6日の公式記事は新バージョンのリリース告知ではなく、既に進んでいるv1からv2への移行を説明する運用ガイドだ。v1.31でv1サポートは保守段階に入り、v1.35では標準設定のkubeletがcgroup v1を拒否する。kubeadm管理の環境では初期化・参加・更新時の事前検査もより厳しくなる。公式記事はv1の一時的なフォールバックを示しつつ、将来の削除を予定している。[1]
| 項目 | 確認すること | 理由 |
|---|---|---|
| 1. OS | cgroup v2を有効にしているか | v2非対応のままではkubeletが利用できない |
| 2. カーネル | 5.8以上。Memory QoSを試すなら5.9以上を推奨 | 必要なcgroup機能・修正を確保する |
| 3. ランタイム | containerd 1.4以上、またはCRI-O 1.20以上など | v2を扱える実装が必要 |
| 4. ドライバー | kubeletとランタイムのcgroupドライバーを一致させる | 不一致によるノード障害を避ける |
| 5. 運用・監視 | Pod退避、CPU重み、OOM、監視指標を試験 | 起動成功だけでは挙動の変化を見落とす |
公式文書は、cgroup v2でsystemd cgroupドライバーを使うことを推奨する。kubeletとランタイムの設定が合っていなければならない。containerd 2.0以降など、RuntimeConfigを実装するランタイムではkubeletがドライバーを自動検出できるが、旧ランタイムでは設定の確認が必要だ。[1][2][3]
v2ではcpu.sharesからcpu.weightへ対応が変わり、OOM（メモリー不足）時にはコンテナー内のプロセス群をまとめて終了させる標準動作がある。正確なCPU重みを監視・ポリシーで前提にしている環境や、複数プロセスを含むコンテナーは移行テストが重要だ。なお、このOOM処理はコンテナー単位でありPod全体を常に終了させるという意味ではない。[1]
Linuxノードで次のコマンドを実行する。cgroup2fsならv2、tmpfsなど別の結果ならv1・混在構成を疑う。OS配布版によって差があるため、変更前に実機で確認する。[1][2]
stat -fc %T /sys/fs/cgroup/
uname -r本番では一括変更せず、対象ノードのPodを退避できるか、PodDisruptionBudgetが移行を妨げないか、ロールバック用のノードイメージがあるかを確認する。OSのcgroup方式を切り替える手順は配布版ごとに異なるため、公式のOS手順に従う。ここに示したコマンドは確認のみで設定を変更しない。
v2に変えるだけで全てのメモリープレッシャーが解消するわけではない。公式記事はI/Oが多いワークロードでのactive_fileに関する退避判定の問題が、v2移行だけでは変わらないと注意している。またMemory QoSなどの機能は、利用中のKubernetes版と機能ゲートの状態を別途確認する必要がある。[1]
次の更新前には、利用中のKubernetesリリースのアップグレード文書、OSのデフォルトcgroup方式、ランタイムの対応表を再確認したい。管理サービスではノードイメージや更新手順が事業者ごとに異なるため、提供元の手順も優先する。
最終確認日：2026年10月8日（日本時間）