containerdは、コンテナのライフサイクル全般を司る高レベルなコンテナランタイムです。2015年にDocker社内でDocker Engineの中核機能を切り出す形で開発が始まり、2016年に独立プロジェクトとして公開、2017年3月にCloud Native Computing Foundation（CNCF）へ寄贈されました。2019年にはCNCF卒業プロジェクトに昇格し、現在ではKubernetesの標準コンテナランタイムとして、Docker Desktop、Google GKE、Amazon EKS、Azure AKSなど主要なクラウド基盤で採用される土台技術となっています。
この記事の目次
- イメージ・実行・ストレージの三役
- Docker分割からCNCF卒業まで
- K8sノードでの典型運用
- Docker Engineとの違い
- まとめ
イメージ・実行・ストレージの三役
containerdが担う仕事は大きく分けてイメージ管理、コンテナ実行、ストレージとネットワークの仲介の3つです。OCI Image SpecとOCI Runtime Specに準拠したコンポーネントとして設計され、イメージのpull/push、レイヤーの展開、スナップショットの作成、低レベルランタイムであるruncへの実行依頼、そしてプロセスの監視・再起動・削除までをgRPC APIで提供します。Docker Engineが提供してきた機能のうち、ビルドやネットワーク作成といった高レベル機能を除いた中核部分が、ほぼそのままcontainerdとして独立した格好です。
アーキテクチャ的にはデーモン（containerdプロセス）とCLIツール（ctr、後述のnerdctl）に分かれ、プラグインで拡張できる構造を採用しています。snapshotter（overlayfs、btrfs、ZFSなど）、runtime（runc、kata-runtime、gVisorなど）、CRIプラグイン（Kubernetes連携）といった主要機能が差し替え可能で、クラウド事業者がそれぞれの環境に合わせてカスタムビルドを提供しやすい構造となっています。
Docker分割からCNCF卒業まで
containerdの歴史はDockerモノリス分割の歴史でもあります。2015年、Docker社のCTOソロモン・ハイクスらは、Docker Engineが肥大化しつつあることへの対応として、中核部分を別プロセスに切り出す方針を打ち出しました。翌2016年にcontainerd 0.2.xがリリースされ、2017年3月にDocker、IBM、Google、Alibabaらの協力のもとCNCFへ寄贈されました。2017年12月の1.0リリースを経て、2019年2月にはEnvoy、Prometheus、Kubernetesに次ぐCNCF卒業プロジェクトに認定されています。
決定的だったのは2020年12月のKubernetes 1.20でのdockershim非推奨化アナウンスです。Kubernetesは長らくkubeletからDocker Engineを呼び出すためのdockershimという橋渡し層を抱えていましたが、1.24（2022年5月）でこれを完全に削除しました。結果として、Kubernetes本体はCRI（Container Runtime Interface）に準拠したランタイム、つまりcontainerdまたはCRI-Oを直接利用する構成に揃い、containerdは事実上の業界標準ランタイムとして定着しました。
K8sノードでの典型運用
実運用上のcontainerdは、Kubernetesノード上で常駐デーモンとして動作するケースが圧倒的多数です。kubeletからのCRI gRPC呼び出しを受け、PodごとのSandbox（pauseコンテナ）と各アプリコンテナを起動し、ログをstreaming serverに流し、OOMやクラッシュをkubeletに通知します。イメージはcontainerdが直接レジストリへアクセスして取得し、overlayfsのスナップショットとしてノードに展開します。Dockerデーモンを介さないため、起動が高速でメモリフットプリントも小さいのが利点とされています。
管理者がノード上で直接操作したい場面では、付属CLIのctrか、Docker互換のCLIであるnerdctlを利用します。ctrはデバッグ向けで人間に優しいとは言い難い設計ですが、namespaceや低レベルAPIに直接触れるためトラブルシュートには有用です。一方nerdctlはdockerコマンドとほぼ同じサブコマンド体系を持ち、nerdctl psやnerdctl logsでDockerと同じ感覚で操作できます。Docker Desktop 4.0以降では内部のコンテナランタイムをcontainerdへ移行するオプションが既定化されつつあります。
Docker Engineとの違い
containerdとDocker Engineは「親子であり兄弟でもある」関係です。Docker EngineはcontainerdをラップしてビルドキットやDocker Compose連携、ネットワーク作成APIなど開発者向けの利便性をまとめた製品であり、containerdはその中核ランタイムとして共有されています。言い換えると、Docker Engineを使う環境はcontainerdを使う環境の上位集合であり、CRI-OやPodmanとは異なる立ち位置にあります。
サーバ／クラウド側ではcontainerdの直接利用が主流になりつつあります。GKEは2019年からノードOSのデフォルトをDocker EngineからcontainerdへMigrationし、EKSも2023年にKubernetes 1.24以降のノードでcontainerdを既定化、AKSも2022年から段階的に移行しました。開発者ローカルではDocker Desktopが使い勝手で優位を保つ一方、本番Kubernetesノードはcontainerdが標準という二極化が、現在のコンテナエコシステムの姿となっています。
まとめ
containerdはDockerモノリスから派生し、CNCF寄贈・卒業を経てKubernetesの標準ランタイムとなった存在です。OCI仕様準拠と高い拡張性を武器に、クラウド事業者からエッジ環境まで幅広く普及しました。Docker Engineと役割を分担しつつ、コンテナ実行の土台を支える基盤技術として理解しておくと、現代のクラウド構成図がぐっと読みやすくなります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント