Kubernetes時代のコンテナランタイム！containerd・CRI-OとOCI標準

2025年10月1日

「Kubernetesを使い始めたけど、コンテナランタイムって何？」
「containerdとCRI-Oって聞くけど、違いがわからない…」
「OCIって何の略？なぜ標準化が必要なの？」

Kubernetesを学び始めると、こんな疑問にぶつかりませんか？

実は、Kubernetes時代に入ってから、コンテナを動かす仕組みは大きく進化しました。Dockerだけでなく、containerd、CRI-O、そしてOCI標準といった新しい技術が登場し、より柔軟で効率的なコンテナ運用が可能になっています。

この記事では、技術評論社の「［改訂新版］イラストでわかるDockerとKubernetes」を参考に、現代のコンテナランタイムの仕組みについて、わかりやすく解説していきます！

［改訂新版］イラストでわかるDockerとKubernetes (Software Design plusシリーズ)

created by Rinker

¥2,363 (2025/10/01 00:01:09時点楽天市場調べ-詳細)

Amazon

「なんとなく動いている」から「仕組みを理解して適切に選択できる」へ、一緒にレベルアップしていきましょう！

Kubernetesでコンテナランタイムが重要な理由

Dockerからの変化

少し前まで、「コンテナ = Docker」というイメージが強かったのではないでしょうか？確かにDockerはコンテナ技術を普及させた立役者ですが、Kubernetesの登場により状況は大きく変わりました。

【従来のDocker中心の世界】
┌─────────────────────────────────────┐
│           アプリケーション              │
└─────────────┬───────────────────────┘
              │
┌─────────────▼───────────────────────┐
│           Docker                    │
│    (すべてをDockerが担当)            │
└─────────────┬───────────────────────┘
              │
┌─────────────▼───────────────────────┐
│         Linux Kernel                │
└─────────────────────────────────────┘

【現代のKubernetes中心の世界】
┌─────────────────────────────────────┐
│         Kubernetes                  │
└─────────────┬───────────────────────┘
              │ CRI
┌─────────────▼───────────────────────┐
│     コンテナランタイム                │
│   (containerd / CRI-O / Docker)     │
└─────────────┬───────────────────────┘
              │ OCI
┌─────────────▼───────────────────────┐
│         低レベルランタイム            │
│           (runc等)                  │
└─────────────┬───────────────────────┘
              │
┌─────────────▼───────────────────────┐
│         Linux Kernel                │
└─────────────────────────────────────┘

CRI（Container Runtime Interface）の登場

Kubernetesが革新的だった理由の一つが、CRI（Container Runtime Interface）という標準インターフェースを導入したことです。

CRIによって、Kubernetesは特定のコンテナランタイムに依存せず、複数の選択肢から最適なものを選べるようになりました！

CRIの主な機能：

Pod（コンテナグループ）の管理
コンテナイメージの取得と管理
コンテナの実行とライフサイクル管理
ネットワークとストレージの設定

コンテナランタイムの役割

現代のコンテナランタイムは、大きく2つの層に分かれています：

高レベルランタイム（CRIランタイム）

containerd
CRI-O
Docker Engine（CRIプラグイン経由）

主な責任：

Kubernetesとの通信（CRI経由）
イメージの管理とダウンロード
コンテナのライフサイクル管理
ネットワーク設定

低レベルランタイム（OCIランタイム）

runc
gVisor (runsc)
Kata Containers

主な責任：

実際のコンテナプロセス起動
namespace・cgroupの設定
セキュリティ制御

containerdとは何か

containerdの基本概念

containerd（コンテナディー）は、Linux Foundation傘下のCNCF（Cloud Native Computing Foundation）プロジェクトで開発されている、業界標準の高レベルコンテナランタイムです。

元々はDocker Engineの一部でしたが、2017年に独立したプロジェクトとして切り出され、現在では多くのKubernetes環境で採用されています。

DockerからKubernetesへの橋渡し

containerdの最大の特徴は、Dockerの豊富な機能を持ちながら、Kubernetesに最適化されていることです。

【containerdのアーキテクチャ】
┌─────────────────────────────────────┐
│         Kubernetes                  │
└─────────────┬───────────────────────┘
              │ CRI Plugin
┌─────────────▼───────────────────────┐
│         containerd                  │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐│
│ │Image    │ │Container│ │Snapshot │││
│ │Service  │ │Service  │ │Service  ││
│ └─────────┘ └─────────┘ └─────────┘│
└─────────────┬───────────────────────┘
              │ OCI Runtime API
┌─────────────▼───────────────────────┐
│           runc                      │
└─────────────────────────────────────┘

［改訂新版］イラストでわかるDockerとKubernetes (Software Design plusシリーズ)

created by Rinker

¥2,363 (2025/10/01 00:01:09時点楽天市場調べ-詳細)

