cgroup とは何か(Linux のリソース制限の仕組み)

[hiramekun]

[claude]

Claude finished @hiramekun's task in 1m 40s —— View job

---

概要

cgroup(control groups)は、Linux カーネルが提供する プロセスグループ単位で CPU・メモリ・I/O などのリソース使用量を制限・計測・隔離する機能 です。Docker や Kubernetes(containerd/runc)がコンテナに --memory・--cpus のようなリソース制限をかけられるのは、内部的にこの cgroup を利用しているためです。似た名前の概念に「namespace」がありますが、役割は異なります。

• namespace:プロセスから「何が見えるか」を分離する(PID・ネットワーク・マウントなど)
• cgroup:プロセスが「どれだけリソースを使えるか」を制限する

flowchart TB
    subgraph Host["Linux カーネル"]
        Root["cgroup ルート (/sys/fs/cgroup)"]
        Root --> A["cgroup: container-A\ncpu.max = 100000 100000\nmemory.max = 512M"]
        Root --> B["cgroup: container-B\ncpu.max = 50000 100000\nmemory.max = 256M"]
        A --> P1["プロセス (nginx)"]
        A --> P2["プロセス (worker)"]
        B --> P3["プロセス (app)"]
    end

    Docker["docker run --memory=512m --cpus=1"] -.設定.-> A

Loading

何が嬉しいのか

cgroup がないと、1 つのプロセス(コンテナ)が CPU やメモリを使い切ってしまい、同じホスト上の他のプロセス・コンテナに影響を与える「noisy neighbor(うるさい隣人)問題」が起きます。cgroup を使うことで次のようなメリットがあります。

• リソースの公平な分配:1 コンテナが暴走してもホスト全体やほかのコンテナを巻き込まない
• OOM(メモリ不足)からの保護:メモリ上限を超えたプロセスだけを cgroup 単位で kill でき、ホスト全体がクラッシュするのを防げる
• リソース使用量の可視化:cgroup 配下の疑似ファイル(memory.current, cpu.stat など)を読むだけでプロセスグループ単位のメトリクスが取れる(cAdvisor や kubectl top はこれを利用)
• マルチテナント環境での安全な共存:Kubernetes の Pod ごとの resources.requests/resources.limits は、最終的に各 Pod 用の cgroup 設定に変換される

具体例として、Kubernetes で Pod に resources.limits.memory: 512Mi を設定すると、kubelet がその Pod のコンテナに対応する cgroup の memory.max を 512Mi に設定し、それを超えて確保しようとしたプロセスは OOM Killer に kill されます。

詳細

仕組み

cgroup は /sys/fs/cgroup にマウントされた cgroupfs という疑似ファイルシステム を通じて操作します。ディレクトリを作ると 1 つの cgroup(プロセスグループ)ができ、そこに cgroup.procs へプロセス ID を書き込むことでそのグループに所属させます。各 cgroup ディレクトリには controller(コントローラ) ごとの制御ファイルが並びます。

主なコントローラ:

コントローラ	役割
cpu	CPU 使用時間の制限・重み付け
cpuset	使用する CPU コア・NUMA ノードの固定
memory	メモリ使用量の上限、OOM 制御
io(v1 では blkio)	ディスク I/O 帯域の制限
pids	生成できるプロセス数(PID)の上限(fork 爆弾対策)
devices	アクセス可能なデバイスファイルの制御
freezer	プロセスグループ全体の一時停止・再開

v1 と v2 の違い

• cgroup v1:コントローラごとに別々の階層(ツリー)を持つ。柔軟だが管理が複雑で、あるプロセスがどの制限を受けているか追いにくい
• cgroup v2:すべてのコントローラを 単一の階層(unified hierarchy) にまとめた再設計版。ファイル名や設計も整理されており、現在の主要ディストリビューション(Ubuntu 22.04+、最近の Docker/containerd/Kubernetes)は v2 がデフォルト

コンテナランタイムは「cgroup driver」として cgroupfs(直接 cgroupfs を操作)か systemd(systemd 経由で cgroup を管理)のどちらかを選べます。Kubernetes では kubelet と CRI 実装(containerd など)で driver を揃えないと Pod 起動時に不整合が起きることがあるため、systemd ドライバへの統一が推奨されています。

確認・操作の例

# 現在のプロセスがどの cgroup に属しているか
cat /proc/self/cgroup

# cgroup v2 でのメモリ上限確認
cat /sys/fs/cgroup/memory.max

# systemd-cgls でツリー表示
systemd-cgls

# Docker でリソース制限をかけて起動(内部的に cgroup を設定)
docker run --memory=512m --cpus=1 nginx

注意点

• cgroup v1/v2 が混在した環境(hybrid mode)ではツールによって挙動が変わることがあるため、mount | grep cgroup で確認しておくと良い
• メモリ制限(memory.max)を超えると、プロセスは即座に OOM Killer に kill される。アプリ側でメモリ使用量を制御していないと突然落ちるので注意
• CPU の cpu.max(quota/period)は「スロットリング」であり、割り当てを使い切ると一時的に CPU を使えなくなる(クラッシュはしないが遅延の原因になる)

参考リンク

• Control Group v2 — The Linux Kernel documentation
• cgroups(7) — Linux manual page
• Docker docs: Resource constraints
• Kubernetes docs: Resource Management for Pods and Containers

