トラフィック管理のためのレーンの使用 - Alibaba Cloud Service Mesh

Service Mesh (ASM) では、トラフィックラベル機能を使用して、アプリケーションのバージョンまたは特定の機能を独立したランタイム環境 (レーンと呼ばれます) に分離できます。その後、ルールに一致するリクエストをアプリケーションのデスティネーションバージョンまたは機能にルーティングするように、レーンルールを設定できます。このトピックでは、ASM コンソールでレーンを使用してトラフィックを管理する方法について説明します。

前提条件

Enterprise Edition または Ultimate Edition の ASM インスタンスが作成されており、インスタンスのバージョンが 1.17.2.22 以降であること。詳細については、「ASM インスタンスの作成」または「ASM インスタンスの更新」をご参照ください。
クラスターが ASM インスタンスに追加されていること。詳細については、「クラスターを ASM インスタンスに追加する」をご参照ください。
ingressgateway という名前の ASM ゲートウェイが作成されていること。詳細については、「イングレスゲートウェイの作成」をご参照ください。

istio-system 名前空間に ingressgateway という名前の 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:
        - '*'

機能

カナリアリリースを使用すると、新しいサービスまたはバージョンを段階的にロールアウトできます。たとえば、新しいバージョンをリリースする場合、最初にトラフィックの一部をそのバージョンに転送して機能をテストし、機能が検証された後にトラフィックを増やすことができます。

エンドツーエンドのカナリアリリースでは、主に異なるマイクロサービス呼び出しチェーンを介してリクエストトラフィックをルーティングします。この目的のためにマイクロサービスを再構成する必要はありません。ゲートウェイからサービスへのトラフィックの分離環境を構築するには、いくつかのルールが必要です。エンドツーエンドのカナリアリリースにより、複数のサービスまたはサービスの複数のバージョンを同時にリリースすることが容易になります。詳細については、「トラフィックのラベル付け」をご参照ください。

この例では、s1、s2、s3 の 3 つのレーンがデプロイされ、各レーンには mocka、mockb、mockc の 3 つのサービスが含まれています。 ASM コンソールにレーンをデプロイした後、トラフィックが期待どおりにレーン間で分散されているかどうかを確認します。泳道模式的全链路灰度

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

default 名前空間の自動サイドカープロキシインジェクションを有効にします。詳細については、「グローバル名前空間の管理」をご参照ください。
詳細については、「サイドカープロキシインジェクションポリシーの設定」をご参照ください。
1. ASM コンソールにログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。
2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[ASM インスタンス] > [グローバル名前空間] を選択します。
3. [グローバル名前空間] ページで、default 名前空間を見つけ、自動サイドカーインジェクションを有効にする[自動サイドカーインジェクション] 列の送信OK をクリックします。メッセージで、をクリックします。

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

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：レーングループとレーンを作成する

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

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

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

パラメーター	説明
スイムレーングループの名前	この例では、test と入力します。
入口ゲートウェイ	ingressgateway を選択します。
スイムレーンサービス	[kubernetes クラスター] ドロップダウンリストから目的の ACK クラスターを選択し、[名前空間] ドロップダウンリストから default を選択します。次に、サービスリストで mocka、mockb、mockc を選択し、アイコンをクリックしてサービスを [選択済み] セクションに追加します。

設定後、対応するトラフィックラベルが生成されます。

トラフィックラベルの YAML コードを表示

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  labels:
    asm-system: 'true'
    provider: asm
  name: asm-trafficlabel-global
  namespace: istio-system
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - $getLabel(ASM_TRAFFIC_TAG)

s1、s2、s3 レーンを作成し、s1 レーンをサンプルサービスの v1 に、s2 レーンをサンプルサービスの v2 に、s3 レーンをサンプルサービスの v3 にバインドします。

このトピックでは、s1 レーンの作成方法のみを説明します。 s2 レーンと s3 レーンは同じ方法で作成できます。

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

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

