パーミッシブモードのトラフィックレーンと伝播ヘッダーの使用 - Alibaba Cloud Service Mesh

パーミッシブモード の トラフィックレーン を使用して、アプリケーションの バージョン分離 を実現できます。E2E パススルーリクエストヘッダー を リクエストルーティングヘッダー として指定することで、ヘッダーの値を使用してトラフィックを スイムレーン にルーティングできます。スイムレーン 内のサービスが相互に呼び出しを行う際、現在の スイムレーン に宛先サービスが存在しない場合、リクエストは ベースラインレーン に転送されます。これにより、呼び出しチェーン の整合性が確保され、トラフィック管理が簡素化されます。

重要

開始する前に、「パーミッシブモードのトラフィックレーンを使用したエンドツーエンドのトラフィック管理」とその関連コンテンツを読み、理解していることを確認してください。

シナリオの概要

この例では、mocka、mockb、mockc の 3 つのサービスを使用して、サービス 呼び出しチェーン の 3 つのバージョンを表す 3 つの スイムレーン (s1、s2、s3) を作成します。s1 スイムレーン は ベースラインレーン であり、3 つすべてのサービスが含まれます。s2 スイムレーン には mocka と mockc サービスのみが含まれます。s3 スイムレーン には mockb サービスのみが含まれます。このシナリオでは、E2E パススルーリクエストヘッダー と リクエストルーティングヘッダー の両方が my-trace-id に設定されます。

ステップ 1：スイムレーングループとスイムレーンの作成

スイムレーングループを作成します。

ASM コンソールにログインします。左側のナビゲーションウィンドウで、[サービスメッシュ] > [メッシュ管理] を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、[トラフィック管理センター] > [トラフィックレーン] を選択します。

Traffic Lane ページで、Create Swimlane Group をクリックします。Create Swimlane Group パネルで、パラメーターを設定し、OK をクリックします。

パラメーター	説明
[Name of swim lane group]	この例では、名前を test に設定します。
[Entrance gateway]	ingressgateway を選択します。
[Lane Mode]	[Permissive Mode]を選択します。
[Pass-through Mode of Trace Context]	[Pass Through Custom Header]を選択します。
[E2E Pass-through Request Header]	これを `my-trace-id` に設定します。
[Swimlane service]	対象の Kubernetes クラスターと default `namespace` を選択します。サービスリストで mocka、mockb、mockc を選択します。アイコンをクリックして、[selected] エリアに移動します。

s1、s2、s3 スイムレーン を作成し、それぞれ v1、v2、v3 バージョンにバインドします。

Traffic Rule Definition ページの Traffic Lane セクションで、Create swimlanes をクリックします。

Create swimlanes ダイアログボックスで、パラメーターを設定し、OK をクリックします。

パラメーター	説明
[Swimlane Name]	3 つの `スイムレーン` の名前を、それぞれ s1、s2、s3 に設定します。
[Configure Service Tag]	[Label Key]： ASM_TRAFFIC_TAG に設定します。 [Label Value]： `s1`、`s2`、`s3` `スイムレーン` に対して、それぞれ v1、v2、v3 に設定します。
[Add Service]	`s1` `スイムレーン` の場合： mocka(default)、mockb(default)、mockc(default) を選択します。 `s2` `スイムレーン` の場合： mocka(default) と mockc(default) を選択します。 `s3` `スイムレーン` の場合： mockb(default) を選択します。

3 つの スイムレーン が作成されると、結果が表示されます。デフォルトでは、グループ内で最初に作成した スイムレーン が ベースラインレーン になります。ベースラインレーン は変更できます。他の スイムレーン に存在しないサービスにトラフィックが送信されると、フォールバックメカニズム によってリクエストが ベースラインレーン に転送されます。ベースラインレーンの変更方法の詳細については、「ベースラインレーンの変更」をご参照ください。[トラフィックルール定義] ページで、ベースラインレーンは s1 に設定され、Ingress タイプは ASM ゲートウェイ (ingressgateway) に設定されます。

3 つの スイムレーン を作成すると、Alibaba Cloud Service Mesh は スイムレーン グループ内の各サービスに対して DestinationRule と VirtualService を自動的に生成します。これらを表示するには、左側メニューでTraffic Management Center > DestinationRule または [Virtual Service] を選択します。たとえば、ASM は mocka サービスに対して次の DestinationRule と VirtualService を自動的に作成します。

