10分で理解したかったlibkrun / I wanted to understand libkrun but

Transcript

1. 10分で完全理解する したかった libkrun Kernel/VM探検隊online part2 Presented by @_inductor_
2. 自己紹介 名前: 太田 航平 (@inductor) 所属: HPE (Hewlett Packard Enterprise) 役職: ソリューションアーキテクト (Cloud Native and DevOps) Container Runtime MeetupやCloud Native Daysの運営、謎のアンバサダー業 好きなこと: 無限にスケールする(無限にスケールするとは言ってない)インフラ
3. Disclaimer 今日はコンテナがちょっと好きな素人がちょっと低めのレイヤに手を出したらやけどし て何もわからなかったという話をします 低レイヤに気軽に手を出してもらうためのきっかけにしてください！！！ 低めのレイヤが好きな皆様にあたりましては、ツッコミとアドバイスをしていただきつ つ、発表者の理解度を上げていただけますようお願い申し上げます😭
4. libkrun とは • Red Hatのエンジニアが去年作り始めたVMM(Virtual Machine Monitor) • VMM? → コンテナ目線で考えるUnikernelとmicroVM(前回の資料) • 最低限のデバイスエミュレーションとC APIを備えたRust製のMicroVM ◦ virtio-console, virtio-fs, virtio-vsockなどを実装 ◦ Firecrackerなどからコードを拝借してるらしい • macOSでも動くっぽい(動作未確認) • C APIを提供しているのでライブラリとしても使える ◦ crunで実験的にサポートを開始 • ネットワークコンポーネントにvirtio-netは使わず、vsockベースのTSI(Transparent Socket Impersonation)という”革新的な方法”で自前実装 ◦ 依存関係ライブラリとして libkrunfwがある
5. libkrun とは • Red Hatのエンジニアが去年作り始めたVMM(Virtual Machine Monitor) • VMM? → コンテナ目線で考えるUnikernelとmicroVM(前回の資料) • 最低限のデバイスエミュレーションとC APIを備えたRust製のMicroVM ◦ virtio-console, virtio-fs, virtio-vsockなどを実装 ◦ Firecrackerなどからコードを拝借してるらしい • macOSでも動くっぽい(動作未確認) • C APIを提供しているのでライブラリとしても使える ◦ crunで実験的にサポートを開始 • ネットワークコンポーネントにvirtio-netは使わず、vsockベースのTSI(Transparent Socket Impersonation)という”革新的な方法”で自前実装 ◦ 依存関係ライブラリとして libkrunfwがある 現時点での疑問 ・なぜ既存のコード使ってまで新しく 作ったの？新規性は？
6. libkrun とは • Red Hatのエンジニアが去年作り始めたVMM(Virtual Machine Monitor) • VMM? → コンテナ目線で考えるUnikernelとmicroVM(前回の資料) • 最低限のデバイスエミュレーションとC APIを備えたRust製のMicroVM ◦ virtio-console, virtio-fs, virtio-vsockなどを実装 ◦ Firecrackerなどからコードを拝借してるらしい • macOSでも動くっぽい(動作未確認) • C APIを提供しているのでライブラリとしても使える ◦ crunで実験的にサポートを開始 • ネットワークコンポーネントにvirtio-netは使わず、vsockベースのTSI(Transparent Socket Impersonation)という”革新的な方法”で自前実装 ◦ 依存関係ライブラリとして libkrunfwがある 現時点での疑問 ・なぜ既存のコード使ってまで新しく 作ったの？新規性は？
7. とりあえずデモ
8. しようとおもったらエラーで 動きませんでした😇😇😇
9. さわってみてわかること • コンテナのプロセス分離をVMでやるためのツール ◦ example手順ではPodmanの導入が必須 ◦ 現状crunとのインテグレーションをサポートしてるっぽい • Upstreamをpullしてきてもexampleが動かなくてつらい ◦ Fedoraで配布されてるバイナリを dnfから引っ張ってきたらうまくいく？ → やっぱなんかだめっぽい (原因がわからんので Issue立てた)
10. さわってみてわかること • コンテナのプロセス分離をVMでやるためのツール ◦ example手順ではPodmanの導入が必須 ◦ 現状crunとのインテグレーションをサポートしてるっぽい • Upstreamをpullしてきてもexampleが動かなくてつらい ◦ Fedoraで配布されてるバイナリを dnfから引っ張ってきたらうまくいく？ → やっぱなんかだめっぽい (原因がわからんので Issue立てた) ランタイムの分離レベルが VMなので、いわゆる サンドボックス型のランタイムに分類できる ・gVisor ・Kata container(QEMU) ・Firecracker(*ここでの分類は厳密にはちょっと違うが ..) など
11. 既存のVM型ランタイムとの違い
12. 既存のVM型ランタイムとの違い LinuxのnamespaceはPodごとに分割 VMがnamespaceごとなのでコンテナ間では共有 のVMを使う →コンテナプロセスはKVM(ホスト上でのプロセス) の子プロセス的な扱い
13. 既存のVM型ランタイムとの違い LinuxのnamespaceはPodごとに分割 VMがnamespaceごとなのでコンテナ間では共有 のVMを使う →コンテナプロセスはKVM(ホスト上でのプロセス) の子プロセス的な扱い Docker + Kataでやってみると・・・ Dockerの中でcontainerdが動いてその後ろで KataのFirecrackerプロセス→kata-shimの順番で プロセスが生えている
14. 既存のVM型ランタイムとの違い VMが分かれていても同じコンテキストで処理が行われる crun(コンテナランタイム)のプロセス=VMのプロセス →crun実行時にVMが立ち上がる
15. Namespace内における独立したVM間の連携
16. Namespace内における独立したVM間の連携 VMをPodごとに作らないので Namespace内のコンテナを動的に管理できる? 異なるVMで実行されている場合でも マウントポイントとNetwork namespace を介してコンテナ間で通信
17. Deeper dive...したい... • 既存の仮想化やラインタイム周りの知識、Rust力が欠如しすぎてて これ以上わからなかった(つらい) • 開発者(RHのエンジニア)のスライドにも詳しく書かれている • 誰か知見を教えて下さい！！！！！！！！！！！！！！！！！！！！！
18. ありがとうございました