:MSEマルチクラスタゲートウェイを使用してACK Oneでゾーンディザスタリカバリを実装する

Argo CD UIを使用したアプリケーションのデプロイ

1. ACK Oneコンソールにログインします。 左側のナビゲーションウィンドウで、フリート> マルチクラスタアプリケーションを選択します。

2. フリートインスタンスのGitOpsページで、GitOpsコンソールをクリックしてGitOpsコンソールに移動します。

   説明

   • GitOpsがACK One フリートインスタンスで有効になっていない場合は、[GitOpsの有効化] をクリックしてGitOpsコンソールにログインします。

   • GitOpsへのインターネットアクセスを有効にする方法の詳細については、「Argo CDへのパブリックアクセスの有効化」をご参照ください。

3. アプリケーションリポジトリを追加します。

   1. ArgoCD UIの左側のナビゲーションウィンドウで、[設定] をクリックし、[リポジトリ] > [レポ接続] を選択します。

   2. 表示されるパネルで、次のパラメーターを設定し、[接続] をクリックします。

      セクション	パラメーター	値
      Choose your connection method		VIA HTTPS
      HTTPSを使用したCONNECT REPO	タイプ	git
      	プロジェクト	default
      	リポジトリURL	https://github.com/AliyunContainerService/gitops-demo.git
      	[サーバー検証のスキップ]	チェックボックスをオンにします。

      

      Gitリポジトリが接続されると、[CONNECTION STATUS] に [Successful] が表示されます。

      

4. アプリケーションを作成します。

   Argo CDの [アプリケーション] ページで、[新しいアプリ] をクリックし、次のパラメーターを設定します。

   セクション	パラメーター	説明
   一般	アプリケーション名	アプリケーション名。 カスタムアプリケーション名を指定できます。
   	プロジェクト名	default
   	SYNCポリシー	要件に基づいて同期ポリシーを選択します。 有効な値： 手動: Gitリポジトリ内のイメージに変更が加えられた場合、変更をターゲットクラスターに手動で同期する必要があります。 自動: Argo CDは、3分ごとにイメージの変更についてGitリポジトリをチェックし、変更をターゲットクラスターに自動的に同期します。
   	SYNCオプション	[AUTO-CREATE NAMESPACE] を選択します。
   ソース	リポジトリURL	ドロップダウンリストからGitリポジトリを選択し、前の手順で追加したURL https://github.com/AliyunContainerService/gitops-demo.git を選択します。
   	リビジョン	ブランチ: [ブランチ] ドロップダウンリストで [gateway-demo] を選択します。
   	パス	manifests/helm/web-demo
   目的地	クラスターURL	クラスター1またはクラスター2のURLを選択します。 右側のURLドロップダウンリストをクリックし、名前を選択して、クラスター名に基づいてURLを選択することもできます。
   	名前空間	この例では、gateway-demoを使用しています。 アプリケーションリソース (サービスとデプロイメント) は、この名前空間に作成されます。
   ヘルム	パラメーター	リクエストを処理するクラスター内のバックエンドポッドを指定するには、envClusterをcluster-demo-1またはcluster-demo-2に設定します。

Argo CD CLIを使用したアプリケーションのデプロイ

1. ACK One FleetインスタンスでGitOpsを有効にします。 詳細については、「フリートインスタンスのGitOpsの有効化」をご参照ください。

2. Argo CDにアクセスします。 詳細については、「Argo CD CLIを使用したArgo CDへのログオン」をご参照ください。

