Tweet
Tweet

Slide 1

Slide 1 text

10分で完全理解する したかった libkrun Kernel/VM探検隊online part2 Presented by @_inductor_

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Disclaimer 今日はコンテナがちょっと好きな素人がちょっと低めのレイヤに手を出したらやけどし て何もわからなかったという話をします 低レイヤに気軽に手を出してもらうためのきっかけにしてください！！！ 低めのレイヤが好きな皆様にあたりましては、ツッコミとアドバイスをしていただきつ つ、発表者の理解度を上げていただけますようお願い申し上げます😭

Slide 4

Slide 4 text

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がある

Slide 5

Slide 5 text

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がある 現時点での疑問 ・なぜ既存のコード使ってまで新しく 作ったの？新規性は？

Slide 6

Slide 6 text

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がある 現時点での疑問 ・なぜ既存のコード使ってまで新しく 作ったの？新規性は？

Slide 7

Slide 7 text

とりあえずデモ

Slide 8

Slide 8 text

しようとおもったらエラーで 動きませんでした😇😇😇

Slide 9

Slide 9 text

さわってみてわかること ● コンテナのプロセス分離をVMでやるためのツール ○ example手順ではPodmanの導入が必須 ○ 現状crunとのインテグレーションをサポートしてるっぽい ● Upstreamをpullしてきてもexampleが動かなくてつらい ○ Fedoraで配布されてるバイナリを dnfから引っ張ってきたらうまくいく？ → やっぱなんかだめっぽい (原因がわからんので Issue立てた)

Slide 10

Slide 10 text

さわってみてわかること ● コンテナのプロセス分離をVMでやるためのツール ○ example手順ではPodmanの導入が必須 ○ 現状crunとのインテグレーションをサポートしてるっぽい ● Upstreamをpullしてきてもexampleが動かなくてつらい ○ Fedoraで配布されてるバイナリを dnfから引っ張ってきたらうまくいく？ → やっぱなんかだめっぽい (原因がわからんので Issue立てた) ランタイムの分離レベルが VMなので、いわゆる サンドボックス型のランタイムに分類できる ・gVisor ・Kata container(QEMU) ・Firecracker(*ここでの分類は厳密にはちょっと違うが ..) など

Slide 11

Slide 11 text

既存のVM型ランタイムとの違い

Slide 12

Slide 12 text

既存のVM型ランタイムとの違い LinuxのnamespaceはPodごとに分割 VMがnamespaceごとなのでコンテナ間では共有 のVMを使う →コンテナプロセスはKVM(ホスト上でのプロセス) の子プロセス的な扱い

Slide 13

Slide 13 text

既存のVM型ランタイムとの違い LinuxのnamespaceはPodごとに分割 VMがnamespaceごとなのでコンテナ間では共有 のVMを使う →コンテナプロセスはKVM(ホスト上でのプロセス) の子プロセス的な扱い Docker + Kataでやってみると・・・ Dockerの中でcontainerdが動いてその後ろで KataのFirecrackerプロセス→kata-shimの順番で プロセスが生えている

Slide 14

Slide 14 text

既存のVM型ランタイムとの違い VMが分かれていても同じコンテキストで処理が行われる crun(コンテナランタイム)のプロセス=VMのプロセス →crun実行時にVMが立ち上がる

Slide 15

Slide 15 text

Namespace内における独立したVM間の連携

Slide 16

Slide 16 text

Namespace内における独立したVM間の連携 VMをPodごとに作らないので Namespace内のコンテナを動的に管理できる? 異なるVMで実行されている場合でも マウントポイントとNetwork namespace を介してコンテナ間で通信

Slide 17

Slide 17 text

Deeper dive...したい... ● 既存の仮想化やラインタイム周りの知識、Rust力が欠如しすぎてて これ以上わからなかった(つらい) ● 開発者(RHのエンジニア)のスライドにも詳しく書かれている ● 誰か知見を教えて下さい！！！！！！！！！！！！！！！！！！！！！

Slide 18

Slide 18 text

ありがとうございました