コンテナ目線で考えるUnikernelと microVM Kernel/VM/探検隊online part1 Presented by @inductor

自己紹介

自己紹介 名前: 太田 航平 (@inductor) 所属: HPE (Hewlett Packard Enterprise) 役職: ソリューションアーキテクト (Cloud Native and DevOps) Docker MeetupとかCloud Native Daysの運営、謎のアンバサダー業 好きなこと: 無限にスケールする(無限にスケールするとは言ってない)インフラ

宣伝 ブログで気が向いたときに論文の 翻訳的なことをやったりしてます (権利関係がめんどくさくてあまり 進めていない）

コンテナの仕組み

コンテナの仕組み 雑に言えばすごいchroot → 特定のディレクトリをルートディレクトリに見立てて仕切りを作る技術 例: ホスト上の /var/docker/container1 をルートにしてそれ以下で別のOSが動くため の環境を作るみたいなことができる 隔離したファイルシステムに対してnamespaceで分離したユーザー、プロセス、NWな どを割り当て、cgroupsで利用できるリソース量を制限すると、まるでVMみたいなもの をプロセスの単位で作れるみたいなやつ

Dockerがもたらした変革 システム領域としてコンテナを利用することは(Linuxに限らず)前からあった DockerがもたらしたDockerfile、Dockerイメージというパッケージング技術と、それを 配布するための仕組みが開発者にとって親和性が高く、アプリケーションを内包する ファイルシステムの共有を簡単に行えるようになった Dockerはtarで固められたレイヤー状のFSをpivot_rootで区切られた空間上で展開 し、ホストOS上でプロセスとして動かすところまでを全部いい感じにした

Dockerが使う低レベルランタイム runCの仕組み(おさらい)

runCの仕組み ホストマシン Linuxカーネル コンテナ コンテナ コンテナ runC Docker & CRI ファイルシステムの展開 プロセスの初期化 イメージの管理

runCの仕組み ホストOS、カーネルはマシンごとに共通 DockerまたはCRIから受けた命令をもとにカーネルに命令を送ってコンテナの実態で あるリソースの隔離を行い、アプリケーションを実行する 普通にやるとホストOSの特権が必要 → runCの脆弱性が見つかるととても危ない

MicroVM

microVMとは 軽量かつ起動が高速で、動的に生成削除されるVMのこと → マイクロ仮想化(Micro-Virtualization)技術で使われるVM Amazonが作っているFirecrackerがOSSとしては有名 → Rust製で125ms程度の速さで起動するのが特徴 ここからはFirecracker前提で話を進めます

microVMの仕組み ホストOS microVM microVM microVM Firecracker CLI or REST Client ゲストOS ゲストOS ゲストOS

コンテナでの利用例 Firecracker-containerd と組み合わせる → Firecracker上のrunCとcontainerdを組み合わせて動かすためのOSS 軽量なVM + Dockerよりも軽量なcontainerdの組み合わせによって Dockerイメージを動かすことができる Fargateと呼ばれるAWSの仮想化技術もこれに準拠したものが使われている Ref. https://aws.amazon.com/jp/blogs/news/under-the-hood-fargate-data-plane/

コンテナでの利用例 ホストOS microVM microVM microVM Firecracker + runC + containerd CLI or REST Client ゲストOS ゲストOS ゲストOS コンテナ ランタイム コンテナ ランタイム コンテナ ランタイム

microVMのメリット・デメリット 既存のVM技術と比べリソースの割当が柔軟で動的 → REST APIでVMの操作が可能、起動が高速なのでスケールも速い VMであることに変わりはないのでホスト環境との隔離性が高い VMレイヤの起動オーバーヘッドなどが無視できない要件の環境だと厳しい

Unikernel

Unikernelとは Library OSを用いて特定のアプリケーションに必要なコンポーネントだけを内包した空 間を分離する技術 → カーネルで使わない機能すら排除して、余計なものを入れないという考え方 Library OS、それすなわち、OSがライブラリとして機能する(必要なものだけを入れたも のになる)という本当に最低限の動作環境なのでセキュア・軽量・高速

コンテナでの利用例 IBMが作っているNabla ContainersプロジェクトではUnikernelを採用 低レベルコンテナランタイムとしてRunncを使う → Seccompで使えるシステムコールを制限 → Library OSを使って必要なコンポーネントのみを入れる Unikernelの特性上通常のDockerイメージが使えない → ランタイムが使うunikernelのバイナリをイメージに組み込む必要があるため ここからはRunnc(Nabla Containers)前提で話を進めます

Unikernelの仕組み ホストOS Runnc ホスト上のnabla run tender が専用にコンパイルされたア プリのバイナリを読み出して 実行

Unikernelのメリット・デメリット VMと違い環境の分離までは行わずにプロセスとしてコンテナが動くので軽量かつ高 速 不要なカーネルの機能は含まれないため、ホストとの接地点が少ない Unikernelの技術自体の知名度が低く、知見があまりない + Runncというものを導入するハードルの高さ イメージのビルド環境が特殊でフォーマットの互換性もない

Appendix: gVisorとの違い gVisor(Runsc)はユーザー領域にカーネルを再実装したものを展開し、 あたかもそれがシステム領域であるかのように動作する仕組みになっている Unikernelと違ってDockerベースのイメージが動き、Containerdも動作するが、その 下にいるgVisorがLinuxカーネルのフリをして動くことによってホストとの環境を分離 している

Appendix: Kata Containerとの違い Kata ContainerはContainerdなどのランタイムから命令を受けたあと、namespace やcgroupsを使う代わりにQEMU/FirecrackerベースのVMを立ち上げ、その上にコン テナを展開する つまり、runCと同様にOCIのインターフェースを持ちコンテナの起動などを 行うが、実際にコンテナが動く環境がKVMで作られたVMになる

今選ぶならどれ？ Runnc(Nabla Container)は最近開発がストップしている → どうやらLupine Linuxという新しい仕組みに夢中のよう 今度のKubeCon Virtualで発表があるようなので楽しみ 論文も春に公開されてて、雰囲気で読んだ(そのうちまた解説を書く) Runsc(gVisor)+高レベルランタイムとFirecracker+Firecracker-containerdが有力だ が、気軽にサンドボックス環境を楽しみたいなら前者、カーネルの互換性を保ちたい なら後者がよさそう(?) ※参考: GCPのCloud RunはgVisorを、FargateはFirecrackerをそれぞれ使用

結論: どっちもどっち(暴論)

結論: 課題を感じなければ 多分Dockerでも大丈夫

まとめ Dockerで使われるrunCには特権を渡す必要がありコンテナ間の隔離性が低いなど の問題がある MicroVMでは隔離性は高いが起動時の遅延がシビアになりやすい Unikernelでは高いパフォーマンスと隔離性の代わりに汎用性が低くなりやすい 要件に合わせていろいろなスタックを組み合わせて使うことで様々な問題を解決する アプローチが現在進行系で（アカデミックな場でも）提案されている

ご意見お待ちしております ありがとうございました！

参考資料 KubeCon 報告：コンテナランタイムやFirecrackerの話題ひととおり 振り返ってみよう by 徳永航平さん https://www.slideshare.net/KoheiTokunaga/kubecon-firecracker makocchiさんのスライドいろいろ https://speakerdeck.com/makocchi/ A Linux in Unikernel Clothing @ EuroSys '20 Firecracker: Lightweight Virtualization for Serverless Applications