Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unike...
Search
Kohei Ota
June 06, 2020
Technology
7
5.1k
コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unikernel in the container world
Kohei Ota
June 06, 2020
Tweet
Share
More Decks by Kohei Ota
See All by Kohei Ota
CloudNative Meets WebAssembly: Exploring Wasm's Potential to Replace Containers
inductor
4
2.9k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
130
Cracking the KubeCon CfP
inductor
2
620
KubeCon Recap -Platform migration at Scale-
inductor
1
1k
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
530
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
28
6.4k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
850
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.3k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
22
6.4k
Other Decks in Technology
See All in Technology
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
120
AIコードアシスタントとiOS開発
jollyjoester
1
230
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
340
今日からあなたもGeminiを好きになる
subaruhello
1
580
PHPでResult型やってみよう
higaki_program
0
190
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
6
1k
QAを早期に巻き込む”って どうやるの? モヤモヤから抜け出す実践知
moritamasami
2
180
「手を動かした者だけが世界を変える」ソフトウェア開発だけではない開発者人生
onishi
12
5.3k
Wasmで社内ツールを作って配布しよう
askua
0
130
(HackFes)米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
5
660
AI エンジニアの立場からみた、AI コーディング時代の開発の品質向上の取り組みと妄想
soh9834
6
330
Data Engineering Study#30 LT資料
tetsuroito
1
570
Featured
See All Featured
Designing for Performance
lara
610
69k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
990
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
850
A Tale of Four Properties
chriscoyier
160
23k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
What's in a price? How to price your products and services
michaelherold
246
12k
Transcript
コンテナ目線で考える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