CRI-Oとは？Kubernetes専用の軽量コンテナランタイムの仕組みとcontainerdとの違いを解説

CRI-O（シーアールアイオー）は、Kubernetesでコンテナを動かすことだけに絞って設計された、OCI準拠の軽量コンテナランタイムです。KubernetesのCRI（Container Runtime Interface）を実装し、ノード上でkubeletからの指示を受けてコンテナを起動する裏方の実行基盤です。この記事では、CRI-OがイメージのpullからコンテナのプロセスをOCIランタイム（crun／runc）へ渡すまでのどこを担うのか、conmonやCNIといった構成要素、Kubernetesと同じバージョン番号で同期する開発体制、そして汎用ランタイムのcontainerdとの設計思想の違いまでを一次情報で整理しました。実装者がCRI-Oを選ぶべき場面と、containerdで足りる場面の判断軸まで示します。

まとめ：CRI-Oの位置づけとKubernetesにおける役割

CRI-Oは、Kubernetesのkubeletとコンテナの間に立ち、イメージの取得・展開、コンテナのライフサイクル管理、ストレージやネットワークの割り当てを受け持つランタイムです。ただしコンテナのプロセスそのものを生成する最下層の処理は自前で行わず、OCI準拠の低レベルランタイムであるcrunやruncへ委ねます。この「Kubernetes専用の高レベル処理はCRI-O、低レベルはcrun/runc」という分業が、CRI-Oを理解する起点になります。

特徴は、汎用性を捨ててKubernetesだけに寄せた割り切りです。DockerやローカルのCLI操作を想定せず、kubeletから駆動される前提でつくられ、バージョンもKubernetesのマイナー版と1:1で同期します。同じCRIランタイムでも、Dockerの下でも動きエコシステムが広いcontainerdとは狙いが対照的です。本記事後半では、この違いを踏まえてどちらを選ぶか、AWSなどクラウド上のKubernetes運用にどう落とすかの判断まで踏み込みます。

CRI-Oの定義とコンテナランタイムを構成する階層構造の全体像

CRI-Oを正しく捉えるには、コンテナランタイムが一枚岩ではなく階層に分かれている事実と、CRI-Oがどの層を担うのかを押さえる必要があります。コンテナという技術そのものの仕組みを前提に、層ごとに分けて見ていきます。

CRIを実装する高レベルランタイムとしてのCRI-Oの責務範囲

Kubernetesは、各ノードのkubeletとコンテナランタイムの間をCRI（Container Runtime Interface）というgRPCの標準インターフェースでつなぎます。CRI-Oはこの受け口を実装した高レベルランタイムで、レジストリからのイメージpull、レイヤの展開とストレージ管理、CNI経由のネットワーク設定、コンテナやPodの起動・停止・削除といったライフサイクル制御を担う役割です。言い換えると、kubeletからの抽象的な「このPodを立ち上げよ」という指示を、OCIランタイム向けの具体的な実行命令へ翻訳する役割を負います。イメージ取得はcontainers/image、ストレージはcontainers/storage（overlay）という、Red Hat系で共通のライブラリ群を土台にしている点も特徴です。

crun／runc（低レベルランタイム）へプロセス生成を委譲する分業構造

実際にLinuxカーネルのnamespaceやcgroupを設定し、コンテナのプロセスを生成する最下層の処理は、CRI-O自身ではなく低レベルランタイムのcrunまたはruncが行います。crunはC言語で書かれた軽量なOCIランタイムで、現在のCRI-Oでは既定として選ばれ、メモリ使用量や起動速度で有利です。runcはGo実装の参照実装で、こちらも選択できます。CRI-Oはコンテナごとにこれらを呼び出し、その生成後のプロセスをconmonという監視プロセスが見張り続けます。conmonがCRI-O daemonとコンテナの間に入るため、CRI-O本体を再起動してもコンテナは動き続ける構造です。crun／runc以外にも、gVisor（runsc）やKata Containersといった別のOCIランタイムへ差し替えられる点が、OCI準拠のインターフェースを持つ強みです。

Red Hat主導の開発経緯とKubernetesとバージョン同期する設計

CRI-Oは、DockerへのCRI対応が定まらない状況を受け、Red Hatが主導して2016年に開発を始めたランタイムです（当初はOCIDと呼ばれていました）。現在はCNCF傘下のIncubatingプロジェクトとして中立に維持されています。最大の設計原則は「Kubernetesを動かすのに過不足ない最小限」で、汎用のコンテナ操作は狙わず、バージョン番号もKubernetesのマイナー版と1:1で対応させています。たとえばCRI-O 1.33はKubernetes 1.33向け、というように番号が揃うため、どのCRI-Oを入れればよいか迷いにくいのが利点です。2026年7月時点の最新は1.36系（1.36.2が2026-07-02公開）で、Kubernetes本体のリリースに追従して更新されます。

