トラフィックルールの構成に基づくトラフィックレーンとトラフィックの縮退の実装方法 - Alibaba Cloud Service Mesh

複数のマイクロサービスを同時にリリースする場合、本番トラフィックに影響を与えることなく、各サービスバージョンを完全な呼び出しチェーンとしてテストする必要があります。トラフィックレーンは、バージョン管理されたサービスの呼び出しチェーンを独立した実行環境に隔離するため、レーンに入ったリクエストはエンドツーエンドでそのバージョン内に留まります。レーン内のバージョンが利用できなくなった場合、トラフィックシフトによってリクエストが指定されたフォールバックバージョンにリダイレクトされ、サービスの中断を防ぎます。

ここでは、Service Mesh (ASM) で完全なセットアップを行うための以下の手順について説明します。DestinationRule によるバージョンサブセットの定義、VirtualService によるサービス間トラフィックのバージョンごとのルーティング、HTTP ヘッダーによる特定レーンへのイングレストラフィックの誘導、およびレーンのターゲットが利用できない場合のフォールバックの設定です。

トラフィックレーンの仕組み

トラフィックレーンは、3 つの Istio トラフィック管理プリミティブから構築されます。

プリミティブ	トラフィックレーンにおける役割
DestinationRule	Pod ラベルに基づいて、各サービスのバージョンサブセット (v1、v2、v3) を宣言します。どのバージョンが存在するかを定義します。
VirtualService	`sourceLabels` に基づいてサービス間トラフィックをルーティングし、リクエストを同じバージョンレーン内に維持します。トラフィックの送信先を定義します。
Gateway + VirtualService	HTTP ヘッダー (`x-asm-prefer-tag`) に基づいて、イングレストラフィックを正しいレーンにルーティングします。レーンへのエントリーポイントとして機能します。

次の図は、それぞれが完全な v1、v2、または v3 の呼び出しチェーンを含む 3 つのレーンを示しています。

                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v1: mocka v1 → mockb v1 → mockc v1  │
  v1                └─────────────────────────────────────┘
                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v2: mocka v2 → mockb v2 → mockc v2  │
  v2                └─────────────────────────────────────┘
                    ┌─────────────────────────────────────┐
  x-asm-prefer-tag: │  Lane v3: mocka v3 → mockb v3 → mockc v3  │
  v3                └─────────────────────────────────────┘

トラフィックシフトはフォールバックメカニズムを追加します。レーン内のサービスバージョンが利用できない場合、ASM はトラフィックを指定されたフォールバックバージョン (通常は v1) にリダイレクトします。

前提条件

開始する前に、以下の準備が整っていることを確認してください。

バージョン 1.17 以降の Service Mesh (ASM) インスタンス (Enterprise Edition または Ultimate Edition)。詳細については、「ASM インスタンスの作成」または「ASM インスタンスの更新」をご参照ください。
ASM インスタンスに追加された Kubernetes クラスター。詳細については、「ASM インスタンスへのクラスターの追加」をご参照ください。
ingressgateway という名前の ASM ゲートウェイ。詳細については、「イングレスゲートウェイの作成」をご参照ください。

ステップ 1：サンプルサービスのデプロイ

このチュートリアルでは、3 つのサンプルサービス (mocka、mockb、mockc) を使用します。それぞれが 3 つのバージョン (v1、v2、v3) でデプロイされます。呼び出しチェーンは mocka から mockb、そして mockc へと流れます。

default 名前空間でサイドカープロキシの自動注入を有効にします。詳細については、「グローバル名前空間の管理」トピックの「サイドカーの自動インジェクションを有効にする」セクション、または「サイドカープロキシの自動注入の有効化」をご参照ください。

データプレーン上のクラスターの kubeconfig ファイルを使用して、サンプルサービスをデプロイします。

   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
   kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml

ステップ 2：DestinationRule によるバージョンサブセットの定義

DestinationRule は、各サービスで利用可能なバージョンサブセットを宣言します。各サブセットは、一致する version ラベルを持つ Pod にマッピングされます。

