Container Runtime

Docker は以下のフローでコンテナを作成する。

Docker client が dockerd の REST API に対して、リクエスト（コマンド）を送信する。
dockerd は containerd といった High-level Runtime に対して、gRPC経由で実行すべきコンテナの情報を伝える。
containerd は runC といったLow-level Runtime に対して、JSON形式で、コンテナの情報を伝える。
Low-level Runtime は、コンテナを実行する。

もし、コンテナランタイムがHigh-level Runtime と Low-level Runtime に分かれていなければ、クライアントからのリクエストの受付からコンテナイメージの管理、実行コンテナの管理、コンテナの起動といった全てを行うものになってしまい、好ましくないアーキテクチャになる。

そのため、２つのランタイムに分けている。

1. High-level Runtime (CRI Runtime)

クライアントからのリクエストの受付やコンテナイメージの管理、Low-level Runtime に対するコンテナの実行依頼などを行う。

containerd
CRI-O

2. Low-level Runtime (OCI Runtime)

OSの機能を利用して、コンテナを実行する責務を担当する。初期実装は、runC だが、脆弱性がいくつか見つかり、かつ特権コンテナを実行できてしまうなどの問題があったため、runCをベースにした新しい実装が登場した。

runC
gVisor (Google): gVisorプロセスがゲストカーネルを展開
Firecracker (AWS): microVMを採用
Kata Containers
Nabla Containers (IBM): Unikernelを採用

コンテナランタイムの構成

gVisor

インストール方法はこちら

以下のように、--runtime=runscとすることで、gVisorを使うことができる。

docker run --rm -it --runtime=runsc ubuntu:20.04

Sysbox