統合階層の意味

Linux cgroup v2はプロセス群の資源使用を階層的に計測・制御するカーネルインターフェースです。v1のようにコントローラーごとに別の階層をマウントする方式ではなく、統合階層を提供します。ただし、すべてのコントローラーがどのホストでも自動的に有効になるわけではありません。cgroup.controllers、親のcgroup.subtree_control、マウント設定、カーネル構成を確認します。CPU、メモリー、I/Oの制御ファイルと動作はカーネルや対応コントローラーで異なります。

systemd環境での管理者と委譲

systemdプロジェクトのインターフェース解説は、各cgroupを単一のユーザー空間コンポーネントが管理するモデルを説明しています。PID 1がsystemdのホストでは、管理対象のファイルを直接書き換えると競合することがあるため、unitの資源設定を使います。サービスが独自の子cgroupを作成する場合は、通常Delegate=yesなどで明示的な委譲を受け、割り当てられた下位ツリーだけを操作します。別のinitやランタイムでは、その管理者の権限・所有ルールを確認してください。

コントローラごとに制御内容は異なる

cpu.max、memory.max、io.maxは異なる資源のポリシーを表し、値を設定するだけで性能や公平性が保証されるわけではありません。I/O制御の適用はブロックデバイス、ファイルシステム、カーネルの対応状況にも左右されます。v2のドメインコントローラーでは、子階層にコントローラーを有効化する際、該当するドメイン構成で親にプロセスを置けない制約があります。これはすべてのcgroupがプロセスを持てないという意味ではなく、threaded subtreeには異なる規則があります。

PSIとOOM方針を混同しない

Pressure Stall InformationはCPU・メモリー・I/O圧力でタスクが遅延した時間をカーネルが報告する仕組みで、cgroup単位でも確認できます。someとfullの平均値・累積値は意味が異なり、単一の使用率とはみなせません。ファイルの有無と設定はカーネルによります。systemd-oomdはPSIを判断材料にできますが、すべてのディストリビューションやKubernetesノードが同じ方法でコンテナーを終了するわけではありません。ユーザー空間oomd、カーネルOOM、kubeletのノード圧力による退避を分けて考えます。

専門家による移行時の実務経験

Red Hatでコンテナー運用に携わったDan Walshは、コンテナツールとディストリビューション間の互換性がcgroup v2の既定化を遅らせ、Fedora、Podman、CRI-O、crunの連携が移行を進めた経緯を記しています。これは当時の運用者による回顧で、現在の全ディストリビューションの互換表ではありません。実運用では階層モード、カーネルとsystemdの版、ランタイム対応、制限の実測を確かめ、v1からの差分も試験します。

参考資料