Higress は現在最高のクラウドネイティブ ゲートウェイでしょうか?

Higress は、Alibaba の社内 Envoy Gateway プラクティスに基づいて構築され、オープンソースの Istio + Envoy をコアとするクラウドネイティブ API ゲートウェイです。トラフィックゲートウェイ + マイクロサービスゲートウェイ + セキュリティゲートウェイの高度な統合機能を実装し、Dubbo、Nacos、Sentinel などのマイクロサービス技術スタックを深く統合することで、ゲートウェイの展開と運用・保守コストを大幅に削減できます。標準の観点から Ingress および Gateway API を完全にサポートし、クラウド ネイティブにおける標準 API 仕様を積極的に採用しています。同時に、Higress Controller は Nginx Ingress のスムーズな移行もサポートしており、ユーザーはコストをかけずに Higress に迅速に移行できます。

業界では、ゲートウェイは通常、トラフィック ゲートウェイとビジネス ゲートウェイの 2 つのカテゴリに分類されます。トラフィック ゲートウェイは主に、バックエンド ビジネスとは関係のないグローバル ポリシー構成を提供します。たとえば、Alibaba の内部統合アクセス ゲートウェイ Tengine は、典型的なトラフィック ゲートウェイです。名前が示すように、ビジネス ゲートウェイは主に、バックエンド ビジネスと緊密に結合された独立したビジネス ドメイン レベルのポリシー構成を提供します。アプリケーション アーキテクチャ モデルが単一のエンティティから今日の分散マイクロサービスへと進化するにつれて、ビジネス ゲートウェイにもマイクロサービス ゲートウェイという新しい名前が付けられました。

仮想化時代のマイクロサービス アーキテクチャでは、企業は通常、トラフィック ゲートウェイ + マイクロサービス ゲートウェイの 2 層アーキテクチャを採用します。トラフィック ゲートウェイは南北トラフィックのスケジューリングとセキュリティ保護を担当し、マイクロサービス ゲートウェイは東西トラフィックのスケジューリングとサービス ガバナンスを担当します。コンテナと K8s が主流のクラウドネイティブ時代において、Ingress は K8s エコシステムのゲートウェイ標準となり、ゲートウェイに新たな使命を与え、トラフィック ゲートウェイ + マイクロサービス ゲートウェイを 1 つに統合することを可能にしました。

North-South パブリック ネットワーク ゲートウェイとして、異常なトラフィックを保護するために Waf を使用することは一般的な要件です。インターネット環境がますます複雑になるにつれ、ユーザーの保護に対する要求は高まり続けています。従来の方法では、まずトラフィックを Waf セキュリティ ゲートウェイに接続し、フィルタリングしてからトラフィックをトラフィック ゲートウェイに転送し、最終的にマイクロサービス ゲートウェイに到達します。 Higress は、組み込みの Waf モジュールを使用して、ユーザーのリクエスト リンクが Higress のみを通過するようにし、Waf 保護、トラフィック分散、マイクロサービス ガバナンスを同時に完了することを望んでいます。これにより、リンク RT が短縮されるだけでなく、ゲートウェイの運用と保守の複雑さも軽減されます。そのため、Higress はトラフィック ゲートウェイ + マイクロサービス ゲートウェイ + セキュリティ ゲートウェイの高度な統合機能を実現します。

使用シナリオ

Higress はさまざまな機能をサポートしており、さまざまなシナリオに適しています。

• Kubernetes イングレス ゲートウェイ:
  Higress は、K8s クラスターの Ingress ゲートウェイとして使用でき、多数の K8s Nginx Ingress アノテーションと互換性があるため、K8s Nginx Ingress から Higress への迅速かつスムーズな移行が可能になります。
  Gateway API 標準をサポートし、ユーザーが Ingress API から Gateway API にスムーズに移行できるようにします。
• マイクロサービスゲートウェイ:
  Higress はマイクロサービス ゲートウェイとして使用でき、Nacos、ZooKeeper、Consul、Eureka などのさまざまなタイプのレジストリ センターに接続して、サービス構成ルートを検出できます。
  また、Dubbo、Nacos、Sentinel などのマイクロサービス テクノロジー スタックも深く統合します。 Envoy C++ ゲートウェイ カーネルの優れたパフォーマンスに基づいて、従来の Java ベースのマイクロサービス ゲートウェイと比較して、リソースの使用率とコストを大幅に削減できます。
• セキュリティ保護ゲートウェイ:
  Higress はセキュリティ保護ゲートウェイとして使用でき、WAF 機能を提供し、key-auth、hmac-auth、jwt-auth、basic-auth、oidc などの複数の認証戦略をサポートします。

コアのメリット

• プロダクショングレード<br>2 年以上にわたって本番環境で検証された Alibaba の社内製品から生まれ、1 秒あたり数十万件のリクエストを処理する大規模なシナリオをサポートします。
  リロードによって発生するトラフィックのジッターを完全に排除し、構成の変更は数ミリ秒で有効になり、企業には気付かれません。
• スムーズな進化<br>Nacos/Zookeeper/Eureka などの複数の登録センターをサポートし、K8s Service に依存せずにサービス検出を実行でき、非コンテナ アーキテクチャからクラウド ネイティブ アーキテクチャへのスムーズな進化をサポートします。
  Nginx Ingress Controller からのスムーズな移行をサポートし、Gateway API へのスムーズな移行をサポートし、ビジネス アーキテクチャの ServiceMesh へのスムーズな進化をサポートします。
• 強力な互換性<br>Nginx Ingress Annotation の 80% 以上の使用シナリオと互換性があり、より豊富な機能を備えた Higress Annotation を提供します。
  Ingress API/Gateway API/Istio API と互換性があり、複数の CRD を組み合わせて洗練されたトラフィック管理を実現できます。
• 簡単に拡張可能<br>Wasm、Lua、アウトオブプロセスの 3 つのプラグイン拡張メカニズムを提供します。複数の言語で書かれたプラグインをサポートします。有効な粒度は、グローバル レベル、ドメイン名 レベル、ルーティング レベルをサポートします。
  プラグインはホット アップデートをサポートしており、プラグインのロジックと構成の変更はトラフィックに影響しません。

建築

全体として、Higress ゲートウェイは、コントロール プレーン コンポーネント higress-controller とデータ プレーン コンポーネント higress-gateway で構成されます。 higress-gateway はデータ トラフィックの伝送を担当し、higress-controller は構成の配信の管理を担当します。

