runC vs. cc-runtime vs. kata-runtime？コンテナランタイムの内部構造と性能比較

連載 [第7回] :

2018年5月24日(木)

Japan Container Days V18.04ではコンテナとKubernetesがソフトウェアとしてのトピックの中心であったが、コンテナを実行するランタイムに関しては様々なランタイムが存在する割にはあまり注目されていないのが現状だ。サイバーエージェントのインフラストラクチャーエンジニアである長谷川誠氏はそこに注目して、コンテナの内部構造からランタイムの違い、性能比較までを含めた「Dockerだけじゃないコンテナruntimeの徹底比較!」と題したセッションを実施した。今回はこのセッションを紹介しよう。

サイバーエージェントの長谷川誠氏

長谷川氏はコンテナランタイムとして、Docker、cri-o、Frakti、containerdを紹介。またCoreOSが開発するrktについても言及し、Kubernetes1.10において既にrktは「Deprecated（推奨されない）」ことが記述されていると説明した。オープンソースソフトウェアの場合、コードが追加される際にAPIのパラメータなども変更されることがあるが、その詳細な部分、特に追加されたのではなく削除された場合には今回の長谷川氏のようにHelpなどを見るしかない場合がある。そういった細かい部分まで掘り下げて解説する辺りに長谷川氏のエンジニア魂を感じた場面であった。

そしてコンテナ関連の重要な標準化のポイントでもあるCRI（Container Runtime Interface）の解説や、Linux Foundation配下の組織であるOCI（Open Container Initiative）についても紹介を行った。ここでのポイントはコンテナの標準化においてランタイム、フォーマットに次いでDocker Registry version 2を元にしたイメージ配布の標準化が進められているという部分だ。長谷川氏によればこれで3つ目の標準化が行われたということになり、コンテナに関するエコシステムを拡大するためにも必要な動きと言える。

OCIの解説とイメージレジストリの標準化について

このスライドに書かれているアナウンスのURLは以下の通り。

https://thenewstack.io/open-container-initiative-creates-a-distribution-specification-for-registries/

なお長谷川氏によるコンテナランタイムを使い分ける方法についてはサイバーエージェントAdtech Studioのブログ記事に詳細に記載されているので参考にされたい。

https://adtech.cyberagent.io/techblog/archives/4036

CRIについては「Kubernetes 1.5からリリースされたKubeletとContainer Runtimeが通信するためのPlugin Interface」と説明された。ここも重要なポイントで、Kubernetesはマスター上のapiserver、controller-managerなどの他に、実際にコンテナが実行されるノードであるkubeletなどいくつかのコンポーネントで実行される。そのために制御がどのように遷移していくのかを理解していないとランタイムが実際にどこで動いているのかを理解することは難しい。

コンテナの実行の詳細を解説

このスライドではノードで動くkubeletからCRIを通ってからContainer runtimeに制御が移り、最終的にOCIを通じてruntimeからコンテナ内のイメージが起動されるという部分を解説したものだ。分かりづらいのは、Container runtimeとruntimeが出てくるとこだろう。長谷川氏の解説によれば、ハイレベルのランタイムとローレベルのランタイムがある、という理解が必要だという。

ハイレベルとローレベルの特徴

主な違いはどこから制御が渡ってくるか、イメージの管理を行うかどうかなどだ。ランタイムの代表的なものとしてはハイレベルがcri-oやcontainerd、ローレベルはrunCであることを例に上げて解説を行った。

ハイレベルとローレベルのランタイム

つまりkubeletから叩かれる部分をハイレベル、その先のコンテナイメージを叩く部分をローレベルと分けるとわかりやすいということだ。そしてここからより詳細にランタイムの違いを解説するフェーズとなった。

Dockerのランタイムを解説

Dockerはkubelet->CRI->Docker->containerd->OCI->runC->コンテナイメージを起動、という流れだが、cri-oの場合は、kubelet->CRI->cri-o->OCI->runC->コンテナイメージ、containerdに至ってはkubelet->CRI->cri-containerd->gRPC->containerd->OCI->runC->コンテナイメージという流れになる。しかしKubernetes 1.10、containerd 1.1以降はkubelet->CRI->containerd->OCI->runC->コンテナイメージという流れに変わっているという。

ランタイムの違いにより仮想マシンのようなコンテナ実行も可能

4つのコンテナランタイムの比較の結果、コンテナだけではなく仮想マシンのようにカーネルを共有しないOpenStack FoundationがホストするランタイムであるKata Container（Intelと中国のHyperが寄贈したコンテナランタイム）の実行も可能だということがわかった。この辺りにランタイムがハイレベルとローレベルの2つに別れている理由がありそうだ。

ランタイムの性能比較を実施

次にランタイムの性能比較を紹介。runC、cc-runtime、kata-runtimeの起動から実行までの時間を比較した。同様にランタイムが利用するストレージドライバーに関しても比較を行った。これは、devicemapper(direct-lvm)、devicemapper(loopback)、overlay、overlay2を比較したものだ。

ストレージドライバーを比較

runC、cc-runtime、kata-runtimeのランタイムに4つのドライバーを組み合わせて比較を行った。

ストレージドライバーの比較

ランタイム、ストレージドライバーともに性能の差はあるものの、まだ積極的にDocker(containerd)以外を選ぶべきというほどの差はなく、ソフトウェアの進化に期待したいというのが最終的な結論だったが、コンテナの内部の動きを詳細に解説することでCRI、OCIが果たす役割や意味を理解することに繋がるセッションであった。