DestinationRule YAML のサンプル

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2

VirtualService YAML のサンプル

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-vs-test-default-mocka
  namespace: istio-system
spec:
  hosts:
    - mocka.default.svc.cluster.local
  http:
    - match:
        - headers:
            my-trace-id:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

3 つの スイムレーン の トラフィックルーティングルール を作成します。

Traffic Rule Definition ページの Traffic Lane セクションで、対象の スイムレーン を見つけ、Actions 列の Ingress traffic rules をクリックします。

Add drainage rule ダイアログボックスで、パラメーターを設定し、OK をクリックします。

この例では、すべての スイムレーン サービスの Ingress API が /mock であると仮定します。したがって、各 スイムレーン に同じ トラフィックルーティングルール を設定します。

パラメーター	説明
[Ingress service]	mocka.default.svc.cluster.local を選択します。
[Ingress traffic rules]	3 つの `スイムレーン` の `トラフィックルーティングルール` について、[Name]をそれぞれ r1、r2、r3 に設定します。[realm name]を * に設定します。
[Matching request URI]	[Method]を [Exact] に、[Content]を /mock に設定します。

3 つの スイムレーン の トラフィックルーティングルール を作成すると、結果が表示されます。URI の完全一致に加えて、各ルールには ヘッダーの一致条件が含まれます。ヘッダー名は my-trace-id、一致タイプは完全一致で、s1、s2、s3 スイムレーン の一致値はそれぞれ s1、s2、s3 です。ベースラインレーンは s1 に設定されます。

ルールを作成すると、ASM は各 スイムレーン の トラフィックルーティングルール を定義する VirtualService を自動的に生成します。たとえば、ASM は s2 スイムレーン に対して次の VirtualService を生成します。

VirtualService YAML のサンプル

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            my-trace-id:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

ステップ 2：E2E カナリアリリースの検証

ASM ingress gateway のパブリック IP アドレスを取得します。詳細については、「Ingress Gateway の IP アドレスの取得」をご参照ください。
次のコマンドを実行して、環境変数を設定します。

コマンドの xxx.xxx.xxx.xxx は、前の手順で取得した IP アドレスです。
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
E2E カナリアリリース を検証します。
1. 次のコマンドを実行して、s1 スイムレーン へのアクセスをテストします。
  
  my-trace-id の値 s1 は、ステップ 1.2 で設定した s1 スイムレーン の名前です。
```
for i in {1..100};  do curl -H'my-trace-id: s1' 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)
```
  この出力は、HTTP ヘッダー my-trace-id: s1 を持つリクエストが s1 スイムレーン 内のサービスにルーティングされることを示します。
2. 次のコマンドを実行して、s2 スイムレーン へのアクセスをテストします。
  
  my-trace-id の値 s2 は、ステップ 1.2 で設定した s2 スイムレーン の名前です。
```
for i in {1..100};  do curl -H'my-trace-id: s2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  期待される出力：
```
mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)
```
  この出力は、HTTP ヘッダー my-trace-id: s2 を持つリクエストが s2 スイムレーン 内のサービスにルーティングされることを示します。リクエストが s2 スイムレーン に存在しない mockb サービスをターゲットとする場合、フォールバックメカニズム によってリクエストが s1 ベースラインレーン 内の mockb サービスに転送されます。その後の mockc サービスへのリクエストは、正しく s2 スイムレーン 内の mockc サービスにルーティングされます。
3. 次のコマンドを実行して、s3 スイムレーン へのアクセスをテストします。
  
  my-trace-id の値 s3 は、ステップ 1.2 で設定した s3 スイムレーン の名前です。
```
for i in {1..100};  do curl -H'my-trace-id: s3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  期待される出力：
```
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
```
  この出力は、HTTP ヘッダー my-trace-id: s3 を持つリクエストが s3 スイムレーン 内のサービスにルーティングされることを示します。リクエストが s3 スイムレーン に存在しない mocka および mockc サービスをターゲットとする場合、フォールバックメカニズム によってリクエストが s1 ベースラインレーン 内の mocka および mockc サービスに転送されます。