ハイグレス

データ プレーン コンポーネント higress-gateway は、Envoy に基づいて開発されたゲートウェイ コンポーネントであり、トラフィックの受信と処理を担当します。 HTTP/1.1、HTTP/2、gRPC などのプロトコルをサポートし、TLS、mTLS、WAF、電流制限、回路遮断、再試行、負荷分散、ルーティング、転送、リダイレクト、クロスドメインなどの機能をサポートします。つまり、実際のトラフィック処理は higress-gateway で完了します。

コントロール プレーン コンポーネント higress-controller は、構成の配信の管理、Ingress API、Gateway API、Istio API、複数の登録センター、複数の認証および承認戦略、複数のプラグイン拡張メカニズム、および洗練されたトラフィック管理のための複数の CRD のサポートを担当します。つまり、すべての構成は higress-controller を介して higress-gateway に配信されます。

インストール

Higress のインストールは非常に簡単です。 Helm 経由でインストールするだけです。ニーズに合わせてカスタマイズしたい場合は、Helm パラメータを変更することでカスタマイズできます。完全なパラメータの概要については、「操作および保守パラメータの説明」を参照してください。よく使用されるカスタマイズ可能なパラメータは次のとおりです。

デフォルトでは、ingress-gateway は LoadBalancer サービスを通じて公開されます。クラスターが LoadBalancer タイプのサービスをサポートしていない場合は、higress-core.gateway.service.type パラメータを変更してサービス タイプを変更するか、higress-core.gateway.hostNetwork パラメータを変更してホスト ネットワークを直接使用することができます。たとえば、ここでは hostNetwork を使用してホスト ネットワークを直接使用します。

 helm repo add higress.io https://higress.io/helm-charts helm upgrade --install higress -n higress-system higress.io/higress --set higress-core.gateway.hostNetwork=true,higress-core.gateway.service.type=ClusterIP --create-namespace

また、Higress は Istio CRD (オプション) もサポートしていますが、事前にクラスターに Istio CRD をインストールする必要があります。 Istio をインストールしたくない場合は、Istio CRD のみをインストールすることもできます。

 helm repo add istio https://istio-release.storage.googleapis.com/charts helm install istio-base istio/base -n istio-system --create-namespace

このモードでは、Higress のデプロイメント パラメータを更新する必要があります。

 helm upgrade higress -n higress-system --set global.enableIstioAPI=true higress.io/higress --reuse-values

同様に、Higress は Gateway API CRD (オプション) もサポートしています。また、事前に Gateway API CRD をインストールする必要があります: https://github.com/kubernetes-sigs/gateway-api/releases。たとえば、ここでは CRD のバージョン 1.0.0 をインストールします。実際の状況に応じて具体的なバージョンを選択できます。

 kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/experimental-install.yaml

このモードでは、Higress のデプロイメント パラメータを更新する必要があります。

 helm upgrade higress -n higress-system --set global.enableGatewayAPI=true higress.io/higress --reuse-values

インストールが完了すると、Higress のデプロイメントを表示できます。

 $ kubectl get pods -n higress-system NAME READY STATUS RESTARTS AGE higress-console-796544b9df-9v5hn 1/1 Running 0 4m57s higress-controller-8d4bb7456-4nx6l 2/2 Running 0 4m57s higress-gateway-596f4f6d9-d46wg 1/1 Running 0 4m57s higress-gateway-596f4f6d9-mbhp9 1/1 Running 0 4m57s $ kubectl get svc -n higress-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE higress-console ClusterIP 10.96.2.141 <none> 8080/TCP 9m35s higress-controller ClusterIP 10.96.0.98 <none> 8888/TCP,15051/TCP,15010/TCP,15012/TCP,443/TCP,15014/TCP 9m35s higress-gateway ClusterIP 10.96.3.17 <none> 80/TCP,443/TCP 9m35s

次に、以下のようにIngressオブジェクトを作成して公開します。   higress-console  仕える：

 # higress-console.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: higress-console namespace: higress-system spec: ingressClassName: higress rules: - host: higress.k8s.local http: paths: - path: / pathType: Prefix backend: service: name: higress-console port: number: 8080

上記の Ingress オブジェクトを適用するだけです。

 $ kubectl apply -f higress-console.yaml $ kubectl get ingress -n higress-system NAME CLASS HOSTS ADDRESS PORTS AGE higress-console higress higress.k8s.local 80 15s

ここでは higress-gateway を hostNetwork モードに設定しているため、higress.k8s.local を higress-gateway が配置されている任意のノードに解決するだけで、higress.k8s.local を介して higress-console サービスにアクセスできるようになります。

管理者を初期化する

基本的な使い方

higress-console に初めてアクセスするときは、管理者アカウントを初期化する必要があります。初期化が完了したら、管理者アカウントを使用して higress-console コンソールにログインできます。

ハイグレスコンソール

次に、ルーティング ルール、サービス、証明書などの作成を含む、higress-console コンソールを介してゲートウェイを構成できます。

たとえば、次に示すように、デフォルトの名前空間には foo サービスがあります。

 # foo.yaml kind: Pod apiVersion: v1 metadata: name: foo-app labels: app: foo spec: containers: - name: foo-app image: higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/http-echo:0.2.4-alpine args: - "-text=foo" --- kind: Service apiVersion: v1 metadata: name: foo-service spec: selector: app: foo ports: # Default port used by the image - port: 5678

ここで、このサービスを指す http://foo.bar.com/foo に対応するルートを作成します。これを実現するには 2 つの方法があります。 1 つは higress-console コンソールを使用して作成する方法で、もう 1 つは YAML ファイルを使用して作成する方法です。

コンソール経由で作成

まず、左側のドメイン名管理ナビゲーション バーをクリックし、ページの右側にある [ドメイン名の作成] ボタンをクリックし、下の図のようにフォームに入力して [OK] ボタンをクリックします。

ドメインを作成する

次に、左側のルート管理ナビゲーション バーをクリックし、ページの右側にある [ルートの作成] ボタンをクリックし、下の図に示すようにフォームに入力して [OK] ボタンをクリックします (対象サービスを選択することに注意してください)。

ルートの作成

次に、ドメイン名 foo.bar.com を higress-gateway が配置されている任意のノードに解決して、foo.bar.com を介して foo-service サービスにアクセスできるようにする必要があります。

 $ curl http://foo.bar.com/foo foo

