Istioのための宣言型WebAssemblyデプロイメント

EnvoyとIstioのWasm拡張機能を宣言的に設定します。

2020年3月16日 | Christian Posta - Solo.io

Istio 2020 trade windsブログ、そして最近Istio 1.5で発表されたように、WebAssembly（Wasm）はIstioサービスプロキシ（Envoyプロキシ）の機能を拡張するための（アルファ）オプションになりました。Wasmを使用すると、ユーザーは新しいプロトコル、カスタムメトリクス、ロガー、その他のフィルターのサポートを構築できます。Googleと緊密に協力して、コミュニティ（Solo.io）では、IstioへのWasm拡張機能の構築、共有、デプロイのユーザーエクスペリエンスに重点を置いてきました。WebAssembly Hubと関連ツールを発表し、Wasmを扱うための「dockerライク」なエクスペリエンスを構築しました。

背景

WebAssembly Hubツールを使用すると、wasme CLIを使用してEnvoy用のWasmプロジェクトを簡単にブートストラップし、リポジトリにプッシュし、Istioにプル/デプロイできます。たとえば、wasmeを使用してWasm拡張機能をIstioにデプロイするには、次のコマンドを実行します。

$  wasme deploy istio webassemblyhub.io/ceposta/demo-add-header:v0.2 \
  --id=myfilter \
  --namespace=bookinfo \
  --config 'tomorrow'

これにより、bookinfo名前空間で実行されているすべてのワークロードにdemo-add-header拡張機能が追加されます。--labelsパラメーターを使用することで、どのワークロードに拡張機能を適用するかをより詳細に制御できます。

$  wasme deploy istio webassemblyhub.io/ceposta/demo-add-header:v0.2 \
  --id=myfilter  \
  --namespace=bookinfo  \
  --config 'tomorrow' \
  --labels app=details

これは、EnvoyFilterリソースを手動で作成し、対象とするワークロードの一部である各ポッドにWasmモジュールを取得しようとするよりもはるかに簡単なエクスペリエンスです。しかし、これはIstioと対話する非常に命令的なアプローチです。ユーザーは通常、本番環境で直接kubectlを使用せず、宣言的なリソースベースのワークフローを好むように、Istioプロキシのカスタマイズについても同様のアプローチを望んでいます。

宣言型アプローチ

WebAssembly Hubツールには、IstioワークロードにWasm拡張機能をデプロイするためのオペレーターも含まれています。オペレーターを使用すると、ユーザーは宣言型の形式でWebAssembly拡張機能を定義し、デプロイメントの修正をオペレーターに任せることができます。たとえば、FilterDeploymentリソースを使用して、どのイメージとワークロードに拡張機能が必要かを定義します。

apiVersion: wasme.io/v1
kind: FilterDeployment
metadata:
  name: bookinfo-custom-filter
  namespace: bookinfo
spec:
  deployment:
    istio:
      kind: Deployment
      labels:
        app: details
  filter:
    config: 'world'
    image: webassemblyhub.io/ceposta/demo-add-header:v0.2

次に、このFilterDeploymentドキュメントを取得し、他のIstioリソースと共にバージョン管理することができます。Istioに既にEnvoyFilterリソースがある場合に、なぜこのカスタムリソースが必要なのか疑問に思われるかもしれません。

それでは、これらが内部でどのように機能するのかを見てみましょう。

動作方法

内部的には、オペレーターはWasm拡張機能をIstioサービスプロキシ（Envoyプロキシ）にデプロイおよび設定する際に役立ついくつかの処理を実行します。

How the wasme operator works
wasmeオペレーターの動作を理解する

現時点では、Wasmイメージをレジストリに公開する必要があります。オペレーターが正しくキャッシュするためです。キャッシュポッドは各ノードでDaemonSetとして実行されるため、キャッシュをEnvoyコンテナにマウントできます。これは理想的なメカニズムではないため、改善されています。理想的には、何もマウントする必要がなく、HTTP経由でプロキシにモジュールを直接ストリーミングできるようになります。そのため、更新にご期待ください（今後数日中にリリースされる予定です）。マウントは、sidecar.istio.io/userVolumeおよびsidecar.istio.io/userVolumeMountアノテーションを使用して確立されます。Istioリソースアノテーションに関するドキュメントで、その動作の詳細を確認できます。

Wasmモジュールが正しくキャッシュされ、ワークロードのサービスプロキシにマウントされると、オペレーターはEnvoyFilterリソースを構成します。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: details-v1-myfilter
  namespace: bookinfo
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: envoy.http_connection_manager
            subFilter:
              name: envoy.router
    patch:
      operation: INSERT_BEFORE
      value:
        config:
          config:
            configuration: tomorrow
            name: myfilter
            rootId: add_header
            vmConfig:
              code:
                local:
                  filename: /var/local/lib/wasme-cache/44bf95b368e78fafb663020b43cf099b23fc6032814653f2f47e4d20643e7267
              runtime: envoy.wasm.runtime.v8
              vmId: myfilter
        name: envoy.filters.http.wasm
  workloadSelector:
    labels:
      app: details
      version: v1

EnvoyFilterリソースは、envoy.filter.http.wasmフィルターを追加し、wasme-cacheからWasmモジュールをロードするようにプロキシを構成していることがわかります。

Wasm拡張機能がIstioサービスプロキシにロードされると、導入したカスタムコードを使用してプロキシの機能が拡張されます。

次のステップ

このブログでは、IstioワークロードにWasm拡張機能をインストールするためのオプションについて説明しました。IstioでWebAssemblyを始める最も簡単な方法は、wasmeツールを使用して新しいWasmプロジェクトをC++、AssemblyScript [またはRust（近日公開！)]でブートストラップすることです。たとえば、C++ Wasmモジュールを設定するには、次のコマンドを実行します。

$ wasme init ./filter --language cpp --platform istio --platform-version 1.5.x

追加のフラグがない場合、wasme initは対話モードに入り、選択する正しい値を案内します。

IstioでWasmを始めるには、WebAssembly Hub wasmeツールをご覧ください。

詳細情報

この記事を共有する