CRI-Oを構成する主要コンポーネントとcontainerdとの違い

CRI-Oを運用面で捉えるには、監視を担うconmon、周辺のライブラリ群、そして汎用ランタイムであるcontainerdとの設計差を押さえます。ここは実装者が選定時に判断材料にする層です。

conmon・containers系ライブラリ・CNIという構成要素

CRI-Oの中核を支えるのがconmonです。conmonはコンテナごとに常駐する監視プロセスで、標準入出力の中継、ログの記録、終了ステータスの回収を担い、CRI-O daemonからコンテナを切り離します。containerdでいうshimに相当する役割で、この分離によりCRI-O本体の更新や再起動がコンテナの稼働に影響しません。イメージのpullと展開はcontainers/image、レイヤのストレージ管理はcontainers/storage（overlayが標準）が受け持ち、ネットワークはKubernetes標準のCNIプラグインで割り当てます。これらはいずれもPodmanなどと共通のRed Hat系ライブラリで、CRI-O単体で完結せず部品を組み合わせる構成になっています。

汎用ランタイムのcontainerdとKubernetes専用CRI-Oの設計思想の違い

同じCRIランタイムでも、狙いは対照的です。containerdはDockerの下でも動く汎用の実行基盤で、ctrやnerdctlという人間向けのCLIを持ち、snapshotterで複数のストレージ方式を選べます。CNCFのGraduatedプロジェクトで、Amazon EKSなどマネージドKubernetesの多くが既定のノードランタイムに採用しています。対してCRI-Oは、Kubernetes以外での利用を想定せず、汎用のクライアントCLIを持ちません。kubeletから駆動される前提で、デバッグはKubernetes標準のcrictlが窓口です。機能を絞る分、攻撃対象領域が小さくなり、バージョンがKubernetesと揃う運用のしやすさが得られます。両者の階層構造やDockerとの関係を掘り下げたcontainerdの解説記事とあわせて読むと、ランタイム選定の軸がはっきりします。

OpenShiftで既定採用されるCRI-Oとエコシステム上の位置づけ

CRI-Oの採用が最も進んでいるのはRed Hat OpenShiftで、ここではCRI-Oが既定かつ唯一サポートされるランタイムです。OpenShiftのバージョンに紐づくKubernetesと同じ番号のCRI-Oが組み込まれるため、利用者がランタイムを個別に選ぶ場面はほとんどありません。一方でEKS・GKE・AKSといったパブリッククラウドのマネージドKubernetesは、既定がcontainerdであるケースが主流です。CRI-Oは自前構築のクラスターやOpenShift系で選ばれる、という住み分けを押さえておくと、基盤選定の当たりがつけやすくなります。コンテナオーケストレーションとしてのKubernetesの役割と、ノードでPodを実際に走らせるCRI-Oの役割を分けて捉えると、全体像が繋がります。

実装者がCRI-Oを選ぶべき場面とcontainerdで足りる判断基準

ここは判断を言い切ります。CRI-Oは優れたランタイムですが、どの現場でも第一候補になるわけではありません。自社のKubernetes運用のどこでCRI-Oを選ぶべきかを、条件付きで見極めます。

CRI-Oを選ぶ場面とcontainerdで足りる場面の線引き

CRI-Oが適するのは、OpenShiftを採用している、あるいは自前構築のクラスターでランタイムのバージョンをKubernetesと厳密に揃えたい、攻撃対象領域を絞った最小構成にしたい、という要件が明確なときです。逆に、EKS・GKE・AKSといったマネージドKubernetesを使い、ノードのランタイムが既定でcontainerdなら、無理にCRI-Oへ載せ替える理由は薄くなります。マネージドサービスは既定のランタイムを前提に検証されており、外れると自前で整合性を担保する負担が増えるためです。OpenShiftならCRI-O、汎用マネージドならcontainerd、という既定に沿う判断が失敗を避ける近道です。

AWSなどクラウド上のKubernetes基盤としてランタイムを選ぶ条件

本番のKubernetesクラスターをクラウド上に組むなら、ランタイムは単体で決めず、マネージドサービスの既定・運用体制・セキュリティ要件をあわせて設計する必要があります。たとえばAmazon EKSのワーカーノードは既定でcontainerdが動きますが、規制対応で最小構成のランタイムを求められる、既存のOpenShift資産と揃えたい、といった事情があるならCRI-Oが選択肢です。こうしたAWSやクラウド上のコンテナ基盤を自社システムへ取り入れる際は、ランタイムやノード構成、運用監視まで含めて妥当性を見極める必要があり、AWSを含むクラウドインフラ構築の相談窓口で、コンテナ基盤の選定から運用まで相談すると立ち上げの手戻りを減らせます。

