OCIランタイムとコンテナ起動シーケンス（runc/containerd）

docker run や kubectl run の一行の裏で、イメージのダウンロードからアプリのプロセスが立ち上がるまでには、明確に役割分担された複数のコンポーネントが連携しています。コンテナがカーネルの namespace と cgroup でできていること自体は /devops/container-vs-vm/ で扱いました。本稿はその一段下、OCI 仕様が定める形式と手順に沿って、誰が何を担い、clone() からどう起動するかを追います。

OCI の2つの仕様

OCI（Open Container Initiative）の標準は、混同されがちですが2つに分かれます。

• Image Spec: イメージの保存形式。manifest（どのレイヤーと config を含むか）、複数の レイヤー（tar+gzip の差分）、config（環境変数・エントリポイント等のメタデータ）で構成され、すべてが コンテンツアドレッサブル（SHA256 ダイジェストで参照）です。
• Runtime Spec: 「展開済みのコンテナ」をどう起動するかの手順。入力はバンドルと呼ばれるディレクトリで、中身は rootfs/（展開済みファイルシステム）と config.json（namespace・mount・cgroup・capability などの実行設定）の2つだけです。

この2つの間には溝があります。Image Spec のレイヤーは「重ねて使う差分」であり、そのままでは起動できません。レイヤーを順に展開して1枚の rootfs にし、image config から config.json を生成する——この変換を担うのが containerd です。

階層的な責務分担

Docker や Kubernetes の標準的なスタックは、上から下へこう並びます。

なぜ shim という中間層が要るのか。それはライフサイクルの寿命を分離するためです。もし containerd が直接コンテナプロセスの親だと、containerd を再起動・アップグレードしただけで全コンテナが孤児化したり巻き添えで死んだりします。コンテナごとに独立した shim を親に置くことで、containerd が落ちてもコンテナは生き続け、復帰後に shim 経由で状態を再取得できます。shim はまた、コンテナの標準入出力を保持し、終了コードを記録しておく役目も負います。

runc は起動して、すぐ消える

ここが直感に反する重要点です。runc create / runc start を実行すると runc プロセスが動きますが、コンテナの実行中ずっと runc が常駐するわけではありません。runc は namespace と cgroup をセットアップし、コンテナの init プロセスを execve で起動したら、その役目を終えて終了します。

実行中のコンテナの「init プロセス（PID 1）」の親は、runc ではなく shim です。つまり runc は使い捨ての設定係であり、実行中の見張りは shim が担います。この設計のおかげで、何百個コンテナが動いていても runc プロセスが何百個も常駐することはありません。

clone() から execve まで

runc が config.json を受け取ってからアプリのプロセスが立ち上がるまでの核心を、原理レベルで追います。本質は 新しい namespace の中に入り、隔離環境を整え終えてから execve するという順序です。

namespace の作成と参加には2系統あります。

• clone() / unshare(): CLONE_NEWPID や CLONE_NEWNS などのフラグを与え、新しい namespace を作って子プロセスをその中で生成する。
• setns(): すでに存在する namespace（例: Pod 内で共有するネットワーク namespace）に既存プロセスを参加させる。

runc は内部で C コードの段階（nsexec）を二段階フォークで通過します。PID namespace は特殊で、clone() を呼んだプロセス自身は新 PID namespace に入らず、その子が PID 1 になるため、正しく「コンテナ内 PID 1」を作るには追加のフォークが必要だからです。概念的な順序は次の通りです。

1. config.json を解析（namespace・mount・cgroup・capability の一覧を取得）
2. clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWNET|CLONE_NEWUTS|CLONE_NEWIPC ...)
   → 新しい namespace 群の中に子プロセスを生成
3. （子の中で）cgroup に自プロセスを加入させ、CPU/メモリ上限を適用
4. rootfs を準備：bind mount を張り、pivot_root で rootfs を新しい「/」に切替
5. /proc, /sys, /dev など必要な擬似ファイルシステムをマウント
6. capability を絞り込み、no_new_privs をセット、seccomp フィルタを適用
7. setuid/setgid でコンテナ内ユーザーに降格
8. execve(エントリポイント) → ここで runc のコードは消え、アプリ本体に置き換わる

ステップ4の pivot_root が「コンテナからホストのファイルシステムが見えない」理由の中核です。mount namespace の中でルートを rootfs に挿げ替え、元のルートをアンマウントすることで、コンテナはホストの / へ遡れなくなります（chroot より堅牢で、抜け出しにくい）。

shim を介した状態管理と終了

execve でアプリ（init プロセス）が走り出すと、その親は shim です。shim はコンテナの終了を waitpid で待ち受け、終了コードを保持します。docker ps で停止済みコンテナの exit code が見えるのは、shim（が containerd に渡した情報）のおかげです。

Kubernetes ではこの低レベルランタイムを kubelet が直接叩くのではなく、CRI（Container Runtime Interface）という gRPC API を介して containerd / CRI-O に依頼します。kubelet は「この Pod を起動せよ」と CRI で要求し、containerd が Pod 内コンテナぶんのバンドルを作って runc を呼ぶ——という分業です。この標準化のおかげで、ランタイムを差し替えても上位の Kubernetes 側は無改変で動きます。

まとめ：層を貫く一本の道

整理すると、docker run から始まる一連は次のように流れます。

1. containerd: イメージを pull し、レイヤーを展開して rootfs を作り、image config と実行指定を合成して config.json を生成。バンドルが完成。
2. shim: コンテナごとに起動し、runc を呼び出す親プロセスとなる。containerd の寿命からコンテナを切り離す。
3. runc: config.json を解釈し、clone() で namespace を作り、cgroup 加入・pivot_root・capability 制限・seccomp を順に適用してから execve。設定が済むと runc は退場。
4. アプリ: コンテナ内 PID 1 として走り、親の shim が終了を見届ける。

この分業は単なる実装都合ではなく、寿命の分離（shim）・標準化（OCI/CRI）・最小権限の確実な適用（runc の順序） という設計目標の現れです。なぜ containerd を再起動してもコンテナが死なないのか、なぜランタイムを crun に差し替えられるのか、なぜ起動失敗が「pull」「mount」「exec」のどの段で起きたか切り分けられるのか——その根拠はすべてこの階層構造にあります。コンテナの不変性を前提にしたデプロイ思想（/devops/immutable-infra/）や、イメージを成果物として扱う CI/CD（/devops/ci-cd/）も、この再現可能な起動経路の上に成り立っています。