YAMLファイルで作成

YAML ファイル (実際には Ingress オブジェクト) を介してルートを作成することもできます。まず、   foo-route.yaml  ファイルを作成し、次の YAML を使用して必要なルーティング構成を作成します。

 # foo-route.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: foo spec: ingressClassName: higress rules: - host: foo.bar.com http: paths: - pathType: Prefix path: "/foo" backend: service: name: foo-service port: number: 5678

次に、上記の YAML ファイルを適用するだけです (最初にコンソールに追加されたドメイン名とルートを削除することを忘れないでください)。

 $ kubectl apply -f foo-route.yaml $ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE foo higress foo.bar.com 80 4s

また、foo.bar.com 経由で foo-service サービスにアクセスできるようになりました。

 $ curl foo.bar.com/foo foo

ただし、YAML ファイルで管理されているルーティング設定はコンソールに同期されないため、ルーティングを管理する際には注意が必要です。

高度な使用法

標準の K8s Ingress リソースは、単純なシナリオでのみ HTTP(S) トラフィック ルーティングを処理でき、トラフィックのセグメンテーション、タイムアウトの再試行、ヘッダー制御、クロスドメインなどの問題を処理することはできません。したがって、さまざまな Ingress コントローラはカスタマイズされた Ingress アノテーションを使用して Ingress 機能を強化します。一般的な Nginx Ingress コントローラーでは、トラフィック管理とセキュリティ保護の観点から Ingress の実装を拡張するために 100 を超えるアノテーションが導入されています。現在、Higress はほとんどの Nginx Ingress アノテーションと完全に互換性があるため、ユーザーは Nginx Ingress から Higress に簡単に移行できます。したがって、Nginx Ingress Annotations を引き続き使用して Higress を構成することができます。

使用習慣に応じて、Nginx Ingress Annotation プレフィックス nginx.ingress.kubernetes.io または Higress Ingress Annotation プレフィックス higress.io を引き続き使用できます。これら2つは同等です。以下では、Annotation を使用して Higress を構成する方法をいくつかの簡単な例で説明します。

クロスドメイン

クロスオリジン リソース共有 (CORS) を使用すると、Web アプリケーション サーバーはクロスドメイン アクセス制御を実行し、安全なクロスドメイン データ転送を実現できます。次のアノテーションを通じて、Higress のクロスドメイン ポリシーを設定できます。

• higress.io/enable-cors: true または false。クロスドメインを有効または無効にするために使用されます。
• higress.io/cors-allow-origin: 許可されたサードパーティのサイト、ワイルドカード ドメイン名をサポートし、カンマ区切りで、ワイルドカードをサポートします。デフォルト値は * で、すべてのサードパーティ サイトが許可されます。
• higress.io/cors-allow-methods: GET、POST、カンマ区切りなどの許可されたリクエスト メソッド。ワイルドカード * がサポートされています。デフォルト値は、GET、PUT、POST、DELETE、PATCH、OPTIONSです。
• higress.io/cors-allow-headers: 許可されたリクエスト ヘッダー (カンマ区切り)。ワイルドカード * がサポートされています。デフォルト値は、DNT、X-CustomHeader、Keep-Alive、User-Agent、X-Requested-With、If-Modified-Since、Cache-Control、Content-Type、Authorization です。
• higress.io/cors-expose-headers: 許可された応答ヘッダー（コンマ区切り）。
• higress.io/cors-allow-credentials: true または false。資格情報の持ち運びを許可するかどうか。デフォルトで許可されます。
• higress.io/cors-max-age: プリフライト結果の最大キャッシュ時間（秒単位）。デフォルト値は 1728000 です。

たとえば、クロスドメイン リクエストは example.com ドメインからのリクエストに制限され、HTTP メソッドは GET と POST のみ、許可されるリクエスト ヘッダーは X-Foo-Bar、資格情報は許可されないという要件が設けられています。次に、次のアノテーションを通じて Higress を構成できます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/enable-cors: "true" higress.io/cors-allow-origin: "example.com" higress.io/cors-allow-methods: "GET,POST" higress.io/cors-allow-headers: "X-Foo-Bar" higress.io/cors-allow-credentials: "false" name: demo spec: ingressClassName: higress rules: - http: paths: - backend: service: name: demo-service port: number: 80 path: /hello pathType: Exact

リライト

リクエストがターゲットのバックエンド サービスに転送される前に、Rewrite は元のリクエストのパスとホスト ドメインを変更できます。次のアノテーションを通じて、Higress の Rewrite 戦略を構成できます。

• higress.io/rewrite-target: パスの書き換え、キャプチャ グループ (Capture Group) をサポートします。
• higress.io/upstream-vhost: ホストを書き換えます。

書き換え 書き換えパス

バックエンド サービスに転送する前に、リクエスト example.com/test を example.com/dev に書き換えます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/rewrite-target: "/dev" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

バックエンド サービスに転送する前に、リクエスト example.com/v1/app からパス プレフィックス /v1 を削除します。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/rewrite-target: "/$2" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /v1(/|$)(.*) pathType: ImplementationSpecific

リクエスト example.com/v1/app をバックエンド サービスに転送する前に、パス プレフィックス /v1 を /v2 に変更します。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/rewrite-target: "/v2/$2" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /v1(/|$)(.*) pathType: ImplementationSpecific

書き換え 書き換えホスト

バックエンド サービスに転送する前に、リクエスト example.com/test を test.com/test に書き換えます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/upstream-vhost: "test.com" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

リダイレクト

リダイレクトは、元のクライアント要求をターゲット要求に変更します。

HTTP から HTTPS へのリダイレクトの設定

次のアノテーションを使用して、Higress が HTTP リクエストを HTTPS にリダイレクトするように構成できます。

• higress.io/ssl-redirect：HTTP から HTTPS へのリダイレクト
• higress.io/force-ssl-redirect: HTTP から HTTPS へのリダイレクト

Higress は上記の 2 つのアノテーションを区別せず、HTTP を HTTPS にリダイレクトするように強制します。

たとえば、リクエスト http://example.com/test を https://example.com/test にリダイレクトする必要がある場合、次のアノテーションを使用して Higress を設定できます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/ssl-redirect: "true" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

永久リダイレクト

