Alibaba Cloud Service Mesh:アプリケーションサービスのエンドツーエンドカナリアリリースの実装に Argo CD を使用する

ステップ 1：Argo CD を使用してアプリケーションサービスとトラフィックレーンルールをデプロイする

1. モックアプリケーションを作成し、アプリケーションのエンドツーエンドキャリーリリースを実装します。

   1. Argo CD UI で、[新しいアプリ] をクリックし、パラメーターを設定します。

      

      パラメーター	説明
      アプリケーション名	アプリケーション名。この例では、mock と入力します。
      同期ポリシー	アプリケーションの同期ポリシー。この例では、自動 を選択します。これは、Git リポジトリ内のリソース定義が変更されたときに、Git リポジトリ内の最新のリソース定義が自動的に同期されることを意味します。リソースの削除 を選択すると、リソースの定義が Git リポジトリに存在しなくなったときにリソースが削除されます。
      リポジトリ URL	リソース定義を同期する Git リポジトリの URL。この例では、https://github.com/AliyunContainerService/asm-labs.git と入力します。Git リポジトリをフォークし、フォークされた Git リポジトリの YAML コードを変更できます。
      リビジョン	リソース定義が同期される Git リポジトリの Git タグまたはブランチ名。この例では、argocd-asm と入力します。
      パス	リソース定義が同期される Git リポジトリ内のコードパス。この例では、以下の例で使用されるリソースが配置されている argo-cd/swimlane パスを入力します。
      クラスター URL	リソース定義の同期先となるクラスターの Kubernetes API サーバーのエンドポイント。この例では、https://kubernetes.default.svc と入力します。これは、Argo CD がインストールされているクラスターの Kubernetes API サーバーのエンドポイントです。

2. パラメーターを設定したら、ページ上部の [作成] をクリックします。

   Argo CD UI の [アプリケーション] ページで、作成したばかりのモックアプリケーションのステータスを表示できます。

   

3. モックアプリケーションをクリックして、リソースの同期ステータスを表示します。

   

   Deployments および Services リソースに加えて、Git リポジトリには VirtualServices、Gateways、ASMSwimLaneGroup、ASMSwimLane などのリソースも含まれていることがわかります。

ステップ 2：トラフィックレーンを使用してエンドツーエンドカナリアリリースを検証する

この例では、ASMSwimLaneGroup および ASMSwimLane CRD を使用して、v1 と v2 のサービスを分離します。仮想サービスを作成して、イングレスゲートウェイが 1:1 の比率で 2 つのバージョンのサービスにリクエストを転送できるようにします。イングレスゲートウェイに繰り返しアクセスして、エンドツーエンドカナリアリリースを検証できます。

1. ASM コンソール でイングレスゲートウェイのパブリック IP アドレスを取得します。詳細については、「KServe と ASM を統合してクラウドネイティブ AI モデルに基づく推論サービスを実装する」トピックの「ステップ 2：ASM イングレスゲートウェイの IP アドレスを取得する」セクションをご参照ください。

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

   xxx.xxx.xxx.xxx は、手順 1 で取得した IP アドレスです。

   export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx  // イングレスゲートウェイのIPアドレスを環境変数に設定します
   

3. 次のコマンドを実行して、イングレスゲートウェイに繰り返しアクセスします。

   for i in {1..100}; do curl http://${ASM_GATEWAY_IP}/mock; echo ''; sleep 1; done; // イングレスゲートウェイに繰り返しアクセスします
   

   予期される出力：

   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   -> mocka(version: v1, ip: 10.0.239.75)-> mockb(version: v1, ip: 10.0.239.138)-> mockc(version: v1, ip: 10.0.239.137)
   -> mocka(version: v2, ip: 10.0.239.73)-> mockb(version: v2, ip: 10.0.239.136)-> mockc(version: v2, ip: 10.0.239.139)
   ... // v1とv2へのリクエストがほぼ1:1の比率で送信されていることを示す出力
   

   出力は、mock アプリケーションに mocka、mockb、mockc の 3 つのサービスが含まれていることを示しています。各サービスには、v1 と v2 の 2 つのバージョンがあります。3 つのサービスは、mocka > mockb > mockc の順序で呼び出されます。リクエストは、mock アプリケーションの v1 および v2 バージョンにほぼ 1:1 の比率で送信されます。さらに、サービスの v1 および v2 バージョンは個別に呼び出されます。エンドツーエンドカナリアリリースは期待どおりに実装されています。

