kubelet から見た高レベルランタイム(Docker/containerd/CRI-O)の使い分け

[hiramekun]

[claude]

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

---

概要

kubelet はコンテナを直接操作せず、CRI (Container Runtime Interface) という gRPC の標準インターフェース越しに「高レベルランタイム」へ指示を出します。Docker・containerd・CRI-O はいずれもこの高レベルランタイムの役割を担える(あるいは担っていた)実装ですが、成り立ちと設計思想が異なります。

flowchart TB
    Kubelet["kubelet"]
    CRI{{"CRI(gRPC)"}}
    subgraph HighLevel["高レベルランタイム"]
        Containerd["containerd\n(CRI plugin 内蔵)"]
        CRIO["CRI-O\n(K8s専用・軽量実装)"]
        Dockershim["dockershim(廃止済み)\n→ Docker Engine"]
    end
    Runc["runc など低レベルランタイム"]

    Kubelet -->|"RunPodSandbox/CreateContainer等"| CRI
    CRI --> Containerd
    CRI --> CRIO
    CRI -.->|"K8s 1.24で削除"| Dockershim
    Containerd --> Runc
    CRIO --> Runc
    Dockershim --> Runc

Loading

• containerd: 元々 Docker Engine の内部コンポーネントだった部分を CNCF に寄贈し独立させたランタイム。CRI plugin を内蔵しており、kubelet と直接 gRPC で会話できる
• CRI-O: Kubernetes 専用に、Red Hat 主導で一から設計されたランタイム。CRI 仕様を満たす最小限の機能だけを持つ
• Docker: 元々は kubelet から直接 CRI 経由で呼び出せなかった(Docker 自身は CRI を実装していない)。dockershim という変換アダプタを kubelet 側に同梱することで対応していたが、Kubernetes 1.20 で非推奨化、1.24 で削除された。現在は Kubernetes ノード上の高レベルランタイムとして Docker を直接使うことはできない

低レベルランタイム(runc など)や OCI・CRI の仕組み自体は #74 で詳しく解説しています。

何が嬉しいのか

CRI という標準 API がある目的は、kubelet 本体を変更せずにランタイム実装を差し替え可能にすることです。この文脈で 3 つの選択肢がどう使い分けられるかを整理すると:

• containerd を選ぶ理由: 最も広く採用されているデファクトスタンダード。GKE・EKS・AKS などマネージド Kubernetes のデフォルトランタイムであり、ロードマップも活発。特別な理由がなければまずこれを選べば間違いない
• CRI-O を選ぶ理由: Kubernetes だけに特化して不要な機能を持たないため、攻撃対象領域(attack surface)が小さく、Kubernetes バージョンとの対応関係が明確。OpenShift のデフォルトランタイムとして採用されており、Kubernetes 専用クラスタでの堅牢性・シンプルさを重視する場合に選ばれる
• Docker を(ノード上のランタイムとして)使わない理由: Docker Engine は「イメージビルド」「Docker CLI」「ネットワーキング」などコンテナ実行以外の機能を多く抱えた重量級のツールで、Kubernetes が実際に必要とするのはその中の「コンテナ実行」部分だけ。dockershim という変換層は保守コストが高く、Kubernetes 側で Docker 内部の変更に振り回される密結合の問題があった。containerd を切り出したのはこの問題を解消するためでもある

つまり、Docker はローカル開発環境(Docker Desktop など)やイメージビルドの文脈では依然として広く使われる一方、Kubernetes ノード上の CRI 実装としては現在使われない、という整理になります。

詳細

	Docker (Engine)	containerd	CRI-O
CRI 対応	非対応(過去は dockershim 経由)	標準で対応(CRI plugin 内蔵)	標準で対応(CRI 専用に設計)
出自	dotCloud/Docker社が開発	Docker から分離・CNCF 卒業プロジェクト	Kubernetes 向けに新規開発(Red Hat 主導、CNCF 卒業)
スコープ	イメージビルド・CLI・ネットワーク・ボリューム等を含む総合ツール	コンテナ実行に特化したランタイムデーモン	Kubernetes 用途に絞った最小構成のランタイム
低レベルランタイム	containerd → runc	runc(差し替え可)	runc(差し替え可)
主な用途	ローカル開発、CI でのイメージビルド	Kubernetes ノードのデフォルト(GKE/EKS/AKS 等)	OpenShift 等、Kubernetes 専用クラスタ
Kubernetes での現状	直接は使用不可(dockershim は 1.24 で削除)	事実上のデフォルト	セキュリティ重視の代替選択肢

なぜ Docker は CRI を実装しなかったのか

Docker はコンテナ管理の総合的なツールとして、ユーザー向け CLI・イメージビルド・compose 機能など Kubernetes が必要としない機能を多く含んでいます。Kubernetes コミュニティは Docker に CRI 実装を求めましたが対応されず、kubelet 側に「CRI リクエストを Docker API 呼び出しに変換する」dockershim を実装して橋渡ししていました。しかし:

• dockershim は Kubernetes 側のメンテナンスコストになっていた
• Docker の内部が containerd + runc という構成になったことで、「kubelet → dockershim → Docker Engine → containerd → runc」という不要に長い呼び出し経路になっていた
• containerd が CRI plugin を内蔵したことで、この経路を「kubelet → containerd → runc」に短縮できるようになった

