CRI-O（クライオ）は、Kubernetesから直接呼び出されることだけを目的に開発された軽量コンテナランタイムです。2016年にRed Hatの主導で着想され、2017年9月にバージョン1.0がリリースされました。同年に開発元のRed HatからCNCFへ寄贈され、2019年にIncubatingプロジェクトへ昇格しています。Kubernetesが定めるCRI（Container Runtime Interface）仕様とOCI（Open Container Initiative）仕様の双方に厳密準拠することを設計目標とし、Red HatのOpenShift Container Platform 4系の既定ランタイムとして本番採用されています。
この記事の目次
- CRI準拠・軽量・OCI整合の三本柱
- Red Hat主導の開発と普及
- OpenShiftノードでの運用
- containerdとの違い
- まとめ
CRI準拠・軽量・OCI整合の三本柱
CRI-Oの基本コンセプトは「Kubernetesに必要なものだけ実装する」です。Docker EngineやcontainerdがイメージビルドやREST API、SDK提供など幅広い機能を抱えるのに対し、CRI-OはCRIを通じてkubeletから呼ばれる範囲のみを実装し、それ以外の機能は意図的に切り捨てました。イメージのpullとレイヤー管理、サンドボックスPodと各コンテナの作成・実行・削除、ログのストリーミング、CNIプラグイン経由のネットワーク設定だけを行います。
実行ランタイムはruncを既定とし、kata-containersやgVisorといった代替OCIランタイムにも切り替え可能です。アーキテクチャ的にはconmonというモニタープロセスが各コンテナごとに付き、kubeletとruncの間で死活監視やログ転送を担います。余計な機能を持たない分、メモリ使用量と起動時間が小さく、ノードあたりのコンテナ密度を上げやすい点が評価されています。
Red Hat主導の開発と普及
CRI-Oは2016年にRed Hatのコンテナ部門エンジニア、ダニエル・ウォルシュらが中心となって立ち上げました。もともと「OCI」というコードネームでKubernetes 1.5に合わせて開発が始まり、後に商標との混同を避けるためCRI-Oという名前に変更されています。Red Hat、Intel、Suse、Hyperらが共同で開発し、2017年9月にCRI-O 1.0として正式リリースされました。Kubernetes 1.7のCRI正式採用と歩調を合わせて、Docker依存からの独立した選択肢を提供する位置づけとなりました。
2018年6月にRed Hatが買収したCoreOSの技術と統合する形でOpenShift Container Platform 4が設計され、CRI-Oが既定ランタイムとして採用されました。これにより、エンタープライズ向けKubernetesディストリビューションの中で、Docker EngineではなくCRI-Oが採用された最初の大規模事例が誕生しました。2022年5月のKubernetes 1.24でdockershimが完全削除された際にも、CRI-Oはcontainerdと並んで「dockershim後の選択肢」として広く案内されています。
OpenShiftノードでの運用
本番運用での代表例はOpenShiftのワーカーノードです。Red Hat Enterprise Linux CoreOS（RHCOS）上でCRI-Oが常駐デーモンとして動作し、kubeletからのCRI呼び出しを受けてPodを作成し、conmonで死活監視を行い、runcで実行します。イメージはquay.ioや独自レジストリからpullし、overlayfs上に展開します。Docker Engineを介さない構成なので、Dockerコマンドはノード上には存在しません。
管理者がトラブルシュートする場面では、Kubernetes標準のCLIであるcrictlを使うのが定石です。crictl psでコンテナ一覧、crictl logsでログ参照、crictl inspectで詳細情報の確認ができます。docker CLIの感覚に近く設計されていますが、ビルド機能は含まれません。イメージビルドはBuildahやPodmanといった別ツールに分業させる思想で、CRI-Oは実行に専念します。この役割分担が、Red HatコンテナエコシステムをDocker無しで完結させる柱となっています。
containerdとの違い
CRI-Oとcontainerdは、Kubernetes標準ランタイムの双璧として並び立つ存在ですが、設計思想に明確な違いがあります。containerdが「汎用コンテナランタイムでKubernetes以外の用途にも使える」のに対し、CRI-Oは「Kubernetes以外で使うことを想定していない」点が最大の差です。前者はDockerやnerdctl、wasm-edgeなど多様なクライアントから利用される一方、後者はkubeletからの呼び出しに最適化されています。
市場シェアでは、CNCFが毎年実施するアンケートでcontainerdが過半数を占め、CRI-Oは20〜30%程度で続くのが近年の構図です。ただしRed HatとOpenShiftのエンタープライズ採用が厚いため、金融・通信・公共などの基幹インフラ層ではCRI-Oの比重が大きくなる傾向があります。どちらを選んでも標準仕様の上で動くため、ノード単位での入れ替えが可能であり、選定基準はディストリビューションやサポート体制で決まるのが実情です。
まとめ
CRI-OはRed Hatが2016年に立ち上げ、2017年にv1.0を出したKubernetes専用ランタイムです。OCI仕様とCRI仕様への準拠を最重視し、機能を絞ることで軽量さと安定性を両立しています。OpenShiftの本番採用を背景にエンタープライズで定着しており、containerdと並んで「Docker無しでもKubernetesが回る」未来を実装したプロジェクトと言えます。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント