kubelet・CRI・OCI・runc(低レベルランタイム)の関係性

[hiramekun]

[claude]

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

---

概要

Kubernetes のノード内で「コンテナを動かす」処理は、役割の異なる複数の層に分かれています。

• kubelet: 各ノードで動く Kubernetes のエージェント。PodSpec を見て「どんなコンテナを動かすべきか」を判断する司令塔で、実際のコンテナ操作はしない
• CRI (Container Runtime Interface): kubelet と「コンテナランタイム」の間の標準 API(gRPC)。kubelet はこのインターフェース越しにしかコンテナ操作を要求しない
• 高レベルランタイム(containerd, CRI-O など): CRI を実装するデーモン。イメージの pull・ストレージ管理・コンテナのライフサイクル管理を担当し、実際のプロセス起動は低レベルランタイムに委譲する
• OCI (Open Container Initiative): コンテナの「イメージ形式」と「ランタイムの振る舞い」を定めた業界標準仕様(Runtime Spec / Image Spec など)
• 低レベルランタイム(runc, crun, runsc, kata-runtime など): OCI Runtime Spec を実装する実行エンジン。namespace・cgroup の作成や pivot_root など、実際に Linux カーネルの機能を呼び出してコンテナプロセスを立ち上げる

flowchart TB
    Kubelet["kubelet(ノードエージェント)"]
    CRI{{"CRI(gRPC API)\nRuntimeService / ImageService"}}
    Containerd["containerd または CRI-O\n(高レベルランタイム: CRI実装)"]
    Shim["containerd-shim\n(コンテナごとの管理プロセス)"]
    OCISpec{{"OCI Runtime Spec\n(config.json + rootfs = OCIバンドル)"}}
    Runc["runc / crun / runsc など\n(低レベルランタイム: OCI実装)"]
    Kernel["Linuxカーネル\n(namespace, cgroup, pivot_root)"]

    Kubelet -->|"Unixソケット経由でCRI呼び出し\n(例: /run/containerd/containerd.sock)"| CRI
    CRI --> Containerd
    Containerd -->|"イメージpull・OCIバンドル生成"| Shim
    Shim -->|"create/start/kill/delete"| OCISpec
    OCISpec --> Runc
    Runc --> Kernel

Loading

何が嬉しいのか

この階層は、いずれも**「実装を差し替え可能にするための標準化」**という同じ目的を持っています。