Amazon

containerdのアーキテクチャ

containerdは、モジュール化された設計が特徴です：

1. Image Service

コンテナイメージの管理を担当：

# containerdを使用したイメージ操作
$ ctr image pull docker.io/library/nginx:alpine
$ ctr image list
$ ctr image remove docker.io/library/nginx:alpine

2. Container Service

コンテナのライフサイクル管理：

# containerdでコンテナ実行
$ ctr run --rm -t docker.io/library/ubuntu:20.04 my-container bash

3. Snapshot Service

ファイルシステムのスナップショット管理：

# スナップショット確認
$ ctr snapshots list

4. CRI Plugin

KubernetesとのCRI通信を担当：

# CRIプラグインの設定確認
$ cat /etc/containerd/config.toml

[plugins.”io.containerd.grpc.v1.cri”]

[plugins.”io.containerd.grpc.v1.cri”.containerd] default_runtime_name = “runc”

containerdの実際の使用例

実際のKubernetes環境でcontainerdがどう動作するかを見てみましょう：

# Kubernetes Nodeでcontainerdのプロセス確認
$ ps aux | grep containerd
root      1234  0.1  1.5  107892  31256 ?  Sl   10:00   0:02 containerd

# containerdが管理するコンテナ一覧
$ ctr -n k8s.io containers list
CONTAINER                                                           IMAGE
k8s_nginx_nginx-deployment-abc123                                  docker.io/library/nginx:1.20
k8s_POD_nginx-deployment-abc123                                    k8s.gcr.io/pause:3.5

# containerdのメトリクス確認
$ ctr metrics

CRI-Oの特徴と役割

CRI-Oとは何か

CRI-O（クライオー）は、Red Hatが主導して開発している、Kubernetes専用に設計されたCRIランタイムです。

「CRI-O」の名前の由来は：

CRI: Container Runtime Interface
O: OCI（Open Container Initiative）

つまり、「CRIとOCIを繋ぐランタイム」という意味が込められています！

containerdとの違い

CRI-OとcontainerdはどちらもCRIランタイムですが、設計思想に大きな違いがあります：

【containerd vs CRI-O 比較】
┌─────────────────────────────────────┐
│          containerd                 │
│ ┌─────────────────────────────────┐ │
│ │    汎用的なコンテナランタイム      │ │
│ │ ┌─────────┐ ┌─────────┐ ┌───┐ │ │
│ │ │Docker   │ │Kubernetes│ │CLI││ │ │
│ │ │互換     │ │対応      │ │等││ │ │
│ │ └─────────┘ └─────────┘ └───┘ │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│            CRI-O                    │
│ ┌─────────────────────────────────┐ │
│ │   Kubernetes専用ランタイム       │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │    Kubernetes ONLY          │ │ │
│ │ │  (最小限・高性能・セキュア)   │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘

主な違い：

項目	containerd	CRI-O
設計思想	汎用的	Kubernetes専用
機能範囲	幅広い	必要最小限
パフォーマンス	高い	より高い
セキュリティ	良好	より厳格
エコシステム	豊富	シンプル

［改訂新版］イラストでわかるDockerとKubernetes (Software Design plusシリーズ)

created by Rinker

¥2,363 (2025/10/01 00:01:09時点楽天市場調べ-詳細)

Amazon

CRI-Oの設計思想

CRI-Oは「Kubernetes以外は考えない」という割り切った設計で、以下のメリットを実現しています：

1. 軽量性

不要な機能を削ぎ落とし、リソース使用量を最小化：

# メモリ使用量比較（例）
$ ps aux | grep containerd
root  1234  0.1  1.5  107892  31256  # containerd

$ ps aux | grep crio
root  5678  0.1  0.8   65432  16128  # crio (より軽量)

2. セキュリティ

Kubernetesのセキュリティモデルに特化：

# CRI-Oのセキュリティ設定
$ cat /etc/crio/crio.conf

[crio.runtime]

seccomp_profile = “/usr/share/containers/seccomp.json” apparmor_profile = “crio-default” selinux = true

3. 高速な起動

Kubernetes専用最適化により高速起動を実現：

# Pod起動時間の測定
$ time kubectl run test --image=nginx --rm -it --restart=Never -- echo "Hello"

# CRI-O: 約1.2秒
# containerd: 約1.8秒
# （環境により異なります）

CRI-Oの実際の設定例

実際のCRI-O設定ファイルを見てみましょう：

# /etc/crio/crio.conf

[crio]

storage_driver = “overlay” storage_option = [“overlay.mount_program=/usr/bin/fuse-overlayfs”]

[crio.api]

listen = “/var/run/crio/crio.sock”

[crio.runtime]

runtime = “runc” runtime_untrusted_workload = “runc” default_workload_trust = “trusted”