• higress.io/permanent-redirect: 永続的なリダイレクトのターゲット URL。スキーム (http または https) を含める必要があります。
• higress.io/permanent-redirect-code: 永続的なリダイレクトの HTTP ステータス コード。デフォルトは 301 です。

たとえば、リクエスト http://example.com/test を http://example.com/app に永続的にリダイレクトするには、次のアノテーションを使用して Higress を設定できます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/permanent-redirect: "http://example.com/app" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

一時的なリダイレクト

• higress.io/temporal-redirect: 一時リダイレクトのターゲット URL にはスキーム (http または https) が含まれている必要があります。

リクエスト http://example.com/test を一時的に http://example.com/app にリダイレクトする必要があります。次のアノテーションを使用して Higress を設定できます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/temporal-redirect: "http://example.com/app" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

バックエンドサービスプロトコルの構成

Higress はデフォルトで HTTP プロトコルを使用して、リクエストをバックエンド ビジネス コンテナーに転送します。ビジネス コンテナーが HTTPS プロトコルを使用する場合は、注釈 higress.io/backend-protocol: "HTTPS" を使用できます。ビジネス コンテナが GRPC サービスを使用する場合、注釈 higress.io/backend-protocol: "GRPC" を使用できます。

Nginx Ingress と比較すると、バックエンド サービスが属する K8s サービス リソースのポート名が grpc または http2 として定義されている場合、注釈 higress.io/backend-protocol: "GRPC" を構成する必要はありません。Higress は自動的に GRPC または HTTP2 を使用します。

たとえば、HTTPS プロトコルを使用してリクエスト example/test をバックエンド サービスに転送する必要がある場合、次のアノテーションを使用して Higress を構成できます。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/backend-protocol: "HTTPS" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: / pathType: Exact

GRPC プロトコルを使用してリクエストの例/テストをバックエンド サービスに転送する必要がある場合、最初のアプローチは、次に示すようにアノテーションを使用することです。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/backend-protocol: "GRPC" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

2 番目の方法は、次に示すように、サービス ポート名を grpc として指定することです。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /order pathType: Exact --- apiVersion: v1 kind: Service metadata: name: demo-service spec: ports: - name: grpc # 指定Service Port Name 为grpc，Higress 会自动使用GRPC 协议port: 80 protocol: TCP selector: app: demo-service

タイムアウト

Higress はルーティング レベルでタイムアウト設定を提供します。 nginx ingress とは異なり、接続/読み取りタイムアウトと書き込みタイムアウトを区別せず、インターフェース処理の合計遅延を構成します。設定が行われていない場合は、デフォルトで制限はありません。たとえば、バックエンドが応答を返さない場合、ゲートウェイは無期限に待機します。

タイムアウトを 5 秒に設定します。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/timeout: "5" name: demo spec: ingressClassName: higress rules: - host: example.com http: paths: - backend: service: name: demo-service port: number: 80 path: /test pathType: Exact

グレースケールリリース

Higress は複雑なルーティング処理機能を提供します。 Ingress Nginx と同様に、Higress もヘッダー、Cookie、重みに基づいたグレースケール リリースをサポートしています。アノテーションを設定することでカナリアリリース機能を実現できます。カナリアリリース機能を有効にするには、アノテーション higress.io/canary: "true" を設定する必要があります。さまざまな注釈を通じて、さまざまなグレースケール リリース機能を実現できます。

複数のモードが同時に設定されている場合、グレースケール モードの選択優先順位は、ヘッダー ベース > Cookie ベース > 重みベース (高から低) となります。

次に、サンプル アプリケーションを使用して、グレースケール解放機能を説明します。

ステップ1. 本番環境アプリケーションをデプロイする

まず、本番環境用のアプリケーション リソース リストを作成します。

 # production.yaml apiVersion: apps/v1 kind: Deployment metadata: name: production labels: app: production spec: selector: matchLabels: app: production template: metadata: labels: app: production spec: containers: - name: production image: mirrorgooglecontainers/echoserver:1.10 ports: - containerPort: 8080 env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP --- apiVersion: v1 kind: Service metadata: name: production labels: app: production spec: ports: - port: 80 targetPort: 8080 name: http selector: app: production

次に、本番環境にアクセスするための Ingress リソース オブジェクトを作成します。

 # production-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: production spec: ingressClassName: higress rules: - host: echo.k8s.local http: paths: - path: / pathType: Prefix backend: service: name: production port: number: 80

上記のリソース オブジェクトを直接作成します。

 ☸ ➜ kubectl apply -f production.yaml ☸ ➜ kubectl apply -f production-ingress.yaml ☸ ➜ kubectl get pods -l app=production NAME READY STATUS RESTARTS AGE production-64cfc46b65-j6krb 1/1 Running 0 56s ☸ ➜ kubectl get ingress production NAME CLASS HOSTS ADDRESS PORTS AGE production higress echo.k8s.local 80 9s

アプリケーションが正常にデプロイされると、通常どおりアプリケーションにアクセスできるようになります。

 ☸ ➜ curl http://echo.k8s.local Hostname: production-64cfc46b65-j6krb Pod Information: node name: node1 pod name: production-64cfc46b65-j6krb pod namespace: default pod IP: 10.0.1.249 Server values: server_versinotallow=nginx: 1.13.3 - lua: 10008 Request Information: client_address=10.0.1.162 method=GET real path=/ query= request_versinotallow=1.1 request_scheme=http request_uri=http://echo.k8s.local:8080/ Request Headers: accept=*/* host=echo.k8s.local original-host=echo.k8s.local req-start-time=1713508680651 user-agent=curl/7.87.0 x-b3-sampled=0 x-b3-spanid=5ec284bec822750c x-b3-traceid=5c48c3cc4192ddc85ec284bec822750c x-envoy-attempt-count=1 x-envoy-decorator-operatinotallow=production.default.svc.cluster.local:80/* x-envoy-internal=true x-forwarded-for=192.168.0.112 x-forwarded-proto=http x-request-id=d42c8455-5b2e-471d-811c-65f80210ccec Request Body: -no body in request-

ステップ2. カナリアバージョンを作成する

上記の製品版の production.yaml ファイルを参照して、アプリケーションの Canary バージョンを作成します。

 # canary.yaml apiVersion: apps/v1 kind: Deployment metadata: name: canary labels: app: canary spec: selector: matchLabels: app: canary template: metadata: labels: app: canary spec: containers: - name: canary image: mirrorgooglecontainers/echoserver:1.10 ports: - containerPort: 8080 env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP --- apiVersion: v1 kind: Service metadata: name: canary labels: app: canary spec: ports: - port: 80 targetPort: 8080 name: http selector: app: canary

