この記事について
OCHaCafe #3に参加していて、参加者の方が「Firecrackerは高レベル低レベルどちらのランタイムに属しますか？」という質問をされていたのを見かけた。
確かにパッとドキュメントを見ても立ち位置よくわからんな、と思い、図を書いて整理してみようと思う。
firecracker-containerdについて
Takuya Niita (@takuya_0301) | Twitter氏も認識されて回答に含めていたプロジェクトにfirecracker-containerdがある。これはcontainerdとrunCを動かすときに間にFirecrackerを挟み込んで仮想化のレイヤを組み込んだ技術だ。Fargateなどで実際に使われているかどうかについては、言及がないので全く分かっていないが、少なくともFirecracker + containerdという選択肢を選ぶ場合はこれを使うのが一般的だろう。
このプロジェクトのアーキテクチャについて少し触れてみる。
通常、containerdとrunCは下図のように、containerdがrunCを直接実行することでホストのカーネル上にコンテナを展開する。
このときrunCはホスト上に存在するバイナリで、containerdからバイナリを実行することでLinuxのシステムコールを呼び出している。
一方、firecracker-containerdの場合、firecracker-controlというgRPCを用いてcontainerdからFirecrackerのVMを作成し、その中でrunCを展開させることによってコンテナをspawnしているようだ。
https://github.com/firecracker-microvm/firecracker-containerd/tree/master/firecracker-control
よって、このユースケースにおけるFirecrackerの立ち位置は、「runCをコンテナごとに隔離するための環境を作成」するためのVMプロバイダーになっている。
Kata + Firecrackerの場合
Kata containersは、runCに置き換え可能な低レベルランタイムで、デフォルトではQEMUを用いたKVMの上でゲストOSを動かし、そこでコンテナを生成する。
Firecrackerが作られたそもそものモチベーションの一つにQEMUの置き換えというものがあり、コンテナを管理するためのこのケースではぴったり当てはまる。詳しくは下記Kataの公式ドキュメントを見ると良い。
また、Dockerのユースケースで恐縮だが、実際にコンテナランタイムを入れ替えてみたケースについてはこちらを参照されたし。
アーキテクチャについては公式の下図が参考になるだろう。基本的にはこのVirtual Machineの部分がQEMUによるKVMではなくFirecrackerによるKVMに置き換わるだけだ。よって、基本的に実現してるレイヤ自体はfirecracker-containerdとそれほど大きな差はない。
これも先程と同じく、「コンテナごとに隔離するための環境を作成」するためのVMプロバイダーとしてFirecrackerが使われていることがわかる。
ただし、KataはrunCと違って機能として含まれる隔離であるため、KataからとってみればFIrecrackerはKVMによる環境分離を実現するために使っているツールの1つ、ということになるだろう。