[crio.image]

default_transport = “docker://” pause_image = “k8s.gcr.io/pause:3.5”

[crio.network]

network_dir = “/etc/cni/net.d/” plugin_dirs = [“/opt/cni/bin/”]

OCI標準の重要性

OCIが生まれた背景

2015年頃、コンテナ技術が普及する中で大きな問題が浮上しました：

「各社が独自仕様でコンテナを実装し、互換性がない」

この問題を解決するために、Linux Foundationの下でOCI（Open Container Initiative）が設立されました。

【OCI設立前の混乱状況】
┌─────────────────────────────────────┐
│        Docker独自仕様               │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│        rkt独自仕様                  │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│       その他独自仕様                │
└─────────────────────────────────────┘
↓ 互換性なし、移行困難

【OCI設立後の統一】
┌─────────────────────────────────────┐
│          OCI標準仕様                │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐│
│ │Runtime  │ │Image    │ │Distri-  ││
│ │Spec     │ │Spec     │ │bution   ││
│ └─────────┘ └─────────┘ └─────────┘│
└─────────────────────────────────────┘
↓ 標準化により互換性確保

3つの主要仕様（Runtime・Image・Distribution）

OCIは、コンテナエコシステムの3つの重要な側面を標準化しています：

1. Runtime Specification（実行時仕様）

コンテナの実行方法を定義：

{
  "ociVersion": "1.0.0",
  "process": {
    "terminal": true,
    "user": {"uid": 0, "gid": 0},
    "args": ["/bin/bash"],
    "env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],
    "cwd": "/"
  },
  "root": {
    "path": "/var/lib/container/rootfs",
    "readonly": false
  },
  "linux": {
    "namespaces": [
      {"type": "pid"},
      {"type": "network"},
      {"type": "mount"},
      {"type": "uts"},
      {"type": "ipc"}
    ],
    "resources": {
      "memory": {"limit": 536870912},
      "cpu": {"quota": 50000, "period": 100000}
    }
  }
}

2. Image Specification（イメージ仕様）

コンテナイメージの形式を定義：

# OCI準拠のイメージ構造
$ tree oci-image/
oci-image/
├── blobs/
│   └── sha256/
│       ├── abc123...  # レイヤーデータ
│       ├── def456...  # 設定ファイル
│       └── ghi789... # マニフェスト
├── index.json        # イメージインデックス
└── oci-layout        # レイアウト情報

3. Distribution Specification（配布仕様）

イメージレジストリの API仕様を定義：

# OCI Distribution API例
GET /v2/<name>/manifests/<reference>
PUT /v2/<name>/manifests/<reference>
GET /v2/<name>/blobs/<digest>
POST /v2/<name>/blobs/uploads/

標準化によるメリット

OCI標準化により、以下のメリットが生まれました：

1. 相互運用性

# 同じイメージを異なるランタイムで実行可能
$ docker run nginx        # Docker
$ podman run nginx        # Podman
$ ctr run nginx           # containerd
$ crictl run nginx        # CRI-O

2. エコシステムの健全な発展

特定ベンダーへの依存を回避
イノベーションの促進
ユーザーの選択肢増加

3. セキュリティの向上

標準化されたセキュリティモデル
脆弱性対応の迅速化
監査の効率化

実践！コンテナランタイムの選択指針

ここまでで、現代のコンテナランタイムについて理解が深まったでしょうか？

今回学んだ要点をまとめると：

containerd: 汎用的で豊富な機能を持つCRIランタイム
CRI-O: Kubernetes専用に特化した軽量・高速なCRIランタイム
OCI: コンテナエコシステムの標準化を推進する重要な仕様
CRI: Kubernetesとランタイム間の標準インターフェース

用途別のランタイム選択

実際にどのランタイムを選ぶべきかは、用途によって異なります：

containerdが適している場合

# 開発環境での柔軟性を重視
$ docker build -t myapp .
$ kubectl run myapp --image=myapp

適用シーン：

開発環境: Dockerとの互換性重視
移行期: 既存Docker環境からの段階的移行
マルチプラットフォーム: Docker Desktop等との連携

メリット：

Docker CLI との高い互換性
豊富なエコシステム
安定した実績

CRI-Oが適している場合

# 本番環境での性能とセキュリティを重視
$ systemctl enable crio
$ kubeadm init --cri-socket=unix:///var/run/crio/crio.sock

適用シーン：

本番環境: 性能とセキュリティを最重視
エッジ環境: リソース制約の厳しい環境
セキュリティ重視: 金融・医療等の規制業界

メリット：

軽量で高速
セキュリティの強化
Kubernetes最適化

実際の選択例

パターン1：開発から本番まで一貫してcontainerd

# kubeadm設定例
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.0
criSocket: unix:///var/run/containerd/containerd.sock

パターン2：開発はDocker、本番はCRI-O

# 開発環境
$ docker build -t myapp:dev .
$ docker run -p 8080:80 myapp:dev

# 本番環境（イメージはレジストリ経由）
$ kubectl create deployment myapp --image=registry.example.com/myapp:v1.0

［改訂新版］イラストでわかるDockerとKubernetes (Software Design plusシリーズ)

created by Rinker

¥2,363 (2025/10/01 00:01:09時点楽天市場調べ-詳細)

Amazon

今後の技術動向

コンテナランタイム技術は現在も急速に進化しています：

1. セキュリティ強化

gVisor: Googleのサンドボックス化ランタイム
Kata Containers: VM級の隔離性能
Firecracker: AWS Lambdaで使用される超軽量ランタイム

# セキュリティ強化ランタイムの使用例
$ kubectl run secure-app --image=myapp --overrides='
{
  "spec": {
    "runtimeClassName": "gvisor"
  }
}'

2. WebAssembly（WASM）との統合

コンテナよりもさらに軽量
言語中立的な実行環境
エッジコンピューティングでの活用

# WASM対応ランタイムの例
$ wasmtime run app.wasm
$ runwasi app.wasm

3. unikernelとの融合

OS機能の最小化
超高速起動
セキュリティ向上

学習を継続するために

コンテナランタイム技術をさらに深く学びたい方は、以下のステップがおすすめです：

1. 実際に触ってみる

# 各ランタイムを実際にインストール・設定
$ sudo apt install containerd.io
$ sudo apt install cri-o cri-o-runc

# 設定ファイルをカスタマイズ
$ sudo vi /etc/containerd/config.toml
$ sudo vi /etc/crio/crio.conf

2. メトリクス監視

# ランタイムのメトリクス収集
$ ctr metrics
$ crictl stats
$ kubectl top nodes
$ kubectl top pods

3. トラブルシューティング

# ログ確認
$ journalctl -u containerd
$ journalctl -u crio

# デバッグ情報収集
$ crictl info
$ ctr version

さらに詳しい内容を学びたい方には、「［改訂新版］イラストでわかるDockerとKubernetes」が非常におすすめです！

この書籍では：

最新のコンテナランタイム事情を網羅的に解説
実際の設定例で実践的な知識が身につく
セキュリティやパフォーマンスの考慮点も詳しく説明
業界の最前線で活躍する著者による貴重な知見

著者の徳永航平さんは、CNCF containerdのレビュワーを務める第一線の技術者。まさにコンテナランタイム技術の専門家による解説は、皆さんの技術力向上に大いに役立つはずです！

コンテナ技術は日々進化していますが、OCI標準やCRIといった基礎概念をしっかり理解することで、新しい技術が登場しても迷わず対応できるようになります。

ぜひ、この記事をきっかけに、現代的なコンテナランタイムの世界をより深く探求してみてください！

［改訂新版］イラストでわかるDockerとKubernetes (Software Design plusシリーズ)

created by Rinker

¥2,363 (2025/10/01 00:01:09時点楽天市場調べ-詳細)

Amazon

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

Docker内部構造を理解しよう！namespace・cgroup・runcで学ぶコンテナ技術

Kubernetes時代のコンテナランタイム！containerd・CRI-OとOCI標準

Kubernetesでコンテナランタイムが重要な理由

Dockerからの変化

CRI（Container Runtime Interface）の登場

コンテナランタイムの役割

高レベルランタイム（CRIランタイム）

低レベルランタイム（OCIランタイム）

containerdとは何か

containerdの基本概念

DockerからKubernetesへの橋渡し

containerdのアーキテクチャ

1. Image Service

2. Container Service

3. Snapshot Service

4. CRI Plugin

containerdの実際の使用例

CRI-Oの特徴と役割

CRI-Oとは何か

containerdとの違い

CRI-Oの設計思想

1. 軽量性

2. セキュリティ

3. 高速な起動

CRI-Oの実際の設定例

OCI標準の重要性

OCIが生まれた背景

3つの主要仕様（Runtime・Image・Distribution）

1. Runtime Specification（実行時仕様）

2. Image Specification（イメージ仕様）

3. Distribution Specification（配布仕様）

標準化によるメリット

1. 相互運用性

2. エコシステムの健全な発展

3. セキュリティの向上

実践！コンテナランタイムの選択指針

用途別のランタイム選択

containerdが適している場合

CRI-Oが適している場合

実際の選択例

パターン1：開発から本番まで一貫してcontainerd

パターン2：開発はDocker、本番はCRI-O

今後の技術動向

1. セキュリティ強化

2. WebAssembly（WASM）との統合

3. unikernelとの融合

学習を継続するために

1. 実際に触ってみる

2. メトリクス監視

3. トラブルシューティング

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル