containerd は、ホスト上のコンテナのライフサイクル全体を管理するコンテナランタイムです。イメージの転送と保存、コンテナの実行と監視、低レベルのストレージとネットワークのアタッチを担当します。ほとんどのマネージド Kubernetes サービスで、そして Docker 自体でも、デフォルトのランタイムとして使われています。

仕組み

containerd は各ノードでデーモンとして動作し、gRPC API を公開します。Kubernetes の kubelet（Container Runtime Interface（CRI）経由）や Docker Engine など、上位のシステムは、これを使ってイメージを pull し、コンテナを起動します。実際のプロセス実行は、低レベルのランタイム（通常は runc）に委譲するため、containerd は namespace や cgroup の仕組みではなく、ライフサイクル管理に集中できます。

主要な概念

• Image（イメージ） — レジストリから pull される、不変でレイヤー化されたファイルシステムのバンドルです。
• Snapshot（スナップショット） — containerd が、イメージのレイヤーから実行中のコンテナ用に構築する、コピーオンライトのファイルシステムです。
• Task（タスク） — コンテナの実行中のインスタンスで、OS レベルのプロセスに支えられています。
• Namespace — containerd 独自のもので、Kubernetes の namespace とは別物です。同じホスト上の異なるクライアントに属するコンテナとリソースを分離します。

チームが containerd に頼る理由

• 最小限で集中している。 CLI、ビルドツール、オーケストレーションをまとめて提供するのではなく、コンテナのライフサイクル管理という 1 つの仕事をうまくこなします。
• CRI ネイティブ。 Kubernetes の Container Runtime Interface を直接実装しているため、kubelet は追加の shim レイヤーなしで通信できます。
• 実戦で実証済み。 本番環境の Kubernetes クラスターの大多数で、内部のランタイムとして使われています。
• graduated な CNCF プロジェクト。 ガバナンスとセキュリティの実践は、Kubernetes 自体をホストしているのと同じ財団によって審査されています。

はじめに

ほとんどのマネージド Kubernetes プラットフォームでは、containerd はすでに設定済みのランタイムであり、インストールするものは何もありません。直接設定する必要がある場合（セルフマネージドクラスター、ベアメタルノード、nerdctl を使ったローカル開発）には、以降のガイドで一般的な構成を説明します。