inductor's blog

nothing but self note :)

Firecrackerはコンテナランタイムなのかという話

この記事について

OCHaCafe #3に参加していて、参加者の方が「Firecrackerは高レベル低レベルどちらのランタイムに属しますか?」という質問をされていたのを見かけた。

ochacafe.connpass.com

確かにパッとドキュメントを見ても立ち位置よくわからんな、と思い、図を書いて整理してみようと思う。

firecracker-containerdについて

Takuya Niita (@takuya_0301) | Twitter氏も認識されて回答に含めていたプロジェクトにfirecracker-containerdがある。これはcontainerdとrunCを動かすときに間にFirecrackerを挟み込んで仮想化のレイヤを組み込んだ技術だ。Fargateなどで実際に使われているかどうかについては、言及がないので全く分かっていないが、少なくともFirecracker + containerdという選択肢を選ぶ場合はこれを使うのが一般的だろう。

github.com

このプロジェクトのアーキテクチャについて少し触れてみる。

通常、containerdとrunCは下図のように、containerdがrunCを直接実行することでホストのカーネル上にコンテナを展開する。

f:id:inductor:20201223211316p:plain

このときrunCはホスト上に存在するバイナリで、containerdからバイナリを実行することでLinuxのシステムコールを呼び出している。

一方、firecracker-containerdの場合、firecracker-controlというgRPCを用いてcontainerdからFirecrackerのVMを作成し、その中でrunCを展開させることによってコンテナをspawnしているようだ。

f:id:inductor:20201223212158p:plain

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の公式ドキュメントを見ると良い。

github.com

また、Dockerのユースケースで恐縮だが、実際にコンテナランタイムを入れ替えてみたケースについてはこちらを参照されたし。

blog.inductor.me

アーキテクチャについては公式の下図が参考になるだろう。基本的にはこのVirtual Machineの部分がQEMUによるKVMではなくFirecrackerによるKVMに置き換わるだけだ。よって、基本的に実現してるレイヤ自体はfirecracker-containerdとそれほど大きな差はない。

f:id:inductor:20201223212803p:plain

これも先程と同じく、「コンテナごとに隔離するための環境を作成」するためのVMプロバイダーとしてFirecrackerが使われていることがわかる。

ただし、KataはrunCと違って機能として含まれる隔離であるため、KataからとってみればFIrecrackerはKVMによる環境分離を実現するために使っているツールの1つ、ということになるだろう。