
2025.02.06
ポンコツ期、孤独期、成果独り占め期を経て… サイボウズのプロマネが振り返る、マネージャーの成長の「4フェーズ」
Red Hatが新しく作り始めたVMMの話(全1記事)
リンクをコピー
記事をブックマーク
太田航平氏:これから「10分で完全理解したかったlibkrun」という話をしていきます。よろしくお願いします。
まずちょっと自己紹介をすると、太田と言います。ふだんインターネットではinductorという名前で活動していて、本職は日本ヒューレット・パッカード合同会社という会社で、DockerやKubernetesを使った基盤のアーキテクトをしています。
コミュニティ活動は「Container Runtime Meetup」とか「Cloud Native Days」というカンファレンスの運営をやったり、あとは「CNCF」という謎の団体のアンバサダーをやったりしています。好きなことは無限にスケールするインフラ(無限にスケールするとは言っていない)です。
今日はけっこうギリギリまでスライドを作るのをさぼっていたのですが、内容としては「コンテナが好きな素人が、ちょっと低いレイヤーに手を出そうとしたらぜんぜんわからなかった。つらい。」みたいな話をしようとしています。意図としては、低レイヤーに気軽に手を出しても意外とわかるところがあっておもしろいよというきっかけにしてもらえるといいなというところです。みなさまにツッコミとアドバイスをもらえるとうれしいなと思います。
そもそもタイトルにあるlibkrunは、Red Hatのエンジニアが作り始めたVirtual Machine Monitor(VMM)のことです。VMMとは何ですか? という人は、僕が前回のKernel/VM探検隊 part1で話した「コンテナ目線で考えるUnikernelとmicroVM」を読んでもらえるとだいたいわかるんじゃないかなと思います。
これもmicroVMの一種で、最低限のデバイスエミュレーションとライブラリとして使えるように、CのAPIを備えたRust製のMicroVMになっています。実装のけっこうなパートがFirecrackerとかrust-vmmとか、別のOSSから拝借している部分が多くて、デバイスとしてはvirtioのconsole、fs、vsockとかをサポートしています。
Firecrackerとかからもけっこうなコードを取っていて、なんでわざわざ既存のコードをたくさん使ってまでこんなものを新しく作ったんだろうなと、最初に疑問に思って調べ始めたのがきっかけです。どうやらmacOSでも動くらしいのですが、僕は今Macをもっていないので未確認です。
あとはCのAPIがあるので、ライブラリとしても使えて、実際にcrunというRed Hatが開発している低レベルのコンテナランタイムでも実験的にサポートを開始しています。
特徴としては、ネットワークコンポーネントやストレージの部分でけっこう新しいアプローチを実装をしています。ネットワークだと「革新的な方法」のTransparent Socket Impersonationを実装していて、libkrunfwという依存関係のライブラリがあります。
見てみると、ライブラリとして使えるLinux関連のバインディングをしているもので、ライブラリが依存関係で、この中でネットワーク回りの実装とかをしているそうです。
作っている本人が、M1 MacでLinuxが直接動いているみたいなことをツイートしていておもしろいなと思いました。
デモなんですが、ちょっと僕の手元の環境だとエラーで動かなくてデモができない致命的な状況です。ただいくつか触ってみて、コンテナのプロセス分離をVMがやるためのツールであることがわかりました。なので、Virtual Machine Monitorと言いつつ、QEMUみたいなジェネリックなバーチャルマシン用の実装ではなくて、コンテナに特化したミニマリスト思考な実装になっています。
exampleの手順の中だと、PodmanというRed Hatが作っているDockerみたいなものが導入が必須であって、それの上で別のルートファイルシステムをコンテナ用に展開して動かすみたいなことをやっています。さっきも言いましたが、crunとのインテグレーションがサポートされていて、crunを動かす時のランタイムに、このlibkrunを指定することができて、いい感じにVMを切り出せるようになっていました。
コンテナは普通、プロセス分離をLinuxカーネルの中でnamespaceを切ってやるんですが、この場合はVMを立ててやっているんですね。サンドボックス型のランタイムに分類できるので、gVisor、Kata container、あとはここで分類すると若干語弊があるんですがFirecrackerなど、このあたりの実装に非常に近いというかたちになっています。
これらの既存のVM型ランタイムなどがあるにもかかわらず、なんでわざわざこれを作ったかのかは、本人がカンファレンスで発表した資料の中に詳しく書かれています。既存の実装では、Podという複数のコンテナを1つのコンテキストにまとめるオブジェクトがあって、そのオブジェクトごとにnamespaceが切られるんですね。
実装の都合でnamespaceごとにVMを立てているので、例えば複数のコンテナを有するPodの場合、VMがその複数のコンテナを内包するかたちで1つ立ち上がってきます。実際のコンテナプロセスはKVMの中でさらに子プロセス的な扱いで、KVMを1つのホスト上のプロセスと見た時にさらにその子プロセスとして2つ生えてきます。
Dockerで実際にKata containerを使ってやってみると、Dockerの後ろでcontainerdが動いて、containerdの中でFirecrackerのVMがKata containerによって作られて、さらにその後ろでkata-shimというruncみたいなものを動かしているやつがいて……とポンポンとチャイルドプロセスがいくつか生えているのがわかります。
これが新しい実装のlibkrunだと、コンテナごとにVMが立ち上がります。このコンテナ間でnamespaceを共有して使うようになっているので、もっと隔離性が高いよみたいなことを謳っています。
これがVM間の連携の図です。virtioのvsockを使ったネットワークの実装と、virtioのfsを使ったボリュームの確認を行ったあとでnamespaceを共有して、いい感じに連携しているらしいです。僕はきちんと中身を読めていないので、実際にこれがどうなっているかまではごめんなさい、わからないです。
「VMをPodごとに作らない」のは、コンテナレベルまで分離ができるので、namespaceの中にいるコンテナを動的に管理できるのがメリットかなと思いました。異なるVMで実行されている場合においても、これらのマウントポイントを使ってコンテナ間で通信ができるので柔軟性があります。なので、コンテナのPodの中の構成がごちゃごちゃ変わってしまった時に、VMごとに作り直さなくても動的に管理ができるのがメリットなのかなと思います。
Deeper diveしたいところですが、さっき言ったとおりデモをしたくても僕の環境では動かせませんでした。CentOSとかFedoraとか、いろいろと使ってもダメだったので難しかったのと、そもそも既存の仮想化や既存のランタイムをそこまで深く理解できていなくて、Rust力が欠如していたので何もわからなくなってつらくなってしまいました。
これ以上のことは、開発者のスライドにも詳しく書かれているので気になる方はそちらもご覧ください。そして、スライドやソースコードを読んだ暁には僕にも知見を共有してほしいなと思っています。今回の発表は、紹介しつつ僕より詳しい人に教えてほしいというお願いの発表でした。というわけで以上です。ありがとうございました。
※掲載当初、一部「型コンテナ」となっていましたが、Kata containerの誤りでした。お詫びして訂正いたします。
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
2025.02.03
手帳に書くだけで心が整うメンタルケアのコツ イライラ、モヤモヤ、落ち込んだ時の手帳の使い方
2025.01.30
2月の立春までにやっておきたい手帳術 「スケジュール管理」を超えた、理想や夢を現実にする手帳の使い方
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.01.29
社内会議は「パワポ」よりも「ドキュメントの黙読」が良い理由 Amazon元本社PMが5つのポイントで教える、資料の書き方
2025.01.31
古い手帳から新しい手帳への繰り越し方 手帳を買い換えたら最初に書き込むポイント
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由