3. アプリケーションを作成してデプロイします。

   1. 次のコマンドを実行してGitリポジトリを追加します。

      argocd repo add https://github.com/AliyunContainerService/gitops-demo.git --name ackone-gitops-demos

      期待される出力:

      Repository 'https://github.com/AliyunContainerService/gitops-demo.git' added

   2. 次のコマンドを実行して、Gitリポジトリを照会します。

      argocd repo list

      期待される出力:

      TYPE  NAME  REPO                                                       INSECURE  OCI    LFS    CREDS  STATUS      MESSAGE  PROJECT
      git         https://github.com/AliyunContainerService/gitops-demo.git  false     false  false  false  Successful           default

   3. 次のコマンドを実行してクラスターを照会します。

      argocd cluster list

      期待される出力:

      SERVER                          NAME                                        VERSION  STATUS      MESSAGE                                                  PROJECT
      https://1.1.XX.XX:6443      c83f3cbc90a****-temp01   1.22+    Successful
      https://2.2.XX.XX:6443      c83f3cbc90a****-temp02   1.22+    Successful
      https://kubernetes.default.svc  in-cluster                                           Unknown     Cluster has no applications and is not being monitored.

   4. アプリケーションモードを使用して、アプリケーションを作成し、移行先クラスターにデプロイします。

      1. apps-web-demo.yamlという名前のファイルを作成し、次のコンテンツをファイルに追加します。

         repoURLを実際のリポジトリURLに置き換えます。

         apps-web-demo.yamlを表示

         apiVersion: argoproj.io/v1alpha1
         kind: Application
         metadata:
           name: app-demo-cluster1
           namespace: argocd
         spec:
           destination:
             namespace: gateway-demo
             # https://1.1.XX.XX:6443
             server: ${cluster1_url}
           project: default
           source:
             helm:
               releaseName: "web-demo"
               parameters:
               - name: envCluster
                 value: cluster-demo-1
               valueFiles:
               - values.yaml
             path: manifests/helm/web-demo
             repoURL: https://github.com/AliyunContainerService/gitops-demo.git
             targetRevision: gateway-demo
           syncPolicy:
             syncOptions:
             - CreateNamespace=true
         ---
         apiVersion: argoproj.io/v1alpha1
         kind: Application
         metadata:
           name: app-demo-cluster1
           namespace: argocd
         spec:
           destination:
             namespace: gateway-demo
             server: ${cluster2_url}
           project: default
           source:
             helm:
               releaseName: "web-demo"
               parameters:
               - name: envCluster
                 value: cluster-demo-2
               valueFiles:
               - values.yaml
             path: manifests/helm/web-demo
             repoURL: https://github.com/AliyunContainerService/gitops-demo.git
             targetRevision: gateway-demo
           syncPolicy:
             syncOptions:
             - CreateNamespace=true

      2. 次のコマンドを実行して、アプリケーションをデプロイします。

         kubectl apply -f apps-web-demo.yaml

      3. 次のコマンドを実行して、アプリケーションを照会します。

         argocd app list

         期待される出力:

         # app list
         NAME                      CLUSTER                  NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                       PATH                     TARGET
         argocd/web-demo-cluster1  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main
         argocd/web-demo-cluster2  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main

アクティブゾーン冗長性

アクティブゾーン冗長性を実装するIngressオブジェクトの作成

ACK One FleetインスタンスにIngressオブジェクトを作成して、アクティブなゾーン冗長性を実装します。

デフォルトでは、トラフィックは、マルチクラスタゲートウェイに接続されているクラスタ1およびクラスタ2のアプリケーションのすべてのレプリケートされたポッドに配信されます。 クラスター1のバックエンドポッドがダウンすると、ゲートウェイはすべてのトラフィックをクラスター2のバックエンドポッドに自動的に配信します。 クラスター1の複製ポッドとクラスター2の複製ポッドの比率は9:1です。 したがって、90% トラフィックはクラスタ1にルーティングされ、10% トラフィックはクラスタ2にルーティングされます。 クラスター1のすべてのバックエンドポッドがダウンすると、ゲートウェイはすべてのトラフィックをクラスター2に自動的にルーティングします。 次の図は、トポロジを示しています。

1. ingress-demo.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。

   次のコードでは、ドメイン名example.comの下の /svc1転送ルールを使用して、service1という名前のバックエンドサービスを公開します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: web-demo
   spec:
     ingressClassName: mse
     rules:
     - host: example.com
       http:
         paths:
         - path: /svc1
           pathType: Exact
           backend:
             service:
               name: service1
               port: 
                 number: 80