関連操作

サービスの新しいバージョンの公開

次の図は、この例で使用されているサンプル Git リポジトリファイルの構造を示しています。

サービスの新しいバージョンを公開するには、サンプル Git リポジトリ https://github.com/AliyunContainerService/asm-labs.git の argocd-asm ブランチをフォークし、argo-cd/swimlane パスにある上記の YAML リソースを変更してから、変更をリモート Git リポジトリに送信します。変更を送信すると、Argo CD は Git リポジトリの変更を自動的に同期します。ステップ 1 の リポジトリ URL フィールドに、フォークされた Git リポジトリの URL を入力する必要があります。

たとえば、mocka、mockb、mockc サービスの v3 バージョンを公開します。Git リポジトリの YAML リソースに次の変更を加える必要があります。

1. argo-cd/swimlane/mock-v3.yaml ファイルを作成します。

   YAML ファイルは、mocka、mockb、mockc サービスの v3 バージョンのデプロイを定義します。

   YAML コードを表示

   apiVersion: apps/v1
   kind: Deployment
   metadata:
    name: mocka-v3 // デプロイメント名
    labels:
    app: mocka
    version: v3 // バージョンラベル
   spec:
    replicas: 1
    selector:
    matchLabels:
    app: mocka
    version: v3
    ASM_TRAFFIC_TAG: v3
    template:
    metadata:
    labels:
    app: mocka
    version: v3
    ASM_TRAFFIC_TAG: v3
    spec:
    containers:
    - name: default
    image: registry.cn-beijing.aliyuncs.com/aliacs-app-catalog/go-http-sample:1.0 // 使用するイメージ
    imagePullPolicy: IfNotPresent
    env:
    - name: version
    value: v3
    - name: app
    value: mocka
    - name: upstream_url
    value: "http://mockb:8000/" // アップストリームURL
    ports:
    - containerPort: 8000
   ---
   // mockb-v3 と mockc-v3 のデプロイメントも同様に定義します。
   

2. argo-cd/swimlane/swimlanes.yaml ファイルの内容を、次のコードブロックの YAML コードに変更します。

   この例では、v3 という名前の ASMSwimLane CRD がファイルに追加されます。ASMSwimLane CRD は、mock という名前の ASMSwimLaneGroup CRD に関連付けられており、version:v3 ラベルが付いたポッドが v3 サービスを実行することを指定します。

   YAML コードを表示

   apiVersion: istio.alibabacloud.com/v1
   kind: ASMSwimLane
   metadata:
    labels:
    swimlane-group: mock // 関連付けられたレーン グループ
    name: v1 // レーン名
   spec:
    labelSelector:
    version: v1 // v1 サービスのラベルセレクター
   ---
   // v2 と v3 のレーンも同様に定義します。
   

3. argo-cd/swimlane/mock-route.yaml ファイルの内容を、次のコードブロックの YAML コードに変更します。

   この例では、ファイル内の mock という名前の仮想サービスが変更され、v3 バージョンの mocka サービスがルート先に追加されます。subset フィールドは、トラフィックレーンの名前を指定します。weight フィールドは仮想サービス内で変更されます。v1、v2、v3 のサービスのカナリアリリースの比率は 6:3:1 に変更されます。

   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: mock
    namespace: istio-system
   spec:
    gateways:
    - ingressgateway
    hosts:
    - '*'
    http:
    - match:
    - uri:
    exact: /mock
    route:
    - destination:
    host: mocka.default.svc.cluster.local
    subset: v1 // v1 レーン
    weight: 60 // v1 のウェイト
    - destination:
    host: mocka.default.svc.cluster.local
    subset: v2 // v2 レーン
    weight: 30 // v2 のウェイト
    - destination:
    host: mocka.default.svc.cluster.local
    subset: v3 // v3 レーン
    weight: 10 // v3 のウェイト