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
4.8k
コンテナ目線で考える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
3
2k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
110
Cracking the KubeCon CfP
inductor
2
510
KubeCon Recap -Platform migration at Scale-
inductor
1
960
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
460
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
26
6.1k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
790
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.2k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
19
6k
Other Decks in Technology
See All in Technology
LambdaとSQLiteでシステム構築
ogadra
1
150
Agentic AI時代のプロダクトマネジメントことはじめ〜仮説検証編〜
masakazu178
0
290
Women in Agile
kawaguti
PRO
2
160
もし今からGraphQLを採用するなら
kazukihayase
7
3.3k
インシデントキーメトリクスによるインシデント対応の改善 / Improving Incident Response using Incident Key Metrics
nari_ex
0
3.5k
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
17k
20250125_Agent for Amazon Bedrock試してみた
riz3f7
2
110
ドメイン駆動設計によるdodaダイレクトのリビルド実践 / Rebuild practice of doda direct with domain-driven design
techtekt
0
510
“自分”を大切に、フラットに。キャリアチェンジしてからの一年 三ヶ月で見えたもの。
maimyyym
0
250
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
0
180
一人から始めたSREチーム3年の歩み - 求められるスキルの変化とチームのあり方 - / The three-year journey of the SRE team, which started all by myself
vtryo
7
5.3k
やっちゃえ誤自宅Nutanix
yukiafronia
0
340
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
96
5.3k
Practical Orchestrator
shlominoach
186
10k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Unsuck your backbone
ammeep
669
57k
RailsConf 2023
tenderlove
29
980
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
The Cult of Friendly URLs
andyhume
78
6.2k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
260
Adopting Sorbet at Scale
ufuk
74
9.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.5k
Rails Girls Zürich Keynote
gr2m
94
13k
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