すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Service Mesh:厳格モードのトラフィックレーンを使用してエンドツーエンドのトラフィックを管理する

    ドキュメントセンター

    Alibaba Cloud Service Mesh:厳格モードのトラフィックレーンを使用してエンドツーエンドのトラフィックを管理する

    最終更新日:Jan 13, 2025

    厳格モードのトラフィックレーンを使用すると、アプリケーションの特定のバージョンまたは特定の機能を個別のランタイム環境に分離できます。 このアプローチは、呼び出しチェーン内のすべてのサービスに対してカナリアリリースを実行する場合、またはアプリケーションバージョンを分離する場合に役立ちます。 指定されたルールに一致するトラフィックのみを新しいサービスバージョンにルーティングすることにより、このアプローチはリリースの信頼性と制御性を確保します。

    前提条件

    • Enterprise EditionまたはUltimate EditionのService Mesh（ASM）インスタンスが作成されており、インスタンスのバージョンが 1.18.2.111 以降であること。 詳細については、「ASMインスタンスの作成」または「ASMインスタンスのアップグレード」をご参照ください。

      説明

      ASMインスタンスのバージョンが 1.17.2.22 以降で 1.18.2.111 より前の場合は、トラフィック管理の詳細について「レーンを使用したトラフィックの管理」をご参照ください。

    • クラスターがASMインスタンスに追加されていること。 詳細については、「ASMインスタンスへのクラスターの追加」をご参照ください。

    • ingressgatewayという名前のASMイングレスゲートウェイが作成されていること。 詳細については、「イングレスゲートウェイの作成」をご参照ください。

    • istio-systemネームスペースにingressgatewayという名前のIstioゲートウェイが作成されていること。 詳細については、「Istioゲートウェイの管理」をご参照ください。

      Istioゲートウェイのサンプル 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:
        - '*'

    例

    この例では、3つのレーン（s1、s2、s3）が作成され、mocka、mockb、mockcサービスの3つのバージョンを表しています。image.png

    手順 1：サンプルサービスをデプロイする

    1. defaultネームスペースに対してサイドカープロキシの自動注入を有効にします。 手順の詳細については、「グローバルネームスペースの管理」トピックの「サイドカープロキシの自動注入を有効にする」をご参照ください。

      サイドカープロキシの自動注入の詳細については、「サイドカープロキシ注入ポリシーの設定」をご参照ください。

    2. 次のコマンドを実行して、Container Service for Kubernetes（ACK）クラスターにサンプルサービスをデプロイします。

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

    手順 2：レーングループとレーンを作成する

    1. レーングループを作成します。

      1. ASMコンソールにログインします。 左側のナビゲーションペインで、[サービスメッシュ] > [メッシュ管理] を選択します。

      2. [メッシュ管理] ページで、ASMインスタンスの名前をクリックします。 左側のナビゲーションペインで、[トラフィック管理センター] > [トラフィックレーン] を選択します。

      3. [トラフィックレーン] ページで、[スイムレーングループの作成] をクリックします。 [スイムレーングループの作成] パネルで、パラメーターを設定し、[OK] をクリックします。

        パラメーター

        説明

        スイムレーングループの名前

        この例では、test と入力します。

        イングレスゲートウェイのistioゲートウェイ

        [ingressgateway] を選択します。

        レーンモード

        [厳格モード] を選択します。

        スイムレーンサービス

        [Kubernetes クラスター] ドロップダウンリストから、サンプルサービスをデプロイしたACKクラスターを選択し、[ネームスペース] ドロップダウンリストから [default] を選択します。 次に、サービスリストで [mocka]、[mockb]、[mockc] を選択し、移动 アイコンをクリックして、サービスを [選択済み] セクションに追加します。

    2. s1、s2、s3レーンを作成し、s1レーンをサンプルサービスのバージョン 1（v1）に、s2レーンをサンプルサービスのバージョン 2（v2）に、s3レーンをサンプルサービスのバージョン 3（v3）にバインドします。

      1. [トラフィックルールの定義] セクションの [トラフィックレーン] ページで、[スイムレーンの作成] をクリックします。

      2. [スイムレーンの作成] ダイアログボックスで、パラメーターを設定し、[OK] をクリックします。

        パラメーター

        説明

        スイムレーン名

        3つのレーンにそれぞれ s1、s2、s3 という名前を付けます。

        サービス タグの設定

        [ラベルキー]: [ASM_TRAFFIC_TAG] を選択します。

        [ラベル値]: s1レーンには v1、s2レーンには v2、s3レーンには v3 を選択します。

        次の図は、s1レーンの構成を示しています。

        创建泳道

        3つのレーンが作成されると、次の図に示すように、[トラフィックルールの定義] セクションに表示されます。创建泳道

        レーン内の各サービスに対して、デスティネーションルールと仮想サービスが自動的に生成されます。 左側のナビゲーションペインで [トラフィック管理センター] > [destinationrule] または [virtualservice] を選択して、デスティネーションルールまたは仮想サービスを表示できます。 たとえば、次のデスティネーションルールと仮想サービスは、mocka サービスに対して自動的に作成されます。

        展開してデスティネーションルールのサンプル 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
    - labels:
        ASM_TRAFFIC_TAG: v3
      name: s3

        展開して仮想サービスのサンプル 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:
        - sourceLabels:
            ASM_TRAFFIC_TAG: v1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
    - match:
        - sourceLabels:
            ASM_TRAFFIC_TAG: v2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
    - match:
        - sourceLabels:
            ASM_TRAFFIC_TAG: v3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3

    3. 各レーンにトラフィックルーティングルールを作成します。

      1. [トラフィックルールの定義] セクションの [トラフィックレーン] ページで、トラフィックルーティングルールを作成するレーンを見つけ、イングレス トラフィック ルール[アクション] 列の をクリックします。

      2. [ドレナージュ ルールの追加] ダイアログボックスで、パラメーターを設定し、[OK] をクリックします。

        この例では、レーン内のすべてのサービスの受信リクエストパスが /mock であり、各レーンに同じトラフィックルーティングルールが設定されていることを前提としています。

        パラメーター

        説明

        イングレスサービス

        [mocka.default.svc.cluster.local] を選択します。

        イングレストラフィックルール

        [名前] パラメーターを r1 に設定し、[レルム名] パラメーターを [*] に設定します。

        リクエスト URI の一致

        [メソッド] パラメーターを [完全一致] に設定し、[コンテンツ] パラメーターを /mock に設定します。

        ヘッダー一致ルールの追加

        [ヘッダー一致ルールの追加] をクリックします。 [名前] を x-asm-prefer-tag に、[メソッド] を [完全一致] に、[コンテンツ] をそれぞれ s1、s2、s3 に設定します。

        次の図は、s1レーンのトラフィックルーティングルールの構成を示しています。

        image.png

        トラフィックルーティングルールが作成されると、次の図に示すように、[トラフィックルールの定義] セクションに表示されます。image.png

        トラフィックルーティングルールが作成されると、レーンに仮想サービスが自動的に生成されます。 たとえば、次の仮想サービスは s1 レーンに対して生成されます。

        展開して仮想サービスのサンプル YAML コードを表示

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

    手順 3：エンドツーエンドのカナリアリリース機能が有効になっていることを確認する

    1. ASMイングレスゲートウェイのパブリック IP アドレスを取得します。 詳細については、「手順 2：ASMイングレスゲートウェイの IP アドレスを取得する」をご参照ください。

    2. 次のコマンドを実行して、環境変数を設定します。

      xxx.xxx.xxx.xxx は、サブステップ 1 で取得した IP アドレスです。

      export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

    3. エンドツーエンドのカナリアリリース機能が有効になっていることを確認します。

      1. 次のコマンドを実行して、s1レーンのサービスにアクセスします。

        コマンドでは、x-asm-prefer-tag の値は s1 です。これは、「手順 2」のサブステップ 2 で s1 レーンを作成したときに設定した s1 レーンの名前です。

        for i in {1..100};  do curl   -H 'x-asm-prefer-tag: 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 ヘッダー x-asm-prefer-tag: s1 で指定されたトラフィックが、s1 レーンの関連サービスに流れていることを示しています。 これは期待どおりです。

      2. 次のコマンドを実行して、s2レーンのサービスにアクセスします。

        コマンドでは、x-asm-prefer-tag の値は s2 です。これは、「手順 2」のサブステップ 2 で s2 レーンを作成したときに設定した s2 レーンの名前です。

        for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s2' 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)

        出力は、HTTP ヘッダー x-asm-prefer-tag: s2 で指定されたトラフィックが、s2 レーンの関連サービスに流れていることを示しています。 これは期待どおりです。

      3. 次のコマンドを実行して、s3レーンのサービスにアクセスします。

        コマンドでは、x-asm-prefer-tag の値は s3 です。これは、「手順 2」のサブステップ 2 で s3 レーンを作成したときに設定した s3 レーンの名前です。

        for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s3' 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)

        出力は、HTTP ヘッダー x-asm-prefer-tag: s3 で指定されたトラフィックが s3 レーンの関連サービスに流れていることを示しています。 これは期待どおりです。

    カスタム仮想サービスを使用して、厳格モードのトラフィックレーンにトラフィックをルーティングする

    ASM コンソールには、リクエストルーティングルール作成機能が組み込まれています。 トラフィックレーンに対応する ASM イングレスゲートウェイで仮想サービスを作成すると、トラフィックレーンにリクエストルーティングルールが作成されます。 これにより、ASM イングレスゲートウェイはリクエストを異なるトラフィックレーンに転送できます。

    トラフィックレーンのリクエストルーティングルールには、リクエストヘッダーとリクエストパスの一致ルールが含まれます。 カスタム仮想サービスを作成して、より複雑な一致ルールを定義したり、カスタムリクエストルートを作成したりできます。

    説明

    カスタム仮想サービスを使用してトラフィックレーンのトラフィックをルーティングする場合は、組み込みのリクエストルーティングルール作成機能を使用してトラフィックレーンのリクエストルーティングルールを作成しないことをお勧めします。 これは、カスタム仮想サービスが、組み込みのリクエストルーティングルール作成機能を使用して作成されたリクエストルーティングルールと競合する可能性があるためです。 その結果、異常なトラフィック分散や予期しないトラフィック分散が発生する可能性があります。

    ASMイングレスゲートウェイでカスタム仮想サービスを作成する

    1. このトピックのシナリオは例です。 手順 2 のサブステップ 3 3 つのレーンのトラフィックルーティングルールを作成する で、トラフィックルーティングルールを作成する手順を、次のコンテンツを使用して仮想サービスを作成する手順に変更します。 詳細については、「仮想サービスの管理」をご参照ください。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: swimlane-ingress-vs-custom
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match: # この一致ルールは env: dev リクエストヘッダーと完全に一致します。
        - headers:
            env:
              exact: dev
      name: dev-route
      route:
        - destination:
            host: mocka.default.svc.cluster.local # トラフィック転送の宛先サービス。
            subset: s2 # トラフィックレーンの名前。
          weight: 50
        - destination:
            host: mocka.default.svc.cluster.local # トラフィック転送の宛先サービス。
            subset: s3 # トラフィックレーンの名前。
          weight: 50
    - name: base-route
      route:
        - destination:
            host: mocka.default.svc.cluster.local # トラフィック転送の宛先サービス。
            subset: s1 # トラフィックレーンの名前。

    2. 手順 3：エンドツーエンドのカナリアリリース機能が有効になっていることを確認する のコマンドを実行します。 s1、s2、s3 レーンのサービスにアクセスすると、次の出力が生成されます。

      -> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)

      env: dev リクエストヘッダーを付けて s1 レーンのサービスにアクセスした場合の結果を確認するには、次のコマンドを実行します。

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

      期待される出力：

      期待される出力を表示

      -> mocka(version: v2, ip: 192.168.0.47)-> mockb(version: v2, ip: 192.168.0.49)-> mockc(version: v2, ip: 192.168.0.43)