CRI-Oを直接運用の対象にしようとする場面で陥る失敗パターン

見送るべきなのは、ローカルで手作業のコンテナ操作をしたいのにCRI-Oを直接触ろうとする構成です。CRI-Oはkubeletから駆動される前提で汎用CLIを持たないため、手元でコンテナを起動したいだけなら、同じcontainers系ライブラリを土台にするPodmanを使うほうが素直です。はまりやすい失敗は3つあります。1つ目は、CRI-OとKubernetesのバージョン番号を揃えずに片方だけ上げて非互換を踏むケース。2つ目は、マネージドKubernetesの既定ランタイムを確認せず、サポート外の構成へ載せ替えて検証負担を抱える構成。3つ目は、conmonが担うログや終了ステータスの取得経路を設計に織り込まず、障害時にノードのコンテナ状態を追えない運用です。バージョンをKubernetesと同期させ、crictlでノードを調査できる体制を先に用意しておけば、CRI-Oを基盤として安定して扱えます。コンテナ技術そのものを自社に導入すべきかの上位判断は、コンテナとはの記事で整理しています。

よくある質問

CRI-Oの検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

CRI-Oとcontainerdの違いは何ですか？

どちらもKubernetesのCRIランタイムですが、containerdはDockerの下でも動く汎用の実行基盤で、ctrやnerdctlといった人間向けCLIを持ち、多くのマネージドKubernetesが既定で採用しています。対してCRI-OはKubernetes専用に機能を絞ったランタイムで、汎用CLIを持たずkubeletから駆動され、Red Hat OpenShiftで既定に採られます。汎用性とエコシステムの広さならcontainerd、最小構成とKubernetesとのバージョン一致ならCRI-O、という住み分けです。

CRI-Oとruncの違いは何ですか？

CRI-Oはイメージのpullやライフサイクル管理を担う高レベルランタイム、runc（やcrun）はLinuxのnamespaceやcgroupを設定してコンテナプロセスを生成する低レベルランタイムです。CRI-Oは実際のプロセス生成をruncやcrunへ委譲し、これらはOCIバンドルからコンテナを起動する最下層を受け持ちます。gVisorやKata Containersといった別のOCIランタイムへ差し替えることもできます。

CRI-Oはどんなときにcontainerdより向いていますか？

Red Hat OpenShiftを使う場合はCRI-Oが既定かつ唯一のサポート対象なので選択の余地なくCRI-Oになります。自前構築のクラスターでも、ランタイムのバージョンをKubernetesと厳密に揃えたい、攻撃対象領域を絞った最小構成にしたい、という要件が強い現場に向いた選択です。逆にEKS・GKE・AKSのようなマネージド環境は既定がcontainerdのため、そちらに沿うほうが運用負担は小さくなります。

CRI-Oのバージョンはどう選べばよいですか？

CRI-OはKubernetesのマイナー版と1:1で番号が対応するため、動かすKubernetesと同じ番号のCRI-Oを選ぶのが基本です。たとえばKubernetes 1.33ならCRI-O 1.33を使います。2026年7月時点の最新は1.36系（1.36.2が2026-07-02公開）で、Kubernetes本体のリリースに追従して更新されます。OpenShiftを使う場合は、OpenShiftのバージョンに紐づくCRI-Oが組み込まれるため、個別に選ぶ必要はありません。

CRI-Oでコンテナの状態を確認するにはどうすればよいですか？

CRI-Oは汎用のクライアントCLIを持たないため、ノード上でコンテナやPodの状態を確認するときはKubernetes標準のcrictlコマンドを使います。crictlはCRI経由でランタイムを操作するデバッグ用ツールで、containerdでもCRI-Oでも共通に使えます。手元でコンテナを手作業で起動したい場合は、同じcontainers系ライブラリを土台にするPodmanを使うのが素直です。

関連記事

• containerdとは？Dockerとの関係・runc/CRIの仕組みとKubernetesでの役割を解説：CRI-Oと対になる汎用コンテナランタイムの比較対象
• コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断：CRIでCRI-Oと連携するKubernetesの上位概念
• コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで：CRI-Oの前提となるコンテナ技術そのものの仕組みと導入判断
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル：ノードのランタイムを選ぶ舞台となるマネージドKubernetes