コンテナ

containerd こんてなでぃ

コンテナランタイムDockerKubernetesOCIruncCRI

containerdについて教えて

簡単に言うとこんな感じ！

containerd（コンテナディ）は、コンテナを動かすための「エンジンの心臓部」だよ！ Dockerの裏側で実際にコンテナを起動・停止してきた部品が独立したもので、Kubernetesもこのcontainerdをつかってコンテナをグルグル動かしてるんだ！

containerdとは

containerd（コンテナディ）は、コンテナのライフサイクル（起動・停止・一時停止・削除）を管理するコンテナランタイムです。もともとDockerの内部コンポーネントとして開発されましたが、2017年にDockerから切り出されてCloud Native Computing Foundation（CNCF）へ寄贈され、独立したオープンソースプロジェクトとして成長しました。

containerdは「コンテナを動かすための最小限の機能セット」に徹した設計になっています。イメージの取得・保存、コンテナの作成・実行、ネットワークやストレージの管理といったコア機能を提供しつつ、UIや開発者向けの高レベルなAPIはあえて持ちません。この「薄い層」としての設計思想が、Kubernetesをはじめとするオーケストレーターがcontainerdを採用する大きな理由のひとつです。

ビジネス的に重要なのは、KubernetesがDockerのサポートを終了（2022年）して以降、多くの本番環境でcontainerdが標準のランタイムになったという点です。「うちのシステムはDockerで動いています」という説明を聞いたとき、正確には「裏側でcontainerdが動いているかもしれない」と理解しておくと発注・選定の判断に役立ちます。

containerdの構造と役割

コンテナ技術は「層（レイヤー）」で成り立っています。containerdはその中間層を担います。

層	代表的な技術	役割
オーケストレーション層	Kubernetes / Docker Compose	複数コンテナの配置・スケール管理
コンテナランタイム上位層	containerd	イメージ管理・コンテナライフサイクル管理
コンテナランタイム下位層	runc	OSの機能（cgroups/namespace）を呼び出して実際にプロセスを隔離・起動
OS・カーネル層	Linux Kernel	cgroups・namespaceなどのコンテナ基盤機能

覚え方：「監督・現場監督・職人」の三層構造

Kubernetes = 監督（全体の采配を振る）
containerd = 現場監督（各コンテナの段取りと管理）
runc = 職人（実際に手を動かしてコンテナを作る）

この三層を押さえると、「DockerとKubernetesとcontainerdの関係がわからない」という混乱が解消されます。

containerdの主な機能

イメージ管理：Docker Hub などのレジストリからイメージをpull・pushする
コンテナ管理：コンテナの作成・起動・停止・削除
スナップショット管理：コンテナのファイルシステム層を管理
CRI対応：KubernetesのContainer Runtime Interface（CRI）を実装し、Kubernetesから直接呼び出せる
名前空間サポート：複数のテナントやシステムを論理的に分離して管理

歴史と背景

2013年 — Dockerが登場。コンテナ技術を一般化
2016年 — Dockerがコンテナランタイム部分を「containerd」として分離・公開
2017年3月 — containerdをCNCFに寄贈。Kubernetes・Prometheusと並ぶCNCFの中核プロジェクトに
2018年 — Kubernetes 1.10でcontainerdのCRI（Container Runtime Interface）が安定版として採用
2019年2月 — containerd 1.0がGraduated（卒業）プロジェクトに昇格。本番利用の信頼性が公式に認められる
2020年頃〜 — AWSのEKS・Google GKEなどのマネージドKubernetesがcontainerdをデフォルトランタイムとして採用開始
2022年 — KubernetesがDockerShimのサポートを正式終了。containerdが事実上の標準ランタイムへ

DockerとcontainerdとKubernetesの関係

「DockerとKubernetesは別物？」「containerdはどこに入るの？」という混乱を整理します。

Dockerを使う場合とKubernetesを使う場合の違い

利用場面	呼び出し経路
`docker run` で起動	Docker CLI → dockerd（Dockerデーモン）→ containerd → runc
Kubernetesでデプロイ	kubelet → containerd（CRI経由）→ runc

ポイント： Kubernetesは直接containerdを呼び出します。Dockerのデーモン（dockerd）は経由しません。これがKubernetesがDocker依存から脱却できた理由です。

containerd vs 他のコンテナランタイム比較

ランタイム	特徴	主な採用先
containerd	軽量・高信頼・CNCF卒業済み	Kubernetes標準、EKS、GKE
CRI-O	Kubernetes専用に設計。さらに薄い	OpenShift
Docker Engine	開発者向けフル機能。containerdを内包	ローカル開発環境
gVisor	セキュリティ重視のサンドボックス型	高セキュリティ要件の環境

規格・仕様	内容
OCI Runtime Spec	コンテナの実行仕様（runcが実装）
OCI Image Spec	コンテナイメージの形式仕様。containerdが準拠
CRI（Container Runtime Interface）	KubernetesがコンテナランタイムをgRPCで呼び出すためのAPI仕様
OCI Distribution Spec	コンテナレジストリとのイメージ転送プロトコル仕様