...(truncated for brevity - shortened the repeated output lines)

      出力は、env: dev リクエストヘッダーを付けて s1 レーンのサービスにアクセスすると、サービスの V2 バージョンを含むトレースとサービスの V3 バージョンを含むトレースが関係し、2種類のトレースのリクエストの比率が約 50:50 であることを示しています。 つまり、env: dev リクエストヘッダー付きのリクエストは、50:50 の比率で s2 レーンと s3 レーンにルーティングされ、残りのリクエストは s1 レーンに転送されます。

    上記の仮想サービスは、ASM ゲートウェイのカスタムルーティングルールを指定して、トラフィックを異なるトラフィックレーンに転送します。 厳格モードのトラフィックレーンへのリクエストをルーティングするためにカスタム仮想サービスを作成する場合、リクエストを特定のトラフィックレーンにルーティングするには、route.destination.subset フィールドをトラフィックレーンの名前に設定するだけです。 リクエストがトラフィックレーンにルーティングされると、トレース内の他のリクエストはトラフィックレーンで送信されます。

    サイドカープロキシでカスタム仮想サービスを作成する

    ASMイングレスゲートウェイでカスタム仮想サービスを作成するだけでなく、すべてのサイドカープロキシで仮想サービスを作成することにより、クラスター内のアプリケーションがトラフィックレーンのサービスにアクセスするためのリクエストルーティングルールを指定することもできます。 ASMイングレスゲートウェイのカスタム仮想サービスとは異なり、サイドカープロキシの仮想サービスには gateway フィールドは不要です。 hosts フィールドに mocka サービスのクラスタードメインを指定する必要があります。 YAML ファイルの例：

    ...(truncated for brevity - YAML code is the same as the previous one)

    1. サイドカープロキシでカスタム仮想サービスを作成した後、env: dev リクエストヘッダーなしで次のコマンドを実行して、mocka サービスにアクセスします。

      kubectl exec -it deploy/sleep -c sleep --  sh -c 'for i in $(seq 1 100);  do curl http://mocka:8000;  echo ""; sleep 1; done;'

      期待される出力：

      -> mocka(version: v1, ip: 192.168.0.50)-> mockb(version: v1, ip: 192.168.0.46)-> mockc(version: v1, ip: 192.168.0.48)

      出力は、env: dev リクエストヘッダーなしですべてのレーンのサービスにアクセスすると、サービスの V1 バージョンを含むトレースが常に関係していることを示しています。 これは、すべてのトラフィックが s1 レーンに送信されることを示しています。

    2. サイドカープロキシでカスタム仮想サービスを作成した後、env: dev リクエストヘッダーを付けて次のコマンドを実行して、mocka サービスにアクセスします。

      kubectl exec -it deploy/sleep -c sleep --  sh -c 'for i in $(seq 1 100);  do curl -H "env: dev" http://mocka:8000;  echo ""; sleep 1; done;'

      期待される出力：

      mocka サービスにアクセスした場合の期待される出力を表示

      ...(truncated for brevity - output is the same as the previous one)

      ASMイングレスゲートウェイでカスタム仮想サービスを作成する の出力と同じです。 env: dev リクエストヘッダーを付けて mocka サービスにアクセスすると、トラフィックは 50:50 の比率で s2 レーンと s3 レーンにルーティングされます。

    ASMイングレスゲートウェイでカスタム仮想サービスを作成する と同様に、クラスター内のサービスがトラフィックレーン内の mocka サービスを呼び出すと、トレース内の後続のリクエストは常にトラフィックレーンにルーティングされます。

    参照

    • トラフィックレーンには、厳格モードと許容モードの 2 つのモードがあります。 2 つのモードとその違いの詳細については、「トラフィックレーンの概要」をご参照ください。

    • 許容モードのトラフィックレーンは、エンドツーエンドのパススルーリクエストヘッダーが使用される場合、より多くのシナリオで使用できます。 たとえば、トレース内の一部のサービスの新しいバージョンのみがリリースされる場合、許容モードのトラフィックレーンを使用してこれらの新しいバージョンをテストできます。 詳細については、「許容モードのトラフィックレーンを使用してエンドツーエンドのトラフィックを管理する」をご参照ください。

    • 仮想サービスとデスティネーションルールを指定することで、トラフィックレーンを設定できます。 また、これらのルールを使用してトラフィックシフトを設定することもできます。トラフィックシフトでは、宛先バージョンまたはアプリケーションが使用できない場合、優先度の低いバージョンまたは特定の特性を持つアプリケーションにトラフィックがルーティングされます。 詳細については、「トラフィックルールを使用してトラフィックレーンとトラフィックシフトを設定する」をご参照ください。