---

既存 issue を検索しましたが、cgroup を中心テーマとする重複・関連ノートはありませんでした。タイトルを「cgroup とは何か(Linux のリソース制限の仕組み)」に変更し、infra / cs-fundamentals / type:concept ラベルを付与しました。

[hiramekun]

@claude cgroup v1とv2の違いを教えて

[claude]

cgroup v1 と v2 の違いを、階層構造・コントローラの実装・運用面の 3 つの観点でもう少し詳しく説明します。

階層構造の違い（最大のポイント）

v1 と v2 の本質的な違いは「コントローラごとに別々のツリーを持てるかどうか」です。

flowchart TB
    subgraph V1["cgroup v1: コントローラごとに独立した階層"]
        direction TB
        CPUroot["cpu 階層"] --> CPUa["group-A"]
        CPUroot --> CPUb["group-B"]
        MEMroot["memory 階層"] --> MEMa["group-A"]
        MEMroot --> MEMc["group-C"]
        Proc1["プロセス P"] -.所属.-> CPUa
        Proc1 -.所属.-> MEMc
    end

    subgraph V2["cgroup v2: 単一の統合階層"]
        direction TB
        Root2["/sys/fs/cgroup"] --> G1["group-A(cpu, memory, io すべて適用)"]
        Root2 --> G2["group-B"]
        Proc2["プロセス P"] -.所属.-> G1
    end

Loading

• v1：cpu 用のツリー、memory 用のツリーのように、コントローラごとに別のマウントポイント（階層）を作れる。1 つのプロセスが「CPU 制限は group-A、メモリ制限は group-C」のように、コントローラごとに違うグループに属することができ、柔軟だが全体像を追いにくい
• v2：すべてのコントローラが 1 本のツリーに統合される。プロセスはただ 1 つの cgroup にのみ所属し、その cgroup で有効化されている全コントローラの制限を受ける。「このプロセスがどの制限を受けているか」を /proc/<pid>/cgroup の 1 行で把握できる

v2 にはさらに 「no internal process ルール」 があり、あるコントローラを有効化した非ルート cgroup は「プロセスを直接持つ」か「子 cgroup を持つ」かのどちらか一方しかできません（リーフノードにのみプロセスを置ける）。これにより v1 でありがちだった「親と子の両方にプロセスがいて、どちらの制限が優先されるか分かりにくい」という問題を構造的に防いでいます。

コントローラ単位の違い

項目	v1	v2
CPU 制限	cpu.shares（相対比、2〜262144） + cpu.cfs_quota_us/cfs_period_us	cpu.weight（1〜10000、デフォルト100） + cpu.max（quota と period を1ファイルに統合）
メモリ制限	memory.limit_in_bytes、memory.soft_limit_in_bytes	memory.max（ハード上限）、memory.high（ソフトなスロットリング）、memory.low/memory.min（保護）の4段階で細かく制御可能
I/O	blkio という別名のコントローラ	io に統合・整理
freezer（一時停止）	独立したコントローラとして有効化が必要	常に使えるコア機能（cgroup.freeze ファイル）
devices（デバイスアクセス制御）	devices.allow/devices.deny ファイル	eBPF プログラム（BPF_CGROUP_DEVICE）ベースに変更。ファイルベースの直接操作は廃止
スロットル可視化	基本的に無し	PSI（Pressure Stall Information）が cpu.pressure/memory.pressure/io.pressure として見える。「リソース不足でどれだけ待たされたか」が定量的に分かる

PSI は v2 で追加された比較的新しい仕組みで、ディストリビューションによってはまだ有効化されていないこともあるので、実際に使う際はカーネル設定（CONFIG_PSI）の確認が必要です。

運用面での違い

• 委譲（delegation）のしやすさ：v2 は「1 プロセス = 1 cgroup」かつ no internal process ルールがあるため、systemd がツリー全体を管理しつつ、その一部をユーザーやコンテナランタイムに安全に委譲しやすい設計になっている。v1 はコントローラごとにツリーが分かれているため委譲の整合性を保つのが難しかった
• 主要ツールの対応状況：Docker（20.10+）、containerd、Kubernetes（1.25 で GA）は v2 に対応済み。現在の主要ディストリ（Ubuntu 22.04+、Fedora、RHEL 9 系など）はデフォルトで v2 を採用
• 混在（hybrid）モード：systemd 自体は v2 の一部機能（プロセス管理用）を使いつつ、他のコントローラは v1 のまま、というハイブリッド構成を取れる環境もある。mount | grep cgroup や stat -fc %T /sys/fs/cgroup で cgroup2fs と出れば v2、tmpfs の下に個別マウントが並んでいれば v1（または hybrid）と判断できる

補足（不確かな点）

v2 のスレッド単位の制御（threaded cgroup）は v1 の per-thread cgroup 割り当てとは仕組みが異なり、cpu コントローラなど一部のみが対応しています。対応コントローラの詳細はカーネルバージョンによって変わる可能性があるため、正確な情報は最新のカーネルドキュメントで確認することをおすすめします。

参考リンク

• Control Group v2 — The Linux Kernel documentation（No Internal Process Constraint、PSI などの章）
• cgroups(7) — Linux manual page
• systemd: The cgroup delegation

[claude]

関連ノート: #65

[claude]

関連ノート: #66