Rustで書かれたKubernetesのためのWASM実行環境Krustletとは？

Deis Labsが新しいオープンソースソフトウェア「Krustlet」を発表した。これはメモリーセーフなプログラミング言語Rustで開発されたソフトウェアで、新しいバイナリーフォーマットWebAssemblyのコードを実行することが可能になる。

Deis LabsはMicrosoftが2017年に買収したクラウドネイティブに特化したソフトウェアを開発するベンチャーで、KubernetesのパッケージマネージャーHelmなどを開発していることでも知られている。Kubernetesは、Googleが社内で利用していたクラスター上でコンテナを管理するためのソフトウェアBorgがベースになっている。これをオープンソースソフトウェアとして公開するためにプロプライエタリなソフトウェアを書き換え、Kubernetesと命名して公開したものだ。KubernetesはGoogleが開発したプログラミング言語Goで書かれているために、Kubernetesに関連する多くのソフトウェアもGoで開発されている。GoもRustもメモリーセーフを謳ったモダンな開発言語だが、Rustは「高速な実行速度」「厳密な変数の所有ルール」「ガベージコレクションがないこと」などから、最近大きな注目を集めている。

Rustは、サービスメッシュのためのソフトウェアLinkerd2 proxyやMicrosoftのIoTのOSなどの開発にも使われており、近年ではDropboxがPythonで書かれたバックエンドのコードをRustで書き換えることを表明した。またAppleがRustでバックエンドを書き換えるためのデベロッパーを募集していたことが話題になっていたほどに、昨今Rustに対する期待が高まっていると言える。

参考：DropboxがコアサービスをRustで書き換えた背景とは

WebAssemblyは元々、JavaScript以外の開発言語をWebブラウザーに導入することを主眼に開発されたバイナリーフォーマットだが、Webブラウザーという枠から脱却して、サーバーサイドで実行することでさまざまな開発言語の違いを吸収して実行できるというのがWebAssemblyのランタイムWASIである。

DockerのSolomon Hykes氏が2019年3月に「もしもWebAssemblyとWASIが2008年に存在していたら、Dockerを開発する必要はなかった」とツイートしたエピソードからもわかるように、LinuxやWindowsといったオペレーティングシステムを意識せずにさまざまな言語で書かれたコードをサーバーサイドで実行することが、Linux ContainerやWindows Containerと同じように重要になると予言したのは印象的だ。

またHykes氏は、Linux ContainerやWindows Containerと同様に「WASM Containerが実行される未来がくる」と予言したが、それをKubernetes上で実装したのが、今回発表されたKrustletとも言えるだろう。

概要としてのKrustletはDeis Labsのブログ記事を参照されたい。

参考：Introducing Krustlet, the WebAssembly Kubelet

Krustletのゴール

ここにはKrustletの目的として、「WebAssemblyのワークロードをKubernetes上で動かす」ことと並べて「Goで書かれたプログラムが多いKubernetesにRustでもプログラムが書けることを実証するため」と明記されている。「RustでKubernetesのコントローラーを書くことはGoよりも遥かに簡単である」というのが、以下のブログに書かれていることからもわかるように、GoをベースにしたKubernetesにおいても、Rustで書くことを推奨するというのがKrustletの目的だ。

参考：Writing a Kubernetes CRD Controller in Rust

またWebAssemblyとLinux Containerの違いについても説明を行っている。コンテナはLinuxのカーネルを共有するが、namespaceによってお互いのプロセスは独立しているためにサンドボックスとして影響を与え合わないような構造になっている。一方WebAssemblyはバイナリーフォーマットとしてプロセッサやOSに依存せずに実行できるため、真の「Compile Once, Run Anywhere」を実装しているという。

そのため、Linux ContainerとWebAssemblyは対立するものではなく、お互いが補完するものであるというのが、この記事を書いたMatt Butcher氏の主張だ。KrustletではVirtual Kubeletと同様の仕組みとしてKubernetesから認識され、Kubernetesの上で稼働する他のPodと同様に実行される。しかしKrustletの場合は、WASIの上で実行されるWebAssemblyのバイナリーであるという部分が他とは異なることになる。

Webブラウザーから始まったJavaScript以外のコードを安全に高速実行するという理念が、ブラウザーからサーバー、そしてKubernetesの上に拡がってきたと言っていいだろう。それをオープンソースコミュニティが凄まじいスピードで実装したことを高く評価したい。

KrustletはNodeとして認識される

Deis LabsだけではなくMicrosoftからもKrustletに関するブログが公開されている。

参考：WebAssembly meets Kubernetes with Krustlet

この記事によれば「コンテナのオーバーヘッドを最小にするために、gVisorのようなより小さなランタイムを使う方法論の発展型として、WebAssemblyを使ってコードを実行する選択肢がある。その実装がKrustletである」というのがMicrosoftの見方だ。この記事でもSolomon Hykes氏のWebAssemblyとWASIがあればDockerは不要だったというツイートが紹介されており、Linuxコンテナによる実行環境のサンドボックス化の進化形態が、WebAssemblyとWASIであるというツイートに注目していることがわかる。

Solomon Hykes氏のツイートを紹介

またこの記事では、WebAssemblyとWASIはコンテナに比べて2つの大きな利点があるという。1つ目は「コンテナよりも少ないリソースで実行でき、高速であること」、2つ目が「デフォルトでは何の特権も持っておらず、明示的に特権を与える必要がある」ことだという。コンテナのオーバーヘッドを減らすためにさまざまなランタイムが開発されたこと、そしてroot権限を与えてしまうことでセキュリティ上の問題が起こってしまうこと。コンテナが抱えるこの2つの問題点を解決しているというのが、WebAssemblyに対するMicrosoftの見解だ。

また当初はコンテナランタイムとして開発をしようと思っていたが、コンテナランタイムはあくまでも「コンテナを実行するためのもの」であり、WebAssemblyのコードを実行するためにはKubeletの方式が合っているとして方向転換を行ったことも明記されている。

またGoと比較してRustで開発を行うことが素晴らしい体験であり、他のデベロッパーにも推奨したい、Rustを使うことがVirtual Kubeletに依存せずに別の実装を行う大きな理由であったと解説している。

しかしMicrosoftもKubernetesで実行される大部分はこれまで通りコンテナのPodであり、ツールや環境などすでにできあがっているエコシステムを無視してWebAssemblyに置き換える必要はないことも明言している。つまりARMプロセッサやリソースが最小限の実行環境（IoTエッジなど）においてはKrustletは有効だが、これまでのワークロードとも共存できるし、するべきだというのがKrustletの位置付けだ。

将来のバージョンではボリュームのマウントなども予定されている

Kubernetesの世界にWebAssemblyが入ってきたことを歓迎するべきだろうし、オーバーヘッドとセキュリティという大きな問題点についても一つの解決策を与えたことは評価するべきだ。ただRustそしてWebAssemblyのエコシステム自体がKubernetesやコンテナに比べて貧弱なことは否めない。今後はより多くのデベロッパーや企業が参入してくるだろう。今後もWebAssembly、そしてRustの将来に注目したい。