コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unikernel in the container world

Transcript

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

   View Slide

2. 自己紹介
   

   View Slide

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

   View Slide

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

   View Slide

5. コンテナの仕組み
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. MicroVM
    

    View Slide

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

    View Slide

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

    View Slide

14. コンテナでの利用例
    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/
    

    View Slide

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

    View Slide

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

    View Slide

17. Unikernel
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. 参考資料
    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
    

    View Slide