ベテラン Kubernetes エンジニアの目から見た WebAssembly の未来

Kubernetes Community Days のパサデナ会場 (SCaLE 20x と同時開催) で、私は 100 人ほどのKubernetes愛好家と話す機会があり、Kubernetes のベテランの視点から WebAssembly についての私の見解を伝えることができました。

私はこの特定のゲームにスキンを持っていると言うことでこれを修飾する必要があります。私は最初から Kubernetes に携わっており、初期の頃はDocker (0.6 っぽい) から始めて、1.2 から Kubernetes に取り組んでおり、Kubernetes プラットフォームが普及する前に構築していました。私は Helm のコア メンテナを 4 年間務め、WebAssembly を Kubernetes とうまく連携させるための初期の取り組みである Bindle と Krustlet の共同作成者でした。長々と言いましたが、完全に理解しています。コンテナと Kubernetes の長所と問題点を理解しています。

私も WebAssembly 分野の出身で、ここ 3 年ほど深く関わっています。両方の陣営に足を踏み入れているので、これら 2 つのオープンな取り組みが何に役立つのか、そして交差点はどのようなものになる可能性があるのか​​、またあるべきなのかについて、私の見解を以下に示します。

Kubernetes と Docker は、プラットフォーム エンジニアや開発者がモノリスをマイクロサービスとアプリケーションに分割し、残りのインフラストラクチャから分離して管理できるようにしたため、ゲームチェンジャーでした。 WebAssembly はさらに深いレベルに進み、個々のアプリケーションを構成可能なコンポーネントに分割し、周囲に合わせて個別にホットスワップ、管理、構成できるようにします。 Wasm は基本的に、デフォルトで安全、移植可能、多言語対応 (特にブラウザ内)、高速、効率的、および拡張性が高く、サーバーサイド コードに必要なものすべてを備えています。

では、Kubernetes と Wasm はどのように交差するのでしょうか?まず、ソーシャルメディアの噂話に対処し、いくつかの誤解を打ち破ってみましょう。

誤解 1: Wasm はコンテナを強制終了します。

いいえ。絶対にありません。コンテナーで問題なく動作するRedis をブラウザーで動作するように書き直す人は誰もいません。 Kubernetes が適切なソリューションである例は数多くあります。長い間存在している大規模なエンタープライズ アプリ (Drupal、Redis、nginx) が数多くありますが、すぐには Wasm に移行されません。

誤解 #2: コンテナ内で Wasm を実行すべきですよね?

すべきではないと言っているわけではありませんが、それは適切な出発点ではなく、複雑なレイヤーを追加するだけになる可能性があります。 WebAssembly を起動するオーバーヘッドに、Docker コンテナー (クロスプラットフォームではない) を起動するオーバーヘッドが追加されます。特に後で説明する利用可能なツールをすべて使用する場合、パフォーマンスのオーバーヘッドを考えるとおそらく価値がありません]

誤解 3: Wasm は Kubernetes と互換性がありません。

はい、そうです！これは「Better Together」の物語です。コンピューターによってあらゆるものが進化します。 VM を思いついたからといって、物理ハードウェアが必要ないというわけではありません。 Wasm が登場したからといって、コンテナが必要ないというわけではありません。これが実際に行われている様子を確認するには、Adobe の友人たちがWasm を使用して Kubernetes アーキテクチャをどのように変換しているかを読んでください。

Kubernetes の初期の頃と同様に、私たちは現在、物事が非常に急速に破壊され、進化している段階にいます。生の Wasm レベルでは、サーバー側のネットワーキングはまだ困難です。私たちは間もなくソケットのサポートを取得する予定で、物事は急速に進んでいます。言語ツールチェーンと低レベルのパフォーマンス コードも重要ですが、まだ実現していません。それにしても、刺激的な瞬間ですね。 WASI (非ブラウザ Wasm) 標準は、ここ数週間であっても大きな進歩を遂げました。これについては後ほど詳しく説明します。

なぜワズム?