次に、トラフィックを分割するための注釈ルールを構成できます。

ヘッダーに基づくグレースケールリリース

グレースケール リリースにヘッダーを使用する必要がある場合は、次のアノテーションを使用して Higress のグレースケール リリース戦略を構成できます。

• higress.io/canary-by-header のみを構成します。リクエスト ヘッダーの名前に基づいてトラフィックを分割します。リクエストにこのヘッダーが含まれ、その値が always の場合、リクエスト トラフィックはグレースケール サービス エントランスに割り当てられます。それ以外の場合、要求トラフィックはグレースケール サービスに割り当てられません。
• higress.io/canary-by-header と higress.io/canary-by-header-value を同時に構成します。リクエスト ヘッダーの名前と値に基づいてトラフィックを分割します。リクエスト内のヘッダー名とヘッダー値が設定と一致する場合、リクエスト トラフィックはグレースケール サービスに割り当てられます。そうしないと、要求トラフィックはグレースケール サービスに割り当てられません。

たとえば、リクエスト ヘッダーが higress:always の場合、グレースケール サービス カナリアにアクセスされます。それ以外の場合は、公式サービスプロダクションにアクセスします。次に、次の Ingress オブジェクトを作成します。

 # canary-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/canary: "true" higress.io/canary-by-header: "higress" name: canary spec: ingressClassName: higress rules: - host: echo.k8s.local http: paths: - backend: service: name: canary port: number: 80 path: / pathType: Prefix

上記の YAML ファイルを適用するだけです:

 ☸ ➜ kubectl apply -f canary.yaml ☸ ➜ kubectl apply -f canary-ingress.yaml ☸ ➜ kubectl get pods -l app=canary NAME READY STATUS RESTARTS AGE canary-7d97679b67-sh2r8 1/1 Running 0 12m ☸ ➜ kubectl get ingress canary NAME CLASS HOSTS ADDRESS PORTS AGE canary higress echo.k8s.local 80 37s

上記の Ingress リソース オブジェクトを更新した後、リクエストに異なるヘッダー値を追加し、アプリケーションのドメイン名に再度アクセスして効果を確認します。

 ☸ ➜ for i in $(seq 1 10); do curl -s echo.k8s.local | grep "Hostname"; done Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb

ここでは、リクエスト時にヘッダーを構成しなかったため、リクエストは Canary アプリケーションに送信されませんでした。他の値に設定するとどうなるでしょうか?

 ☸ ➜ for i in $(seq 1 10); do curl -s -H "higress: always" echo.k8s.local | grep "Hostname"; done Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8

リクエストに設定したヘッダー値は higress: always なので、すべてのリクエストはカナリア サービスにルーティングされます。その他の値の場合、カナリア サービスにルーティングされません。

このとき、以前のアノテーション (canary-by-header) に基づいて、higress.io/canary-by-header-value: user-value などのルールを追加し、指定されたヘッダー値を持つリクエストを Canary Ingress で指定されたサービスにルーティングすることができます。

 annotations: higress.io/canary: "true" # 要开启灰度发布机制，首先需要启用Canary higress.io/canary-by-header: "higress" # 基于header的流量切分higress.io/canary-by-header-value: "user-value"

Ingress オブジェクトを更新した後、アプリケーションを再度確認してください。リクエスト ヘッダーが higress: user-value を満たす場合、すべてのリクエストは Canary バージョンにルーティングされます。

 ☸ ➜ for i in $(seq 1 10); do curl -s -H "higress: user-value" echo.k8s.local | grep "Hostname"; done Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8

クッキーに基づくグレースケールリリース

使用ルールは、リクエスト ヘッダー アノテーションに基づくルールと同様です。たとえば、A/B テストのシナリオでは、北京のユーザーが Canary バージョンにアクセスできるようにする必要があります。次に、Cookie アノテーションが higress.io/canary-by-cookie: "users_from_Beijing" に設定されると、バックエンドはログインしたユーザーのリクエストを確認できます。ユーザーのアクセス元が北京の場合、Cookie users_from_Beijing の値は always に設定され、北京のユーザーは Canary バージョンにのみアクセスできるようになります。

Cookie ベースのグレースケールリリースでは、キーに対応する値のカスタム設定はサポートされておらず、常に設定することしかできません。

たとえば、現在要求している Cookie が users_from_Beijing=always の場合、グレースケール バージョンのカナリア サービスにアクセスします。それ以外の場合は、公式サービスプロダクションにアクセスします。次に、次の Ingress オブジェクトを作成します。

 # canary-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/canary: "true" higress.io/canary-by-cookie: "users_from_Beijing" name: canary spec: ingressClassName: higress rules: - host: echo.k8s.local http: paths: - backend: service: name: canary port: number: 80 path: / pathType: Prefix

上記のIngress Resourceオブジェクトを更新した後、ユーザーのCookie値を常にリクエストに設定し、アプリケーションのドメイン名に再度アクセスします。

 ☸ ➜ for i in $(seq 1 10); do curl -s -b "users_from_Beijing=always" echo.k8s.local | grep "Hostname"; done Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8 Hostname: canary-7d97679b67-sh2r8

アプリケーションは、アプリケーションのカナリアバージョンにルーティングされていることがわかります。 Cookie値を別の値に設定した場合、カナリアアプリケーションにルーティングされません。

重量に基づくグレースケールリリース

重量ベースのトラフィック分割の典型的なアプリケーションシナリオは、青緑色の展開です。これは、重量を0または100に設定することで達成できます。たとえば、緑色のバージョンをメインパーツとして設定し、ポータルのブルーバージョンをカナリアとして構成できます。最初は、重量が0に設定されているため、青色のバージョンにはトラフィックがプロキシングされません。新しいバージョンが正常にテストおよび検証されると、ブルーバージョンの重量を100に設定できます。つまり、すべてのトラフィックはグリーンバージョンからブルーバージョンに転用されます。

Higressでは、次の注釈を使用して、重量ベースのグレースケールリリース戦略を構成できます。

• higress.io/canary-weight：リクエストの割合を特定のサービスに設定します（0〜100の整数値）
• higress.io/canary-weight-total：合計重量を設定します。デフォルトは100です

たとえば、カナリアサービスの重量を20％に設定し、生産サービスの重量を80％に設定すると、次のイングレスオブジェクトを作成できます。

 # canary-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: higress.io/canary: "true" higress.io/canary-weight: "20" # 分配20%流量到当前Canary版本name: canary spec: ingressClassName: higress rules: - host: echo.k8s.local http: paths: - backend: service: name: canary port: number: 80 path: / pathType: Prefix

上記のイングレスオブジェクトを更新します。次に、コマンドライン端末でこのアプリケーションに引き続きアクセスし、ホスト名の変更を観察します。

 ☸ ➜ for i in $(seq 1 10); do curl -s echo.k8s.local | grep "Hostname"; done Hostname: production-64cfc46b65-j6krb Hostname: canary-7d97679b67-sh2r8 Hostname: production-64cfc46b65-j6krb Hostname: canary-7d97679b67-sh2r8 Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb Hostname: production-64cfc46b65-j6krb

交通量の約20％をCanaryバージョンアプリケーションに割り当てたため、10回のうち3回（必ずしもそうではない）にアクセスしました。これは期待に沿ったものです。

この時点で、HigressのGrayscaleリリース機能を通じて交通セグメンテーションを達成しました。さまざまなシナリオに従って、さまざまなグレースケールリリース方法を選択できます。

プラグイン

Higressは、WASM、LUA、およびOffor Of Processの3つのプラグイン拡張メカニズムを提供します。カスタマイズされた関数拡張機能は、プラグインメカニズムを介して実装できます。複数の言語でプラグインの書き込みをサポートし、有効性の粒度はグローバルレベル、ドメインレベル、ルーティングレベルをサポートします。プラグインはホットアップデートをサポートし、プラグインロジックと構成の変更はトラフィックに影響しません。

ヒグレス用のプラグインを有効にするには、2つの方法があります。 1つはHigressコンソールを介して構成することであり、もう1つはHigress Wasmplugin CRDを介して構成することです。

Higressコンソール経由で構成

Higressコンソールは、プラグイン構成用の3つのポータルを提供します。

