Kubernetes v1.35、Linuxノードでのcgroup v2移行を強制

Kubernetesプロジェクトはcgroup v1サポートをメンテナンスモードに移行し、cgroup v2による統一されたリソース管理インターフェースへの明確なシフトを示しました。Kubernetes v1.35以降、管理者がこの挙動を明示的にオーバーライドしない限り、kubeletは依然としてcgroup v1を使用しているノードでの起動を拒否します。この変更はすべてのLinuxベースのクラスターに影響するため、アップグレード前にカーネルバージョン、コンテナランタイム、およびノード構成の確認が必要です。

何が起きたか

制御グループ（cgroups）は、CPUやメモリなどのリソースを特定のプロセスに割り当てることを可能にするLinuxカーネル機能です。Kubernetesは、コンテナ同士が干渉し合わないことを保証するためにこのメカニズムを利用しています。cgroup v2はKubernetesバージョン1.25以来安定してサポートされていますが、旧式のv1インターフェースへのサポートは現在段階的に廃止されています。Kubernetes v1.35では、failCgroupV1設定パラメータのデフォルト値がtrueになります。つまり、ノードがcgroup v1を実行している場合、kubeletプロセスは起動中に失敗し、事実上ノードがオフライン状態になります。

まだ移行の準備ができていない管理者は、kubelet設定ファイルでfailCgroupV1: falseを一時的に設定できます。しかし、これはあくまで暫定的な対策です。Kubernetesの非推奨ポリシーによれば、cgroup v1サポートの完全な削除は間もなく実施される予定であり、KEP-5573で追跡されています。kubeadmで管理されているクラスターの場合、強制力はさらに厳しくなります。k8s.io/system-validatorsツールの一部であるSystemVerificationプリフライトチェックは、kubelet v1.35以降を実行しているノードでcgroup v1を検出すると、初期化、参加、またはアップグレード中にエラーを返すようになりました。以前は単なる警告でした。

この移行は単なるコンプライアンスの問題ではなく、現代的なリソース管理機能を解放するものです。cgroup v2は単一の階層構造を提供し、v1の複数の階層構造と比較してインターフェースを簡素化します。より強力な分離を実現し、Pressure Stall Information (PSI) や改善されたメモリ品質サービス (QoS) などの新機能をサポートします。v1のまま残っているクラスターはこれらの最適化を見逃し、新しいコンテナランタイムや監視ツールとの互換性問題に直面することになります。

仕組み

cgroup v2は、v1の複雑なマルチ階層構造を、すべてのコントローラー（CPU、メモリ、I/O）が接続される単一のツリー構造に置き換えます。この統一により、リソース会計の一貫性が向上し、階層の不一致によってあるコントローラーでは制限されるが別のコントローラーでは制限されないという状況を防止できます。Kubernetesでは、kubeletがこれらのコントローラーと対話して、Pod仕様に定義された制限を適用します。v2では、kubeletはmemory.highによるスロットリングやmemory.minによるハードプロテクションなどの機能を使用できますが、これらはv1では不可能であったか信頼性がありませんでした。

また、移行に伴い、アウト・オブ・メモリー（OOM）イベントの処理方法も変更されます。cgroup v2では、kubeletは各コンテナのcgroupに対してmemory.oom.groupを設定します。OOMイベントが発生すると、カーネルはプロセスを一つずつ選択するのではなく、そのコンテナ内のすべてのプロセスを同時に終了させます。これにより、部分的に動作しているコンテナが破損した状態で残り続けることが防がれます。さらに、cgroup v2は委任（delegation）を有効にし、rootlessコンテナがsystemdを通じて自身のcgroupを安全に管理できるようにします。この機能はv1ではリスクが高かったか、あるいは不可能でした。

主要な詳細

• デフォルトの強制: Kubernetes v1.35では、failCgroupV1のデフォルト値がtrueとなり、cgroup v1ノードでのkubelet起動失敗を引き起こします。
• カーネル要件: cgroup v2サポートにはLinuxカーネルバージョン5.8以降が必要であり、メモリQoSの安定性のためには5.9以上が推奨されます。
• ランタイムサポート: Containerd v1.4+ および CRI-O v1.20+ はcgroup v2をサポートしています。自動ドライバー検出にはcontainerd v2.0+ または CRI-O v1.28+ が必要です。
• メモリQoS: memory.high と memory.low を使用するアルファ版のMemory QoS機能は、cgroup v2ノードでのみ利用可能です。
• ツール更新: 監視ツールを更新する必要があります。cAdvisor v0.43.0+ が推奨され、JavaおよびNode.jsライブラリの互換性のあるバージョンも必要です。
• CPUウェイト変換: crun v1.23 や runc v1.3.2 などの新しいOCIランタイムは、v1のcpu.sharesからv2のcpu.weightへの変換に非線形なアプローチを採用しており、小さなCPUリクエストに対する粒度を改善します。

なぜ重要か

ソフトウェアエンジニアやプラットフォームチームにとって、このシフトはレガシーなインフラ構成がもはや実行不可能であることを意味します。ワーカーノードを移行せずにコントロールプレーンをv1.35にアップグレードすると、クラスターは破綻します。ノードは参加に失敗し、既存のノードは再起動後に失敗する可能性があります。多くの古いLinuxディストリビューションはデフォルトでcgroup v1を使用しているため、OSアップデートへの強い依存関係が生じます。チームはフリート全体でカーネルアップグレードを調整する必要があり、大規模で異種混合の環境では大きな運用上の障壁となる可能性があります。

即時の移行の痛みを超えて、v2にとどまることはより良いリソース効率をもたらします。PSIなどの機能はリソース競合に関するリアルタイムの可視性を提供し、より正確なオートスケーリング判断を可能にします。改善されたOOM処理により、アプリケーション障害はよりクリーンになり、デバッグが容易になります。さらに、インプレース垂直スケーリングが安定化するにつれ、正確な集約的な強制にはcgroup v2が必要になります。この移行パスを無視すれば、最終的にはクラスターがこれらのパフォーマンスおよび信頼性の向上を導入できなくなります。

対応策

• 現在のステータス確認: ノード上で stat -fc %T /sys/fs/cgroup/ を実行してください。cgroup2fs が返される場合は、すでにv2を使用しています。
• カーネルバージョン検証: すべてのLinuxノードがカーネル5.8以降を実行していることを確認してください。Kubernetesのアップグレードを試みる前に、必要に応じてOSをアップグレードしてください。
• コンテナランタイム更新: containerd v1.4+ または CRI-O v1.20+ を使用していることを確認してください。理想的には、自動cgroupドライバー検出を活用するためにcontainerd v2.0+ へ移行してください。
• Kubelet設定: 即時の移行ができない場合は、kubelet設定で failCgroupV1: false を設定しますが、このオーバーライドを早急に削除する計画を立ててください。ランタイムに合わせてcgroupドライバーを設定し、できれば systemd を使用してください。
• 監視スタック更新: cAdvisorをv0.43.0以降にアップグレードし、Prometheusスクレイパーやその他の監視ツールがcgroup v2メトリクスをサポートしていることを確認してください。
• メモリQoSテスト: 高度なリソース管理を使用している場合は、ステージング環境でアルファ版のMemory QoS機能をテストし、memory.high スロットリングがワークロードにどのような影響を与えるかを理解してください。