Kubernetesの新たなコンテナランタイム

ここ数ヶ月間で、Kubernetesと、そのコンテナランタイムであるDockerとrktとのこれまでの関係に変化があった。KubernetesがContainer Runtime Interface(CRI) APIをリリースしたのだ。並行して、KubernetesとOCI準拠のランタイムとのブリッジ構築を目的とした、CRI-Oと呼ばれる実装の開発も進められている。これによってKubernetesから、OCI準拠のコンテナ・ランタイムを標準的な方法で使用できるようになる。

Kubernetesは、プルや作成や削除といった、コンテナのライフサイクル制御のための操作を、基盤となるコンテナランタイムに依存している。ランタイムは実際のコンテナ実装として、名前空間の分離やリソース割り当てをオペレーションシステムのレベルで実行する。これまでのDockerとrktは、いずれも非公開のAPIを通じて、Kubernetesのソースコードに密接に統合されていた。そのため、これら以外のランタイムの追加が困難な上に、安定性の保証されないソースコードの修正を行なう必要があった。Kubernetesにアルファ機能として導入されたContainer Runtime Interface(CRI)は、これを変えようというものだ。CRIは、コンテナランタイムをKubernetesシステムにプラグインするための共通インターフェースを公開する。これによってユーザは、Dockerやrkt以外のインフラストラクチャの編成や拡張が可能になる。runvのようなコンテナベースのハイパーバイザもランタイムとして使用可能だ。

コンテナフォーマットとランタイムの標準化を目標に結成された業界フォーラムであるOpen Container Initiative(OCI)が、 コンテナランタイムの標準となる ランタイム仕様を公開した。現時点での実装としては、HyperHQのrunvであるruncと、IntelのClear Containersベースのもの、その他がある。Project Atomic/RedHatが業界のコントリビュータ達と立ち上げたCRI-Oプロジェクトでは、OCIコンテナランタイムを使用したKubernetes CRI APIを開発中である。これにより、OCIに準拠した任意のランタイムであれば、CRIアダプタの実装をそれぞれ用意しなくても、後者のCRI APIを通じてKubernetesにプラグインできるようになる。

KubernetesのCRIには、現時点で次の実装が存在する。

• CRI-O – OCI準拠ランタイム
• rktlet – rktコンテナランタイム
• Frakti – ハイパーバイザベースのコンテナランタイム
• Docker CRI shim – CRIアダプタとしてDockerを直接サポート

イメージ提供: http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html

Kubernetesのデプロイメントでは、kubeletが各ホスト(Kubernetes用語ではミニオン)のローカルエージェントとしてコンテナランタイムと通信するが、CRIを使用する場合には、kubeletはgRPC(オープンソースのRPCフレームワーク)越しにCRIシムと通信し、それをフロントエンドとして実際のランタイムを呼び出すことになる。Kubernetesの最小デプロイメントユニットであるPodのコンセプトは、PodSandboxというコンセプトに拡張され、同様のセマンティクスを維持する。これは、ハイパーバイザベースのシステムでは仮想マシンに、DockerなどのランタイムではLinuxネームスペースに、それぞれ転換されることになる。