という経緯から、Kubernetes 1.20 で dockershim 非推奨化がアナウンスされ、1.24 で削除されました。ノード上で Docker イメージ(OCI 準拠)自体は問題なく動作します。影響を受けるのは「docker コマンドでノード上のコンテナを直接操作していたツール(一部の監視・ログツールなど)」であり、通常の Pod 実行には影響ありません。

移行時の注意点

• docker.sock に依存するツール(例: 一部の DaemonSet 型のログ収集エージェント)は、containerd の場合は containerd.sock、CRI-O の場合は crio.sock に向き先を変える必要がある
• デバッグ時は docker ps の代わりに crictl ps(CRI 共通の CLI)を使うと、ランタイムに依存せずノード上のコンテナ状態を確認できる
• CRI-O はマイナーバージョンを Kubernetes のマイナーバージョンに合わせてリリースしており、v1.28.x は Kubernetes 1.28 用、というようにバージョン対応が明確

参考リンク

• Kubernetes 公式: Container Runtimes
• Kubernetes Blog: Dockershim の削除について(FAQ)
• containerd 公式サイト
• CRI-O 公式サイト
• Kubernetes 公式: Container Runtime Interface (CRI)

関連ノート

• kubelet・CRI・OCI・runc(低レベルランタイム)の関係性 #74 kubelet・CRI・OCI・runc(低レベルランタイム)の関係性 — kubelet・CRI・OCI・runc(低レベルランタイム)の関係性 #74 : CRI・OCI を含めた層構造全体を解説したノート。本ノートはその中の「高レベルランタイム」の各実装の違いにフォーカスしています

---

進行状況

• 既存 issue の重複・関連確認(kubelet・CRI・OCI・runc(低レベルランタイム)の関係性 #74 を確認、重複ではなく関連)
• リクエスト内容の把握
• 解説コメントの作成
• タイトル編集
• ラベル付与
• 関連 issue (kubelet・CRI・OCI・runc(低レベルランタイム)の関係性 #74) への相互リンク

すべて完了しました。kubelet から見た高レベルランタイムとして Docker・containerd・CRI-O の役割の違いと使い分けについてまとめました。コード変更はありません。

[hiramekun]

@claude 今も cri-dockerd を使えば Kubernetes 上で Docker を使えるんじゃないの？

[claude]

Claude finished @hiramekun's task in 54s —— View job

---

はい、ご指摘の通りです。おっしゃる通り cri-dockerd を使えば、現在でも Kubernetes ノード上で Docker Engine をランタイムとして使い続けることができます。前回のコメントで「Kubernetes ノード上の CRI 実装としては現在使われない」と書いたのは正確ではなかったので補足します。

cri-dockerd とは

cri-dockerd は、削除された dockershim のコードを Kubernetes 本体の外に切り出し、Mirantis が中心となって(Docker 社とも協業しつつ)独立したプロジェクトとしてメンテナンスしている CRI shim です。

flowchart LR
    Kubelet["kubelet"] -->|CRI gRPC| CriDockerd["cri-dockerd"]
    CriDockerd -->|Docker Engine API| Docker["Docker Engine (dockerd)"]
    Docker --> Containerd["containerd"]
    Containerd --> Runc["runc"]

Loading

• 役割としては dockershim とほぼ同じで、「CRI リクエスト → Docker Engine API 呼び出し」への変換を担う
• 呼び出し経路は kubelet → cri-dockerd → dockerd → containerd → runc となり、以前の dockershim 経由の構成と同様に階層が一段増える
• リポジトリ: https://github.com/Mirantis/cri-dockerd 。2026年時点でもリリースが継続されており(直近では v0.4.x 系)、CRI 準拠性テストも通している、と Mirantis 側は説明しています
• Docker Desktop や Mirantis Container Runtime (MCR, 旧 Docker Enterprise Edition) でも同梱・利用されています

まとめると

• kubelet 本体・Kubernetes コミュニティが標準サポートするか → いいえ。dockershim が Kubernetes 本体から削除された経緯(前回コメント参照)は変わらず、Kubernetes プロジェクトとしては containerd / CRI-O を推奨しています
• サードパーティのアダプタを追加すれば Docker を使い続けられるか → はい。cri-dockerd をノードにインストールし、kubelet の --container-runtime-endpoint を cri-dockerd のソケット(unix:///var/run/cri-dockerd.sock など)に向けることで、Docker Engine を CRI 経由で使い続けられます

なので「今も Docker を使えるか」という問いには、Kubernetes 本体の標準機能としては不可、cri-dockerd という外部アダプタを追加すれば可能 というのが正確な回答になります。当時 dockershim が問題視された「保守コストの高さ・呼び出し経路の冗長さ」自体は cri-dockerd でも変わらないため、特別な理由(既存の Docker 依存ツールがある、など)がない限りは今も containerd や CRI-O が推奨されます。

参考リンク

• Mirantis/cri-dockerd (GitHub)
• cri-dockerd 公式サイト
• Mirantis Blog: The Future of Dockershim is cri-dockerd
• Kubernetes 公式: Container Runtimes

不確実な点として、cri-dockerd のメンテナンス活発度については情報源によって評価が分かれています(公式ブログは「安定してメンテナンスされている」としていますが、GitHub 上には「十分にメンテナンスされていないのでは」という懸念コメントも見られます)。本番導入前には最新の Issue やリリース状況をご自身でも確認することをおすすめします。