2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
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の誤りでした。お詫びして訂正いたします。
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略