2. 次のコマンドを実行して、ACK OneフリートインスタンスにIngressをデプロイします。

   kubectl apply -f ingress-demo.yaml -n gateway-demo

カナリアバージョンの確認

アクティブなゾーン冗長性のシナリオでは、次の方法を使用して、ビジネスに影響を与えずにアプリケーションのカナリアバージョンを確認できます。

既存のクラスターにアプリケーションを作成します。 サービスと展開の名前とセレクターを指定します。 名前とセレクターが元のアプリケーション用に設定されたものと異なることを確認します。 次に、リクエストヘッダーに基づいてアプリケーションのカナリアバージョンを確認します。

1. クラスター1にnew-app.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。 サービスと展開の設定を除いて、元の設定を保持します。

   apiVersion: v1       
   kind: Service
   metadata:
     name: service1-canary-1
     namespace: gateway-demo
   spec:
     ports:
     - port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: web-demo-canary-1
     sessionAffinity: None
     type: ClusterIP
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-demo-canary-1
     namespace: gateway-demo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: web-demo-canary-1
     template:
       metadata:
         labels:
           app: web-demo-canary-1
       spec:
         containers:
           - env:
               - name: ENV_NAME
                 value: cluster-demo-1-canary
             image: 'registry-cn-hangzhou.ack.aliyuncs.com/acs/web-demo:0.6.0'
             imagePullPolicy: Always
             name: web-demo

2. 次のコマンドを実行して、canaryバージョンをクラスター1にデプロイします。

   kubectl apply -f new-app.yaml

3. new-ingress.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。

   ACK One FleetインスタンスにIngressを作成し、リクエストヘッダーに基づいてリクエストをルーティングします。 アノテーションを追加してcanary機能を有効にし、canary-dest: cluster1ヘッダーを指定して、このヘッダーをcanaryバージョンに運ぶリクエストをルーティングできます。

   • nginx.ingress.kubernetes.io/canary: カナリア機能を有効にするには、値を "true" に設定します。

   • nginx.ingress.kubernetes.io/canary-by-header: カナリアバージョンにルーティングされたリクエストのヘッダーキー。

   • nginx.ingress.kubernetes.io/canary-by-header-value: カナリアバージョンにルーティングされたリクエストのヘッダー値。

     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       name: web-demo-canary-1
       namespace: gateway-demo
       annotations:
         nginx.ingress.kubernetes.io/canary: "true"
         nginx.ingress.kubernetes.io/canary-by-header: "canary-dest"
         nginx.ingress.kubernetes.io/canary-by-header-value: "cluster1"
     spec:
       ingressClassName: mse
       rules:
       - host: example.com
         http:
           paths:
           - path: /svc1
             pathType: Exact
             backend:
               service:
                 name: service1-canary-1
                 port: 
                   number: 80

4. 次のコマンドを実行して、ACK One FleetインスタンスにIngressをデプロイし、リクエストヘッダーに基づいてリクエストをルーティングします。

   kubectl apply -f new-ingress.yaml

アクティブゾーンの冗長性の確認

クラスター1にデプロイされたレプリケートポッドの数を9に変更し、クラスター2にデプロイされたレプリケートポッドの数を1に変更します。 これにより、デフォルトでは、90% トラフィックはクラスタ1にルーティングされ、10% トラフィックはクラスタ2にルーティングされます。 クラスター1のすべてのバックエンドポッドがダウンすると、すべてのトラフィックが自動的にクラスター2にルーティングされます。

次のコマンドを実行して、マルチクラスタゲートウェイのパブリックIPアドレスを照会します。

kubectl get ingress web-demo -n gateway-demo -ojsonpath="{.status.loadBalancer}"

• 指定された比率に基づいてトラフィックを2つのクラスターにルーティングする

  次のコマンドを実行して、トラフィックルーティング情報を照会します。

  XX.XX.XX.XXを、前の手順で取得したマルチクラスターゲートウェイのパブリックIPアドレスに置き換えます。

  for i in {1..100}; do curl -H "host: example.com" XX.XX.XX.XX done

  期待される出力: 出力は、90% トラフィックがクラスタ1にルーティングされ、10% トラフィックがクラスタ2にルーティングされることを示します。

