Kubernetes、Docker不要のコンテナ実行環境を目指す独自のコンテナランタイム「cri-o」開発中

多数のDockerコンテナをクラスタ化し、運用管理を容易にするためのツールとしてオープンソースで開発されている「Kubernetes」は、独自のコンテナの実行エンジン「cri-o」の開発をスタートさせています。

cri-oは当初「OCID」という名前で開発が始まり、2週間ほど前に「cri-o」に名称変更しました。cri-oはコンテナランタイムの標準仕様であるOCI（Open Container Initiative）準拠の実装であるrunCをコアにしたKubernetes用のコンテナランタイムです。

cri-oはまだプレアルファ版の状態ですが、実装が完成すればKubernetes上でコンテナを実行する際にDockerが必要ではなくなる見通しです。

CRIとOCIの2つの標準に準拠

現在、KubernetesはコンテナランタイムとしてDockerを利用しますが、Kubernetesとコンテナランタイムのあいだのインターフェイスを「CRI」（Kubelet Container Runtime Interface）として標準化しようとしています（Kubeletとは、Kubernetesの各ノード上で実行されるエージェントのことです）。

この標準化はKubernetesの開発主体であるCloud Native Computing Foundationによって行われています。

一方で、コンテナの標準仕様もDockerやマイクロソフト、Googleなどによる「Open Container Initiative」（OCI）が策定され、ランタイムのリファレンス実装としてrunCがオープンソースで開発されています（OCIに準拠したコンテナ実行デーモンということで、cri-oの当初の名前はOCIDでした）。

cri-oは、このKubernetesとコンテナエンジンとのインターフェイスであるCRI、およびコンテナランタイムの標準であるOCIの両方に準拠したKubernetes用のコンテナランタイムを開発しようというプロジェクトです。

This is an implementation of the Kubernetes Container Runtime Interface (CRI) that will allow Kubernetes to directly launch and manage Open Container Initiative (OCI) containers.

これは

Kubernetesとcri-oを組み合わせることで、Kuberneteが直接コンテナイメージを実行できるようになり、ネットワークで接続し、オーケストレーションするという、コンテナを大規模展開して実行する環境は一通り揃うことになり、（実行環境に置いては）Dockerが不要になる見通しです。

ただしcri-oはコマンドラインインターフェイスなどを備える計画ではないため、コンテナの作成や登録などでDockerが不要になるわけではありません。

コンテナはオーケストレーションツールを中心に回り始めた

cri-oは、Kubernetes incubatorの一部としてRed Hatが主導で開発を行っています。

Red Hatは同社のコンテナプラットフォームであるOpenShiftでKubernetesを採用しており、よりスリムで安定したコンテナプラットフォームを実現するために積極的に動いているといえます。

これはDockerがDocker 1.11でオーケストレーション機能のSwarm modeやコンテナネットワーキング機能をDocker Engineに統合し、さらに先週にはDocker環境の自動修復機能などを備えるInfraKitも将来的にDocker Engineに統合することを発表するなど、多くの機能を貪欲かつ急速にDocker Engineに統合していく動きに対して、よりスリムで安定したコンテナランタイムが求められる動きが表面化したものといえそうです。

そしてコンテナ関連の開発は、オーケストレーションツールを中心に回り始める時代へと転換し始めたことも同時に感じさせます。コンテナランタイムの主流の座を、Dockerは保ち続けることができるのでしょうか。