次の内容で dr-mock.yaml という名前のファイルを作成します。主要なフィールド：

フィールド	説明
`namespace: istio-system`	アプリケーションの名前空間ではなく、ASM コントロールプレーンの名前空間に適用されます。
`host`	完全修飾サービス名 (例：`mocka.default.svc.cluster.local`)。
`subsets[].labels.version`	ステップ 1 でデプロイされた Pod の `version` ラベルと一致します。

dr-mock.yaml の表示

   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mocka
     namespace: istio-system
   spec:
     host: mocka.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     host: mockb.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     host: mockc.default.svc.cluster.local
     subsets:
       - labels:
           version: v1
         name: v1
       - labels:
           version: v2
         name: v2
       - labels:
           version: v3
         name: v3

ASM インスタンスの kubeconfig ファイルを使用して DestinationRule を適用します。
```
   kubectl apply -f dr-mock.yaml
```

ステップ 3：VirtualService によるレーン内トラフィックのルーティング

VirtualService は sourceLabels に基づいてサービス間トラフィックをルーティングし、リクエストを同じバージョンレーン内に維持します。mocka v2 が mockb を呼び出すと、VirtualService はソースラベル version: v2 に一致し、リクエストを mockb v2 にルーティングします。

次の内容で vs-mock.yaml という名前のファイルを作成します。主要なフィールド：ルーティングルールは上から下に評価されます。最初に一致したものが適用されます。

フィールド	説明
`sourceLabels`	呼び出し元 Pod の `version` ラベルと一致します。v2 の呼び出し元は v2 の送信先にのみ到達し、トラフィックはレーン内に留まります。
`subset`	DestinationRule (ステップ 2) で定義されたサブセット名を参照します。

vs-mock.yaml の表示

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     hosts:
       - mockb.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v2
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v3
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     hosts:
       - mockc.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v2
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v3

ASM インスタンスの kubeconfig ファイルを使用して VirtualService を適用します。
```
   kubectl apply -f vs-mock.yaml
```

ステップ 4：HTTP ヘッダーによるイングレストラフィックのレーンへのルーティング

Gateway とゲートウェイレベルの VirtualService は、x-asm-prefer-tag HTTP ヘッダーに基づいて、受信リクエストを正しいレーンに誘導します。カナリアテスト中、QA エンジニアまたは CI/CD パイプラインはテストリクエストに x-asm-prefer-tag: v2 を追加し、それらを v2 レーンにルーティングする一方、本番トラフィックは v1 に流れ続けます。

次の内容で gw-mock.yaml という名前のファイルを作成します。主要なフィールド：

フィールド	説明
`selector: istio: ingressgateway`	Gateway を ASM イングレスゲートウェイの Pod にバインドします。
`x-asm-prefer-tag`	どのレーンがリクエストを受信するかを決定します。値はバージョン (v1、v2、または v3) と完全に一致する必要があります。
`uri: exact: /mock`	ルートを適用するには、ヘッダーと URI の両方が一致する必要があります。

gw-mock.yaml の表示

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 80
           name: http
           protocol: HTTP
         hosts:
           - '*'
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     gateways:
       - istio-system/ingressgateway
     hosts:
       - '*'
     http:
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v1
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v1
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v2
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v2
       - match:
           - headers:
               x-asm-prefer-tag:
                 exact: v3
             uri:
               exact: /mock
         route:
           - destination:
               host: mocka.default.svc.cluster.local
               subset: v3

ASM インスタンスの kubeconfig ファイルを使用して Gateway とルーティングルールを適用します。
```
   kubectl apply -f gw-mock.yaml
```

ステップ 5：トラフィックレーンの検証

ASM ゲートウェイのパブリック IP アドレスを取得します。詳細については、「KServe と ASM の統合」のステップ 2 をご参照ください。
ゲートウェイの IP を環境変数として設定します。xxx.xxx.xxx.xxx を実際の IP アドレスに置き換えます。
```
   export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```