• クラスタ1のすべてのバックエンドポッドがダウンしている場合、すべてのトラフィックをクラスタ2にルーティングする

  クラスター1のデプロイのレプリカ値が0に設定されている場合、次の結果が返されます。 出力は、トラフィックが自動的にクラスタ2にフェールオーバーされることを示します。

• 指定されたヘッダーを持つリクエストをカナリアバージョンにルーティングする

  次のコマンドを実行して、トラフィックルーティング情報を照会します。

  次のコマンドのXX.XX.XX.XXを、[カナリアバージョンの確認] セクションでアプリケーションとIngressをデプロイした後に取得したIPアドレスに置き換えます。

  for i in {1..100}; do curl -H "host: example.com" -H "canary-dest: cluster1" xx.xx.xx.xx/svc1; sleep 1;  done  

  期待される出力: 出力は、canary-dest: cluster1ヘッダーを持つリクエストがクラスター1のカナリアバージョンにルーティングされることを示します。

プライマリ /セカンダリのディザスタリカバリ

ACK One FleetインスタンスにIngressオブジェクトを作成して、プライマリ /セカンダリディザスタリカバリを実装します。

両方のクラスターのバックエンドポッドが正常な場合、トラフィックはクラスター1のバックエンドポッドにのみルーティングされます。 クラスター1のバックエンドポッドがダウンしている場合、ゲートウェイは自動的にトラフィックをクラスター2にルーティングします。 次の図は、トポロジを示しています。

プライマリ /セカンダリディザスタリカバリを実装するためのIngressの作成

1. ingress-demo-cluster-one.yamlという名前のファイルを作成し、次の内容をファイルに追加します。

   mse.ingress.kubernetes.io/service-subsetおよびmse.ingress.kubernetes.io/subset-labelsアノテーションをIngressオブジェクトのYAMLファイルに追加し、バックエンドのService service1を公開するためにexample.comされるドメイン名の下に /service1を使用します。 MSE Ingressでサポートされているアノテーションの詳細については、「MSE Ingressゲートウェイでサポートされているアノテーション」をご参照ください。

   • mse.ingress.kubernetes.io/service-subset: サービスのサブセットの名前。 移行先クラスターに関連する名前を使用することを推奨します。

   • mse.ingress.kubernetes.io/subset-labels: 移行先クラスターのID。

     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       annotations:
         mse.ingress.kubernetes.io/service-subset: cluster-demo-1
         mse.ingress.kubernetes.io/subset-labels: |
           topology.istio.io/cluster ${cluster1-id}
       name: web-demo-cluster-one
     spec:
       ingressClassName: mse
       rules:
       - host: example.com
         http:
           paths:
           - path: /service1
             pathType: Exact
             backend:
               service:
                 name: service1
                 port: 
                   number: 80

2. 次のコマンドを実行して、ACK OneフリートインスタンスにIngressをデプロイします。

   kubectl apply -f ingress-demo-cluster-one.yaml -ngateway-demo

クラスターレベルのカナリアリリース

マルチクラスターゲートウェイを使用すると、Ingressをデプロイして、リクエストヘッダーに基づいてリクエストを特定のクラスターにルーティングできます。 この機能と、[プライマリ /セカンダリディザスタリカバリを実装するためのIngressの作成] セクションで作成されたIngressオブジェクトを使用して、負荷分散のためにすべてのレプリケートされたポッドにトラフィックを均等に分散し、指定されたヘッダーをカナリアバージョンに運ぶリクエストをルーティングできます。

1. Ingressは、プライマリ /セカンダリディザスタリカバリを実装するためのIngressの作成セクションの手順に従って作成されます。