実のところ、 Kubernetes には、特にエッジにおいて限界があります。多くの進歩が見られましたが（K3 のようなプロジェクトに大きな声援を送ります）、物事が進むには限界があります。 Kubernetes は、ほとんどの場合、同じ地理的領域の一部であるクラスター内で実行されることを目的としています。携帯電話の基地局、発電所、実店舗で何かが実行されている場合、Kubernetes はあまりうまく拡張できません。私たちはコミュニティのメンバーと話をしたときにこれを確認しました。 Wasm は真のクロスプラットフォーム アーキテクチャであり、非常に小規模で動作するため、エッジのより良い候補になります。

コストと使用率も主要な要素です。私たちはフォーチュン 100 企業数社と話をしましたが、その Kubernetes サーバーの使用率は総容量の約 25 ～ 35% であり、50 ～ 60% に達する企業もいくつかあります。コストが非常に高いため、多くの企業が社内の Kubernetes チームを分離しました。 Wasm を使用すると、より小さなスペースに多くのものを詰め込み、スペースをより有効に活用できるようになります。

セキュリティもWasm の大きな利点です。コンテナーはかなり安全ですが、特に開発者にとって複雑さを生み出す微妙な点がたくさんあります。デフォルトでは、WebAssembly モジュールは、権限を付与しない限り何も実行できません。

Kubernetes と Wasm を使って今何ができるでしょうか?

そうは言っても、現時点で Wasm と Kubernetes を使用して実際に何ができるのでしょうか? Wasm をすぐに活用できる 3 つの最大のシナリオを確認してみましょう。

CNCFコンテナーでのrunwasi

Wasm を使用する非常に優れた方法の 1 つは、CNCF のcontainerd エコシステムの一部である素晴らしいrunwasiプロジェクトをチェックすることです。基本的に、 runwasi 、Kubernetes 内の containerd shim を介して WebAssembly ランタイムを実行できます。これは、ポッド内でコンテナーをスピンアップする場合と同様に、WebAssembly を直接実行するため、コンテナー内で Wasm を実行しようとするよりもはるかに優れたオプションです。

サービスメッシュ、誰か？

Envoy やその他のメッシュには、WebAssembly を使用してプラグインを作成する機能がすでにあります。これらを使用すると、WebAssembly にコンパイルできる任意の言語を使用して、カスタム フィルタリングやその他のプラグイン モデルを作成できます。

ワズムクラウド

企業がすでに、さまざまなユースケースで Kubernetes と Wasm を連携させることに価値を見出していることを私たちは知っています。しかし、wasmCloud は、フラット ネットワーク トポロジで異種のコンピューティングを接続できる機能により、それを次のレベルに引き上げます。 2 番目のデモでは、それぞれ異なる場所にある 3 つの異なるノード間で同じコードを移動することがいかに簡単かを示しました。この場合、パサデナにある私の Mac、ニューヨークにある Digital Ocean K8s クラスター、および wasmCloud です。リファクタリングなし、同じコード、場所を選びません。次に、Cosmonic プラットフォーム (wasmCloud 上に構築) は、企業が本番環境に移行する際に必要となるフルサービスのアプローチを Wasm に提供します。

マネージド プラットフォームで wasmCloud を試してみませんか?

今すぐ無料で Cosmonic を始めましょう。今すぐ起動してください!

コンポーネントモデル

最後に、そして最も興味深いことに、この分野では物事が急速に進んでいます。 Bailey Hayes と Dan Chiarlone のWASM I/O講演をご覧ください。この講演では、WASI 標準とコンポーネント モデルの定義がどこまで進んでいるのかが示されました。これは、私たちが本当に望んでいる将来の姿を初めて示したものでした。ここで進捗状況を追跡し、 Bytecode Allianceに参加して最新情報を聞くことができます。

- Taylor Thomas著、Cosmonic エンジニアリング リード

さらに詳しく知りたい場合、質問がある場合、またはチャットしたい場合は、 DiscordまたはSlackでご連絡ください。