Kubernetes、独自のコンテナランタイム「cri-o」開発中。コンテナランタイムのインターフェイスを標準化し、Dockerだけでなくどんなコンテナランタイムでも対応可能に
多数のDockerコンテナをクラスタ化し、運用管理を容易にするオーケストレーションツールの「Kubernetes」が、独自のコンテナランタイム「cri-o」の開発をスタートさせています。
cri-oは当初「OCID」（Open Container Initiative Daemon）という名前で開発が始まり、2週間ほど前に「cri-o」に名称変更しました。
Kubernetesはコンテナとのインターフェイスを「Container Runtime Interface」（CRI）として標準化しようとしており、cri-oは、そのCRIに対応したコンテナランタイムとして実装されようとしているのです。
またcri-oはCRIだけでなく、コンテナランタイムの標準であるOCI（Open Container Initiative）にも準拠するとしています。
下記はGitHubのcri-oのドキュメントから「What is the scope of this project?」の冒頭を引用しました。
cri-o is meant to provide an integration path between OCI conformant runtimes and the kubelet. Specifically, it implements the Kubelet Container Runtime Interface (CRI) using OCI conformant runtimes.
cri-oはOCIに対応したランタイムとKubelet（注：各ノードで実行されるKubernetesのエージェントのこと）の統合を実現しようとするものだ。特に、OCI対応のランタイムを用いてKubeletのContainer Runtime Interface（CRI）を実装することにある。
OCI対応のランタイムとは、OCIのリファレンス実装であるrunCのことを指します。つまり、cri-oとは、runCを用いつつ、CRIの適切な標準のあり方や実装をさぐりつつ、Kubernetesに対応したコンテナランタイムを実装しようという試みだといえそうです。
Kubernetesの主要な開発者の一人でコミッターであるKelsey Hightower氏も、OCID（すなわち現cri-o）は機能を完備し標準に対応したコンテナランタイムであり、KubernetesのCRIに対応したものだと説明しています。
ocid - A fully featured, standards based, container runtime that implements Kubernetes' Container Runtime Interface. https://t.co/GVDVcqLs7U
— Kelsey Hightower (@kelseyhightower) 2016年9月15日
CRIとOCI、2つの標準
OCIとCRIについて少し補足しておきましょう。
OCIとは、それぞれ異なるコンテナ実装を進めてきたDockerとCoreOSが、2015年6月に統一したコンテナ実装の標準を作ることに合意し、マイクロソフトやインテル、レッドハット、Googleなどとともに発足させたコンテナの標準仕様を推進する「Open Container Initiative」が推進する、コンテナ標準仕様です。
そのリファレンス実装が「runC」で、すでにDocker 1.11からはDockerもrunCベースとなっています。
一方のCRI（Container Runtime Interface）について触れる前に、まず現状のKubernetesとコンテナランタイムの関係を見ておきましょう。
Kubernetesはのンテナランタイムとして主に用いられているのはDockerですが、現時点でKubernetesはDockerに加えてrktとHyperの3種類をコンテナランタイムとして利用可能です。
Kubernetesとしては、さまざまなコンテナランタイムをKubernetesとともに利用できることこそあるべき姿と考えているため、Kubernetesとコンテナランタイムのインターフェイスを標準化し、この標準インターフェイスに対応したコンテナランタイムなら自由にKubernetesと組み合わせて使えるようにしようとしています。
そのKubernetesとコンテナランタイムのあいだのインターフェイスが「CRI」（Kubelet Container Runtime Interface）というわけです。
cri-oは、このKubernetesとコンテナエンジンとのインターフェイスであるCRI、およびコンテナランタイムの標準であるOCIの両方に準拠したKubernetes用のコンテナランタイムを開発しようというプロジェクトといえます。現在cri-oはプレアルファの状態で、kubernetes-incubatorのプロジェクトの1つとしてレッドハットが主導しています。
cri-o（旧OCID）はDockerと競合しない……
cri-oが実現すれば、KubernetesはDockerを使わずともコンテナイメージを実行できるようになりそうです。では、cri-oはDockerと競合する存在かといえば、そうではないと、cri-oの開発を主導するレッドハットはブログ「Running production applications in containers: Introducing OCID」で次のように書いています。
OCID is not competitive with the docker project - in fact it shares the same OCI runC container runtime used by docker engine, the same image format, and allows for the use of docker build and related tooling. We expect to bring developers more flexibility by adding other image builders and tooling in the future.
OCIDはDockerプロジェクトと競合するものではない。実際のところ、Dockerエンジンでも使われているOCIのrunCコンテナラタンタイムを共用しているし、イメージフォーマットも同じ、またDockerのビルドや関連ツールを使うことも許容しているのだ。
私たちは将来的に、ほかのコンテナイメージのビルダーやツール群を追加することで、開発者たちにより柔軟性をもたらすことを期待している。
正確な意図は読み取りにくいのですが、OCID（現cri-o）の開発を通じてこうしたイノベーションをDockerなどと共有していきたい、というのがメッセージのようです。
また、cri-oはあくまでコンテナランタイムの機能しか持たず、コマンドラインインターフェイスなどは備えないので、コンテナイメージの作成や管理といった部分はDockerが担う、という役割分担も想定しているのではないかと思われます。
コンテナはオーケストレーションツールを中心に回り始めた
とはいうものの、DockerはDocker 1.11でオーケストレーション機能のSwarm modeやコンテナネットワーキング機能をDocker Engineに統合し、さらに先週にはDocker環境の自動修復機能などを備えるInfraKitも将来的にDocker Engineに統合することを発表するなど、貪欲に機能を取り込んでいます。
こうした動きに対して、スリムで安定したシンプルなコンテナランタイムを実現したい、という希望がKubernetes側にあったとしても不思議ではありません。
CRIおよびcri-oがうまくいけば、コンテナランタイムは交換が容易なコンポーネントとしてコモディティ化が促進される一方、Kubernetesのようなオーケストレーションツールがコンテナエコシステムの主導権を握る動きが加速する可能性が高くなるでしょう。だからこそDockerもいまはSwarmなどのオーケストレーションツールに注力し、主導権を持ち続けたいと考えているはずです。
コンテナ関連の開発は、オーケストレーションツールによる主導権争いへと転換し始めたように思います。数年後も、コンテナの主流の座をDockerは保ち続けることができるのでしょうか。
タグ ： Docker , Kubernetes , クラウド , コンテナ
≪前の記事
オープンソースのエディタ「Visual Studio Code 1.6」リリース。TypeScript 2.0対応、セーブ時にコードを自動フォーマットしてくれるFormat on Save機能など