コンテナの正体：namespace と cgroup の原理

「箱」の中身を開けてみる

コンテナを起動すると、その中ではプロセス番号 1 から始まる独自のプロセス表が見え、専用の IP アドレスを持ち、ホストとは別のファイルツリーが広がっています。一見すると小さな OS が動いているようですが、ホスト側で ps を打つと、その「コンテナ内のプロセス」がホストのプロセス一覧にそのまま並んでいます。つまりコンテナは別のマシンでも軽量な仮想マシンでもなく、ホストのカーネルが直接スケジュールしている、ただの Linux プロセスです。

VM が CPU 命令レベルで別のカーネルを動かすのに対し、コンテナにはゲストカーネルが存在しません。違いの詳細は /devops/container-vs-vm/ にありますが、本稿ではその「壁」を作っている2つのカーネル機構——namespace（隔離） と cgroup（制限）——を内部から見ていきます。

namespace：資源の「見え方」を分ける

namespace はカーネルが管理する各種グローバル資源を、プロセスごとに別々のインスタンスに見せかける仕組みです。資源を分割するのではなく、どの集合が見えるか を切り替えます。clone(2) / unshare(2) / setns(2) の3つのシステムコールで作成・参加します。

要点は、namespace が 入れ子と写像 で成り立っていることです。たとえば PID namespace では、コンテナの「PID 1」はホストから見れば PID 1万番台のごく普通のプロセスです。カーネルは1つのプロセスに対し、所属する各 PID namespace ごとに異なる番号を割り当てて管理しています。

MNT namespace と組み合わせて使うのが pivot_root(2) です。コンテナイメージを展開したディレクトリを新しいルート / に差し替えることで、ホストのファイルツリーから切り離します（古い chroot の強化版に相当）。NET namespace では、ホスト側に作った仮想イーサネットペア（veth）の片端をコンテナの namespace へ移し、もう片端をブリッジへ繋ぐことで通信経路を構築します。

cgroup v2：資源の「使える量」を配る

namespace が可視性を制御するのに対し、cgroup（control group）は 資源の量 を制御します。v1 は資源ごとに独立した階層を持ち管理が煩雑でしたが、v2 では単一の統一階層 に一本化され、すべてのコントローラが同じツリー構造を共有します。プロセスは末端（リーフ）の cgroup にのみ所属できる、というルールが整合性を保ちます。

cgroup は /sys/fs/cgroup 配下の擬似ファイルシステムとして見え、ディレクトリを mkdir すれば cgroup が1つ生まれ、cgroup.procs に PID を書き込めばそのプロセスが所属します。主要コントローラは次のように働きます。

# メモリ上限を 512MiB に設定（cgroup v2）
echo "536870912" > /sys/fs/cgroup/myapp/memory.max

# CPU を「100ms 周期のうち最大 50ms」= 0.5 コア相当に制限
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max

# プロセスをこの cgroup に所属させる
echo $PID > /sys/fs/cgroup/myapp/cgroup.procs

• CPU：cpu.max の quota period 形式で、各周期に使える時間を上限化（CFS バンド幅制御）。さらに cpu.weight で空き時間の比例配分を決めます。上限到達時はプロセスがスロットリングされ、待たされます。
• メモリ：memory.max がハードリミット。これを超えて確保しようとすると、まず回収（reclaim）が走り、それでも足りなければ cgroup 単位の OOM killer が内部のプロセスを停止します。memory.high を併用するとソフトリミット（超過時に積極的に reclaim しつつ即死は避ける）を設定できます。
• I/O：io.max でブロックデバイス単位の IOPS・帯域を制限。io.weight で比例配分します。

なぜ「軽量VM」ではないのか

ここまでで核心が見えます。コンテナは 新しいカーネルを起動していません。namespace で見える資源を絞り、cgroup で使える量を絞った、ホストカーネル上の普通のプロセスです。だからこそ起動はミリ秒で、メモリも数十 MB から済みます。一方で代償もあります。

この前提が、コンテナ運用の作法を規定します。状態を内部に持たず使い捨てにする発想（/devops/immutable-infra/）や、1コンテナ1責務でスケールさせる /devops/microservices/ の設計は、いずれも「コンテナ＝制約付きプロセス」という正体から自然に導かれます。

観測：制約の中身を覗く

コンテナの内部状態は、結局カーネルのインターフェース越しに観測します。cgroup の memory.current / cpu.stat（throttled_usec を含む）/ io.stat を読めば、その瞬間の消費と制限到達状況が分かります。プロセス単位やシステムコール単位でさらに踏み込むなら、カーネルにフックを仕掛ける /devops/ebpf-observability/ が強力です。いずれにせよ、コンテナを「ブラックボックスの小さなマシン」ではなく「カーネルが管理する名前空間と制御群の組」として捉えると、観測も制限もデバッグも一本の筋で理解できます。