2. ACK One Fleetインスタンスにヘッダー関連のアノテーションを含むIngressを作成して、クラスターレベルのカナリアリリースを実装します。 リクエストのヘッダーがIngressルールと一致すると、リクエストはカナリアバージョンのバックエンドポッドにルーティングされます。

   1. ingress-demo-cluster-gray.yamlという名前のファイルを作成し、次の内容をファイルに追加します。

      次のIngressオブジェクトのYAMLファイルで、${cluster1-id} をターゲットクラスターのIDに置き換えます。 mse.ingress.kubernetes.io/service-subsetアノテーションとmse.ingress.kubernetes.io/subset-labelsアノテーションに加えて、ドメイン名example.comの下にある /service1 Ingressルールを使用して、service1という名前のバックエンドサービスを公開するには、次のアノテーションを追加する必要があります。

      • nginx.ingress.kubernetes.io/canary: カナリアリリースを有効にするには、値を "true" に設定します。

      • nginx.ingress.kubernetes.io/canary-by-header: クラスターにルーティングされるリクエストのヘッダーキー。

      • nginx.ingress.kubernetes.io/canary-by-header-value: クラスターにルーティングされたリクエストのヘッダー値。

      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        annotations:
          mse.ingress.kubernetes.io/service-subset: cluster-demo-2
          mse.ingress.kubernetes.io/subset-labels: |
            topology.istio.io/cluster ${cluster2-id}
          nginx.ingress.kubernetes.io/canary: "true"
          nginx.ingress.kubernetes.io/canary-by-header: "app-web-demo-version"
          nginx.ingress.kubernetes.io/canary-by-header-value: "gray"
        name: web-demo-cluster-gray
        name: web-demo
      spec:
        ingressClassName: mse
        rules:
        - host: example.com
          http:
            paths:
            - path: /service1
              pathType: Exact
              backend:
                service:
                  name: service1
                  port: 
                    number: 80

   2. 次のコマンドを実行して、ACK OneフリートインスタンスにIngressをデプロイします。

      kubectl apply -f ingress-demo-cluster-gray.yaml -n gateway-demo

プライマリ /セカンダリディザスタリカバリの検証

プライマリ /セカンダリディザスタリカバリを確認するには、クラスター1とクラスター2のレプリケートされたポッドの数を1に設定します。 このようにして、指定されたヘッダーを持つリクエストはクラスター2にルーティングされ、その他のリクエストはデフォルトでクラスター1にルーティングされます。 クラスター1のバックエンドポッドがダウンしている場合、トラフィックはクラスター2にルーティングされます。

次のコマンドを実行して、マルチクラスタゲートウェイのパブリックIPアドレスを照会します。

kubectl get ingress web-demo -n gateway-demo -ojsonpath="{.status.loadBalancer}"

• デフォルトでトラフィックをクラスタ1にルーティングする

  次のコマンドを実行して、トラフィックがデフォルトでクラスター1にルーティングされているかどうかを確認します。

  XX.XX.XX.XXを、前の手順で取得したマルチクラスターゲートウェイのパブリックIPアドレスに置き換えます。

  for i in {1..100}; do curl -H "host: example.com" xx.xx.xx.xx/service1; sleep 1;  done

  期待される出力: 出力は、すべてのトラフィックがデフォルトでクラスター1にルーティングされることを示します。

• 指定されたヘッダーを持つリクエストをカナリアバージョンにルーティングする

  次のコマンドを実行して、指定されたヘッダーを持つリクエストがカナリアバージョンにルーティングされるかどうかを確認します。

  XX.XX.XX.XXを、前の手順で取得したマルチクラスターゲートウェイのパブリックIPアドレスに置き換えます。

  for i in {1..50}; do curl -H "host: example.com" -H "app-web-demo-version: gray" xx.xx.xx.xx/service1; sleep 1;  done

  期待される出力: 出力は、app-web-demo-version: grayヘッダーを持つリクエストがクラスター2のカナリアバージョンにルーティングされることを示します。

• クラスター1がダウンしているときにトラフィックをクラスター2にルーティングする

  クラスター1のデプロイのレプリカ値が0に設定されている場合、次の結果が返されます。 出力は、トラフィックが自動的にクラスタ2にフェールオーバーされることを示します。