• CRI がなかった頃は、kubelet のコード内に Docker 専用の処理(dockershim)が直接埋め込まれていました。新しいランタイムを Kubernetes に対応させるには kubelet 本体に手を入れる必要があり、Kubernetes 側も Docker の内部変更に振り回されるという密結合の問題がありました。CRI という標準 API を挟んだことで、containerd・CRI-O・(現在は使われませんが)dockershim のような実装を kubelet 側の変更なしに差し替えられるようになりました(dockershim は Kubernetes 1.24 で削除され、現在は containerd や CRI-O を直接使うのが標準です)
• OCI がなかった頃は、コンテナイメージの形式やランタイムの起動方法がツールごとにバラバラで、「Docker で作ったイメージが他のツールで動かない」といった相互運用性の問題がありました。OCI が Runtime Spec / Image Spec を標準化したことで、containerd や CRI-O は runc・crun・runsc・Kata Containers など好きな低レベルランタイムを選べるようになりました
• 実用上のメリットとして、RuntimeClass を使えば Pod ごとに低レベルランタイムを選択できます。例えば信頼できないコードは gVisor(runsc、[[gVisor(runsc)とは何か(runc との違いと使いどころ) #70]] 参照)や Kata Containers(VM ベースでさらに強い隔離)で動かし、通常のワークロードは高速な runc で動かす、という使い分けが kubelet や CRI の実装を一切変更せずに実現できます

詳細

各層の責務

層	役割	主な実装例
kubelet	Pod のスケジュール結果を見て「あるべき状態」を維持する。CRI クライアントとして動作	(Kubernetes 本体の一部)
CRI	kubelet ⇔ ランタイム間の API 仕様(Protocol Buffers で定義された gRPC)	仕様そのもの(kubernetes/cri-api)
高レベルランタイム	CRI を実装。イメージ管理・スナップショット・コンテナのライフサイクル管理・ネットワーク設定の呼び出しなど	containerd, CRI-O
OCI	コンテナの実行方法・イメージ形式の標準仕様	仕様そのもの(opencontainers/runtime-spec, image-spec)
低レベルランタイム	OCI Runtime Spec を実装。実際に namespace/cgroup を作りプロセスを起動	runc, crun, runsc([[#70]]), kata-runtime

実際の呼び出しの流れ

1. kubelet が PodSpec の差分を検知し、CRI の RuntimeService.RunPodSandbox / CreateContainer / StartContainer を gRPC で呼び出す(Unix ソケット経由)
2. containerd(または CRI-O)がイメージを pull し(OCI Image Spec に準拠したイメージ)、コンテナごとに containerd-shim プロセスを起動する
3. shim が OCI バンドル(rootfs ディレクトリ + config.json)を用意し、低レベルランタイム(runc など)を サブプロセスとして 起動して create / start を実行させる
4. runc が clone()/unshare() で namespace を作り、cgroup を設定し、pivot_root で rootfs を切り替えてコンテナプロセスを実行し、起動が終わると終了する(runc 自体はコンテナ起動中ずっと生き続けるわけではなく、shim がプロセスの監視を引き継ぐ)

namespace・cgroup そのものの仕組みは [[#65]]・[[#64]]・[[#66]] で解説しています。

用語整理でよく混乱するポイント

• 「コンテナランタイム」という言葉は文脈によって containerd(高レベル)を指すことも runc(低レベル)を指すこともあるため、CRI と OCI どちらのレイヤーの話かを意識すると混乱しにくい
• Docker は内部的に containerd → runc という同じスタックを使っているが、kubelet と直接 CRI で会話できないため、過去は dockershim という変換アダプタが必要だった
• デバッグ時は kubectl/docker ではなく、CRI を直接叩く crictl(例: crictl ps, crictl inspect)を使うと、kubelet が見ている実際のコンテナ状態を確認できる

注意点

• OCI Runtime Spec は「ランタイムがどう振る舞うべきか」の仕様であり、runc はそのリファレンス実装の一つに過ぎない。仕様と実装を混同しないよう注意
• CRI はバージョン間で API が変わることがあり(例: v1alpha2 → v1)、containerd/CRI-O 側の対応バージョンと Kubernetes のバージョンの組み合わせに注意が必要

参考リンク

• Kubernetes 公式: Container Runtime Interface (CRI)
• kubernetes/cri-api (CRI の Protocol Buffers 定義)
• Open Container Initiative: runtime-spec
• Open Container Initiative: image-spec
• containerd 公式ドキュメント
• CRI-O 公式サイト
• runc (OCI リファレンス実装)
• Kubernetes Blog: Dockershim の削除について

関連ノート

• gVisor(runsc)とは何か(runc との違いと使いどころ) #70 gVisor(runsc)とは何か(runc との違いと使いどころ) — gVisor(runsc)とは何か(runc との違いと使いどころ) #70 : 本ノートで説明した「低レベルランタイム」の具体例として、runc の代わりに差し替え可能な runsc を掘り下げたノート
• cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66 cgroup と namespace はどのように Docker のコンテナ化技術を支えているか — cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66 : 本ノートの図に出てくる runc が実際に namespace/cgroup をどう操作してコンテナを作るかを掘り下げたノート
• kind (Kubernetes IN Docker) がローカルにクラスタを構築する仕組み #13 kind (Kubernetes IN Docker) がローカルにクラスタを構築する仕組み — kind (Kubernetes IN Docker) がローカルにクラスタを構築する仕組み #13 : kubelet・containerd がノードコンテナ内で実際にどう動いているかの具体例

---

進行状況

• 既存 issue の重複・関連確認(gVisor(runsc)とは何か(runc との違いと使いどころ) #70 cgroup と namespace はどのように Docker のコンテナ化技術を支えているか #66 kind (Kubernetes IN Docker) がローカルにクラスタを構築する仕組み #13 を確認、いずれも重複ではなく関連)
• issue 内容の理解
• 関連候補の詳細確認
• 解説コメントの作成
• タイトルの編集
• ラベルの付与
• 関連 issue への相互リンク

すべて完了しました。kubelet・CRI・高レベルランタイム(containerd/CRI-O)・OCI・低レベルランタイム(runc)の 5 層の関係性と、標準化(CRI・OCI)によってランタイム実装を差し替え可能にしている狙いについてまとめました。コード変更はありません。

[claude]

関連ノート: #77