• グローバル構成：プラグインマーケット - >構成用のプラグインを選択します
• ドメインレベルの構成：ドメイン名管理 - >ドメイン名の選択 - > [ポリシー]をクリック - > [構成]の[プラグイン]を選択します
• ルーティングレベルの構成：ルーティング構成 - > [ルート]を選択 - > [ポリシー - > [[プラグ]]を[構成]を選択します

これら3つの構成の効果的な優先度は、次のとおりです。  ルーティングレベル>ドメイン名レベル>グローバル、つまり、グローバル構成は、特定のルートまたはドメイン名と一致しないリクエストに対してのみ有効になります。

カスタムプラグインを含む一般的なプラグインの場合、ルーティング/ドメインレベルの構成フィールドとグローバル構成フィールドはまったく同じです。認証プラグイン（キー認証、HMAC認証、基本認証、JWT認証など）の場合、グローバル構成は消費者資格設定の構成のみを実行し、グローバル認証が有効になるかどうかを実行し、ルーティング/ドメインレベルで構成されている消費者リストは許容フィールドを通じて構成されます。

たとえば、以前のfoo.bar.comサービスの基本的な認証プラグインを構成する場合は、まずグローバル構成で基本的なAuthプラグインを有効にしてから、ドメイン名レベル（またはルートレベル）で基本的なAuthプラグインを構成する必要があります。

コンソールのプラグインマーケットに切り替え、基本的な認証プラグインを見つけ、[構成]をクリックして、データエディターを通過します  consumers  フィールドは、次のようにユーザーの資格情報を構成します。

 global_auth: false consumers: # 配置两个用户凭证- name: consumer1 credential: admin:123456 - name: consumer2 credential: guest:abc

オン状態を選択し、[保存]をクリックしてください。

基本認証を構成します

次に、ドメイン名管理ページに切り替え、ドメイン名foo.bar.comを追加し、[ポリシー]をクリックして[基本的なAuthプラグインを選択して構成]を選択します。

次のように、データエディターのAllowフィールドからアクセスできるユーザーを構成します。

 allow: - consumer1

オン状態を選択し、[保存]をクリックしてください。ここでは、foo.bar.comサービスにアクセスするようにConsumer1ユーザーのみを構成し、他の発信者はアクセスを許可しません。

これで、foo.bar.comサービスにアクセスして確認できます。

 $ curl -v foo.bar.com/foo * Trying 192.168.0.116:80... * Connected to foo.bar.com (192.168.0.116) port 80 (#0) > GET /foo HTTP/1.1 > Host: foo.bar.com > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized < www-authenticate: Basic realm=MSE Gateway < date: Sat, 20 Apr 2024 06:05:15 GMT < server: istio-envoy < content-length: 0 < * Connection #0 to host foo.bar.com left intact

ユーザーの資格情報を提供していないため、401が許可されていないことがわかります。次に、アクセス用のユーザー資格情報を提供します。

 $ curl -v -u admin:123456 foo.bar.com/foo * Trying 192.168.0.116:80... * Connected to foo.bar.com (192.168.0.116) port 80 (#0) * Server auth using Basic with user 'admin' > GET /foo HTTP/1.1 > Host: foo.bar.com > Authorization: Basic YWRtaW46MTIzNDU2 > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < x-app-name: http-echo < x-app-version: 0.2.4 < date: Sat, 20 Apr 2024 06:06:10 GMT < content-length: 4 < content-type: text/plain; charset=utf-8 < req-cost-time: 1 < req-arrive-time: 1713593170671 < resp-start-time: 1713593170673 < x-envoy-upstream-service-time: 1 < server: istio-envoy < foo * Connection #0 to host foo.bar.com left intact

ユーザーの資格情報を提供した後、サービスに正常にアクセスしたことがわかります。私たちが提供するユーザーの資格情報がアクセスを許可されているユーザーのリストにない場合、403の禁止エラーが返されます。

 $ curl -v -u guest:abc foo.bar.com/foo * Trying 192.168.0.116:80... * Connected to foo.bar.com (192.168.0.116) port 80 (#0) * Server auth using Basic with user 'guest' > GET /foo HTTP/1.1 > Host: foo.bar.com > Authorization: Basic Z3Vlc3Q6YWJj > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 403 Forbidden < www-authenticate: Basic realm=MSE Gateway < date: Sat, 20 Apr 2024 06:06:54 GMT < server: istio-envoy < content-length: 0 < * Connection #0 to host foo.bar.com left intact

Higress wasmplugin経由で構成

コンソールを介してプラグインを構成することに加えて、いくつかの新しい構成フィールドを追加して、ISTIO Wasmplugin CRDの拡張であるHigress Wasmplugin CRDを介して構成することもできます。

MatchRulesの各アイテムの構成フィールドの説明：

同様に、Basic Authプラグインを構成してWasmpluginを実装する場合は、まず以下に示すようにWasmplugin CRDオブジェクトを作成する必要があります。

 # basic-auth-plugin.yaml apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: basic-auth namespace: higress-system spec: url: oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/basic-auth:1.0.0 # 插件镜像地址defaultConfig: consumers: - name: consumer1 credential: admin:123456 - name: consumer2 credential: guest:abc matchRules: - domain: - foo.bar.com config: allow: - consumer2

基本的なAuthプラグインを有効にせずに、コンソールを介して構成された上記の基本的なAuthプラグイン構成をリセットします。

上記のwasmpluginオブジェクトでは、defaultconfigフィールドを介してユーザー資格情報を構成します。この部分は実際にコンソールのグローバル構成に対応し、その後、MatchRulesフィールドを介してドメイン名レベルの構成を構成します。この部分は、コンソールのドメイン名レベルの構成に対応します。もちろん、ドメインに加えて、コンソールのルーティングレベルの構成に対応するイングレスフィールドを構成することもできます。たとえば、上記の構成は、consumer2ユーザーのみがfoo.bar.comサービスにアクセスできることを意味します。

上記のwasmpluginオブジェクトを直接作成します。

 ☸ ➜ kubectl apply -f basic-auth-plugin.yaml

次に、foo.bar.comサービスにもう一度アクセスして、次を確認してください。

 ☸ ➜ curl -v foo.bar.com/foo * Trying 192.168.0.116:80... * Connected to foo.bar.com (192.168.0.116) port 80 (#0) > GET /foo HTTP/1.1 > Host: foo.bar.com > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 401 Unauthorized < www-authenticate: Basic realm=MSE Gateway < date: Sat, 20 Apr 2024 06:23:48 GMT < server: istio-envoy < content-length: 0 < * Connection #0 to host foo.bar.com left intact

ユーザーの資格情報を提供していないため、401が許可されていないことがわかります。次に、アクセス用のユーザー資格情報を提供します。

 ☸ ➜ curl -v -u guest:abc foo.bar.com/foo * Trying 192.168.0.116:80... * Connected to foo.bar.com (192.168.0.116) port 80 (#0) * Server auth using Basic with user 'guest' > GET /foo HTTP/1.1 > Host: foo.bar.com > Authorization: Basic Z3Vlc3Q6YWJj > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < x-app-name: http-echo < x-app-version: 0.2.4 < date: Sat, 20 Apr 2024 06:24:49 GMT < content-length: 4 < content-type: text/plain; charset=utf-8 < req-cost-time: 1 < req-arrive-time: 1713594289845 < resp-start-time: 1713594289847 < x-envoy-upstream-service-time: 0 < server: istio-envoy < foo * Connection #0 to host foo.bar.com left intact

上記のWasmpluginで構成されているため、Consumer2ユーザーのみがFoo.bar.comサービスにアクセスできるようにするため、Consumer2ユーザーの資格情報を提供するリクエストのみがサービスにアクセスできます。したがって、ゲスト：ここで提供するABCユーザー資格情報は、サービスに正常にアクセスしました。提供されたユーザーの資格情報がアクセスを許可されているユーザーのリストにない場合、403の禁止エラーが返されます。

 ☸ ➜ curl -v -u admin:123456 foo.bar.com/foo * Trying 192.168.0.116:80... * Connected to foo.bar.com (192.168.0.116) port 80 (#0) * Server auth using Basic with user 'admin' > GET /foo HTTP/1.1 > Host: foo.bar.com > Authorization: Basic YWRtaW46MTIzNDU2 > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 403 Forbidden < www-authenticate: Basic realm=MSE Gateway < date: Sat, 20 Apr 2024 06:26:00 GMT < server: istio-envoy < content-length: 0 < * Connection #0 to host foo.bar.com left intact

ここでは、Higress Wasmplugin CRDオブジェクトを介して基本的なAuthプラグイン構成を実装し、ユーザー資格認証機能を実装します。 Basic Authプラグインに加えて、Higressは、キーAuthプラグイン、HMAC Authプラグイン、JWT Authプラグインなど、他の多くのプラグインも提供します。実際のニーズに応じて、構成用に異なるプラグインを選択できます。各プラグインの構成プロパティは、コンソールのプラグイン市場の構成命令を参照できます。

カスタムプラグイン

Higressが提供するビルトインプラグインに加えて、特別なニーズがある場合があります。この時点で、カスタムプラグインを使用して、カスタマイズされた関数拡張機能を実現できます。さまざまなプログラミング言語を使用してプラグインを作成できます。これは、グローバルレベル、ドメイン名レベル、ルーティングレベルをサポートする効果的な粒度を備えています。さらに、プラグインはホットの更新もサポートしており、プラグインロジックと構成の変更はトラフィックに紛失します。簡単な例を使用して、カスタムプラグインの書き方を説明しましょう。

まず、GolangおよびTinygoプログラムをインストールする必要があります。 Golangにはバージョン1.18以上が必要です。公式ガイダンスリンクは次のとおりです。https：//go.dev/doc/install; Tinygoにはバージョン0.28.1以上が必要です。公式ガイダンスリンクはhttps://tinygo.org/getting-started/install/です。

 ☸ ➜ go version go version go1.20.14 darwin/arm64 ☸ ➜ tinygo version tinygo version 0.30.0 darwin/amd64 (using go version go1.20.14 and LLVM version 16.0.1)

次に、プロジェクトディレクトリを初期化し、新しい名前の新しいものを作成します  wasm-demo-go  ディレクトリ、Build Directoryで次のコマンドを実行して、GOプロジェクトを初期化します

go mod init wasm-demo-go

国内環境は、依存関係パッケージをダウンロードするためのプロキシを設定する必要があります

go env -w GOPROXY=https://proxy.golang.com.cn,direct

次に、ビルドプラグインの依存関係をダウンロードします。

 go get github.com/higress-group/proxy-wasm-go-sdk go get github.com/alibaba/higress/plugins/wasm-go@main go get github.com/tidwall/gjson

次に、簡単な機能を実装するための簡単なプラグインを記述しましょう。 mockenableがある場合：プラグイン構成でtrueは、Hello World Responseを直接返します。プラグイン構成がない場合、またはmockenable：falseが設定されている場合、Hello：World Request Header Headerを元のリクエストに追加します。

 package main import ( "github.com/alibaba/higress/plugins/wasm-go/pkg/wrapper" "github.com/higress-group/proxy-wasm-go-sdk/proxywasm" "github.com/higress-group/proxy-wasm-go-sdk/proxywasm/types" "github.com/tidwall/gjson" ) func main() { wrapper.SetCtx( // 插件名称"my-plugin", // 为解析插件配置，设置自定义函数wrapper.ParseConfigBy(parseConfig), // 为处理请求头，设置自定义函数wrapper.ProcessRequestHeadersBy(onHttpRequestHeaders), ) } // 自定义插件配置type MyConfig struct { mockEnable bool } // 在控制台插件配置中填写的yaml配置会自动转换为json，此处直接从json这个参数里解析配置即可func parseConfig(json gjson.Result, config *MyConfig, log wrapper.Log) error { // 解析出配置，更新到config中config.mockEnable = json.Get("mockEnable").Bool() return nil } func onHttpRequestHeaders(ctx wrapper.HttpContext, config MyConfig, log wrapper.Log) types.Action { proxywasm.AddHttpRequestHeader("hello", "world") if config.mockEnable { proxywasm.SendHttpResponse(200, nil, []byte("hello world"), -1) } return types.ActionContinue }

ゲートウェイコンソールのプラグインはYAML形式で構成されており、プラグインに発行されるとJSON形式に自動的に変換されるため、例のParseConfigはJSONから直接解析できます。

上記のコードでは、onhttprequestheadersbyのカスタム関数を使用して、HTTPリクエストヘッダー処理段階でリクエストを処理します。さらに、次の方法を使用して、他の段階のカスタム処理関数を設定することもできます。

proxywasm.addhttprequestheaderおよびproxywasm.sendhtttpresponse上記の例コードは、プラグインSDKによって提供される2つのツールメソッドです。主なツール方法を次の表に示します。

次に、WASMファイルをコンパイルして生成する必要があります。

 go mod tidy tinygo build -o main.wasm -scheduler=none -target=wasi -gc=custom -tags="custommalloc nottinygc_finalizer" ./main.go

コンピレーションは成功し、ファイルMain.WASMが現在のディレクトリで生成されます。 Wasmplugin CRDまたはコンソールのUIインタラクションでHigressのプラグインを構成するには、WASMファイルをOCIまたはDocker画像にパッケージ化する必要があります。

次のコンテンツを使用して、Project Root Directoryの下にDockerFileファイルを作成します。

 FROM scratch COPY main.wasm plugin.wasm

次に、次のコマンドを実行して画像を構築およびプッシュします。

 docker build -t cnych/higress-plugin-demo:1.0.0 . docker push cnych/higress-plugin-demo:1.0.0

このようにして、カスタムプラグインをDocker画像にパッケージ化します。次に、ゲートウェイコンソールのプラグイン市場でカスタムプラグインを作成し、上記のWASM画像アドレスに入力します。

プラグインを追加します

作成が完了したら、プラグインカードの構成ボタンをクリックし、プラグインの構成mockenable：trueを入力し、スイッチをオンにして有効にします。プラグインロジックが変更された場合、新しい画像を作成して別の画像タグを使用できます。プラグインカードの右上にあるメニューの[編集]ボタンをクリックし、WASMイメージアドレスを新しいバージョンのアドレスに変更します。

ただし、すべてのリクエストがオンになった後に有効になることに注意する必要があるため、生産環境では注意して使用する必要があります。ドメイン名またはルートレベルの構成プラグインを使用して、プラグインの有効性範囲を制御できます。

コンソールを介してプラグインを構成することに加えて、Higress Wasmplugin CRDオブジェクトを介してプラグインを構成することもできます。これにより、プラグインの効果的な範囲をより柔軟に制御できます。

 # wasm-plugin-demo.yaml apiVersion: extensions.higress.io/v1alpha1 kind: WasmPlugin metadata: name: plugin-demo namespace: higress-system spec: url: oci://docker.io/cnych/higress-plugin-demo:1.0.0 defaultConfig: mockEnable: false matchRules: - domain: - foo.bar.com config: mockEnable: true

上記のwasmpluginオブジェクトを直接適用します。

 ☸ ➜ kubectl apply -f wasm-plugin-demo.yaml

次に、foo.bar.comサービスに再度アクセスして、次のことを確認します。

 ☸ ➜ curl foo.bar.com/foo hello world

プラグイン構成がmockenableを提供することがわかります。プラグイン構成をmockenable：falseに設定すると、Hello：World Request Header Headerを元のリクエストに追加します。

このようにして、Higress Wasmplugin CRDオブジェクトを介してカスタムプラグインを構成して、カスタマイズされた関数拡張機能を実現しました。

プラグインの有効性メカニズムの簡単な説明を次に示します。

• ユーザーはコードをWASMファイルにコンパイルします
• ユーザーはWASMファイルをDocker画像にビルドします
• ユーザーはDocker画像を画像リポジトリにプッシュします
• ユーザーはwasmpluginリソースを作成します
• Istio WatchからWasmpluginリソースへの変更
• Higress GatewayのXDSプロキシプロセスは、ISTIOから構成を取得し、プラグインのミラーアドレスを発見します
• XDSプロキシは、ミラーリポジトリから画像を引き出します
• XDSプロキシは、ミラーからWASMファイルを抽出します
• Higress GatewayのEnvoy Processは、XDSプロキシから構成を取得し、WASMファイルのローカルパスを発見します。
• Envoyは、ローカルファイルからWASMファイルをロードします

プラグインが有効になります

ここで、Envoyは構成を取得し、ECDS（拡張機能構成サービス）メカニズムを使用してWASMファイルをロードし、WASMファイルの更新を実装します。これは直接ホットロードであり、接続の中断を引き起こさず、サービストラフィックは完全にロスレスされます。

この記事で導入されたHigress関数に加えて、他の多くの機能やベストプラクティスソリューションがあります。詳細については、公式のHigressドキュメントを参照してください。

参照ドキュメント：https：//higress.io