各レーンにテストリクエストを送信し、トラフィックが正しいバージョン内に留まることを確認します。v1 レーンのテスト：期待される出力：3 つのサービスすべてがバージョン v1 で応答し、トラフィックが v1 レーン内に留まることを確認します。v2 レーンのテスト：期待される出力：v3 レーンのテスト：期待される出力：各レーンは、一致するバージョンのサービスにのみトラフィックをルーティングし、レーンの隔離が正しく機能していることを確認します。

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)

   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

   -> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)

ステップ 6：フォールバックによるトラフィックシフトの追加

トラフィックシフトは、トラフィックレーンに回復力を追加します。fallback 構成を使用すると、ターゲットバージョンが利用できない場合に ASM はトラフィックを安定したバージョン (v1) にリダイレクトし、カナリアリリース中のサービス中断を防ぎます。

vs-mock.yaml の内容を次の構成に置き換えます。これにより、v2 および v3 ルートに fallback ブロックが追加され、ターゲットバージョンが到達不能な場合にトラフィックが v1 サブセットに誘導されます。主要なフィールド：

フィールド	説明
`fallback.target.host` および `fallback.target.subset`	フォールバック先の送信先。ここでは、`mockb` と `mockc` の両方が v1 にフォールバックします。
v1 ルート (フォールバックなし)	v1 は安定したベースラインとして機能するため、フォールバックターゲットは必要ありません。
ルートごとのフォールバック	各バージョンのフォールバックターゲットは独立して構成されます。

更新された vs-mock.yaml の表示

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockb
     namespace: istio-system
   spec:
     hosts:
       - mockb.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v2
         fallback:
           target:
             host: mockb.default.svc.cluster.local
             subset: v1
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockb.default.svc.cluster.local
           subset: v3
         fallback:
           target:
             host: mockb.default.svc.cluster.local
             subset: v1
   ---
   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: mockc
     namespace: istio-system
   spec:
     hosts:
       - mockc.default.svc.cluster.local
     http:
     - match:
       - sourceLabels:
           version: v1
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v1
     - match:
       - sourceLabels:
           version: v2
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v2
         fallback:
           target:
             host: mockc.default.svc.cluster.local
             subset: v1
     - match:
       - sourceLabels:
           version: v3
       route:
       - destination:
           host: mockc.default.svc.cluster.local
           subset: v3
         fallback:
           target:
             host: mockc.default.svc.cluster.local
             subset: v1

ASM インスタンスの kubeconfig ファイルを使用して、更新された VirtualService を適用します。
```
   kubectl apply -f vs-mock.yaml
```

ステップ 7：トラフィックシフトの検証

サービスの障害をシミュレートして、フォールバックルーティングが機能することを確認します。

ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、対象のクラスター名をクリックし、左側のナビゲーションウィンドウで [ワークロード] > [デプロイメント] を選択します。
[デプロイメント] ページで、mockb-v2 ワークロードを見つけ、[アクション] 列の [スケール] をクリックします。[スケール] ダイアログボックスで、[Pod の必要数] を 1 に設定し、[OK] をクリックします。[確認] をクリックして適用します。これにより、mockb v2 サービスの障害をシミュレートします。
v2 レーンにテストリクエストを送信します。期待される出力：リクエストは mocka v2 を通じて入ります (x-asm-prefer-tag: v2 ヘッダーに一致)。mockb v2 が利用できないため、トラフィックは mockb v1 にシフトし、そこから v1 レーンを通じて mockc v1 にルーティングされます。トラフィックシフトは期待どおりに機能します。
```
   for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
```
   -> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.126)-> mockc(version: v1, ip: 172.17.0.128)
```

リソースのクリーンアップ

このチュートリアルで作成したすべてのリソースを削除するには、次を実行します。

# トラフィックルールを削除 (ASM kubeconfig を使用)
kubectl delete -f gw-mock.yaml
kubectl delete -f vs-mock.yaml
kubectl delete -f dr-mock.yaml

# サンプルサービスを削除 (クラスターの kubeconfig を使用)
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
kubectl delete -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml