containerd と runC の違いとは？
コンテナ技術に触れると、「containerd」と「runC」という言葉をよく目にするはず。でも、違いを聞かれると「どちらもコンテナを動かすもの？」くらいの理解になりがちですよね。
実はこの2つ、役割が全然違う んです。ざっくり言うと、containerd は「管理者」、runC は「作業者」 みたいな関係。どんな仕組みなのか、一緒に見ていきましょう！
containerd と runC の役割の違い
まず、それぞれの役割を整理するとこんな感じです。
containerd：コンテナのライフサイクル管理（作成・開始・停止・削除）を担当する
runC：コンテナを実際に起動・実行する
もう少し詳しく言うと…
🏗 containerd は「コンテナの管理者」
containerd はコンテナを管理するためのツールで、主に以下のようなことをしています。
(1) コンテナの作成・管理
新しくコンテナを作ったり、動かしたり、消したりする
(2) イメージ管理コンテナの元となるイメージ（テンプレートみたいなもの）を取得・保存する
(3) API を提供Kubernetes などのシステムが containerd を使ってコンテナを操作できるようにする
イメージとしては、「現場の監督」のような存在ですね。
「このコンテナを作って！」とか「このコンテナを止めて！」みたいな指示を出す役割です。
⚙ runC は「コンテナの作業者」
runC はコンテナを実際に起動するツールです。
(1) コンテナのプロセスを起動
コンテナの内部でアプリケーションを実際に動かす
(2) 低レベルな実装Linux の機能（Namespaces や cgroups）を使ってコンテナを隔離
つまり、containerd から「このコンテナを動かして！」と指示を受けて、実際に作業するのが runC です。
まさに「現場の作業員」のような存在ですね。
containerd と runC の関係性をイメージで理解
containerd と runC はそれぞれ単独で動くものではなく、containerd が runC を利用してコンテナを実行 しています。
例えば、Docker や Kubernetes がコンテナを動かすときの流れを考えてみましょう。
🛠 Docker の場合
Docker CLI → Docker Engine → containerd → runC → Linux Namespaces & cgroups
Docker コマンドを実行すると、裏側では containerd がコンテナを管理し、runC がコンテナを起動します。
🏗 Kubernetes の場合
Kubernetes (kubelet) → containerd → runC → Linux Namespaces & cgroups
Kubernetes でも、containerd がコンテナ管理を担当し、実際のコンテナ実行は runC が行っています。
つまり、Docker でも Kubernetes でも、最終的には containerd と runC のコンビが動いている ということですね。
まとめ
最後に、もう一度整理すると…
containerd は「管理者」 → コンテナの作成・管理・API の提供を担当
runC は「作業者」 → 実際にコンテナを起動・実行する
containerd は runC を使ってコンテナを動かす
Docker も Kubernetes も containerd / runC を使ってコンテナを動かしている
イメージとしては、containerd が「現場監督」、runC が「作業員」 という関係です。
こう考えると、それぞれの役割がしっくりきますね！