パラメーター	説明
スイムレーン名	この例では、s1 と入力します。説明ヘッダーに `'x-asm-prefer-tag: レーン名'` の形式でレーン名が含まれているリクエストは、対応するバージョンのサービスにルーティングされます。
サービスタグの設定	この例では、v1 と入力します。
サービスの追加	この例では、mocka(default)、mockb(default)、mockc(default) サービスを選択します。

创建泳道

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

レーンを作成するたびに、システムはデスティネーションルールを作成します。次のコードは、s1 レーンを作成した後に作成されるデスティネーションルールの例を示しています。

デスティネーションルールのサンプル YAML コードを表示

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  creationTimestamp: '2023-05-29T09:06:09Z'
  generation: 3
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
  resourceVersion: '1310364657'
  uid: 7112ce64-0176-4ff3-b5f3-66263085****
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: v1
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: v2
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2
    - labels:
        ASM_TRAFFIC_TAG: v3
      name: v3
    - labels:
        ASM_TRAFFIC_TAG: v3
      name: s3

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

このトピックでは、s1 レーンのトラフィックルーティングルールを作成する方法のみを説明します。 s2 レーンと s3 レーンのトラフィックルーティングルールは同じ方法で作成できます。

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

[排水ルールの追加] ダイアログボックスで、パラメーターを設定し、[OK] をクリックします。

この例では、すべてのレーンサービスのインバウンドリクエストパスが /mock であると想定し、各レーンに同じトラフィックルーティングルールが設定されています。

パラメーター	説明
イングレスサービス	この例では、mocka.default.svc.cluster.local を選択します。
イングレストラフィックルール	この例では、[名前] パラメーターを r1 に設定し、[レルム名] パラメーターを * に設定します。
リクエスト URI の一致	この例では、[メソッド] パラメーターを [完全一致] に設定し、[コンテンツ] パラメーターを /mock に設定します。

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

次に、システムは仮想サービスを生成します。次のコードは、仮想サービスの例を示しています。

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

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  creationTimestamp: '2023-05-29T09:13:00Z'
  generation: 3
  labels:
    asm-system: 'true'
    istioGateway: ingressgateway
    provider: asm
  name: ingressgateway
  namespace: istio-system
  resourceVersion: '1310388638'
  uid: d60baa2f-3a12-472f-881a-15d21004****
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s2-rule2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s3
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s3-rule3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s1
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s1-rule1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  creationTimestamp: '2023-05-29T09:13:00Z'
  generation: 3
  labels:
    asm-system: 'true'
    istioGateway: ingressgateway
    provider: asm
  name: ingressgateway
  namespace: istio-system
  resourceVersion: '1310388638'
  uid: d60baa2f-3a12-472f-881a-15d21004****
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s2-rule2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s3
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s3-rule3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s1
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s1-rule1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1

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

ASM ゲートウェイのパブリック IP アドレスを取得します。詳細については、「クラウドネイティブ推論サービス KServe と ASM の統合」の手順 2：ASM インスタンスのイングレスゲートウェイの IP アドレスを照会するをご参照ください。
次のコマンドを実行して、環境変数を設定します。
xxx.xxx.xxx.xxx は、サブステップ 1 で取得した IP アドレスです。
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
エンドツーエンドカナリアリリース機能が有効になっていることを確認します。
1. 次のコマンドを実行して、s1 レーンのサービスにアクセスします。
  コマンドでは、x-asm-prefer-tag の値は s1 です。これは、手順 2 でレーンを作成したときに設定したレーンの名前です。
```
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 でレーンを作成したときに設定したレーンの名前です。
```
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 でレーンを作成したときに設定したレーンの名前です。
```
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 レーンの関連サービスに流れます。これは期待どおりです。

(オプション) 手順 4：メッシュトポロジを確認する

ASM コンソールでメッシュトポロジを有効にしている場合は、前述のリクエストのトポロジを確認できます。詳細については、「可観測性を向上させるためのメッシュトポロジの有効化」をご参照ください。