4.2. OpenShift Routes を使用してトラフィックをルーティングするように Argo Rollouts を設定する

手順

1. Route オブジェクトを作成します。

   1. Web コンソールの Administrator パースペクティブで、Networking Routes をクリックします。
   2. Create Route をクリックします。

   3. Create Route ページで、YAML view をクリックし、以下のスニペットを追加します。以下の例では、rollouts-demo-route というルートを作成します。

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: rollouts-demo-route
      spec:
        port:
          targetPort: http 1
        tls: 2
          insecureEdgeTerminationPolicy: Redirect
          termination: edge
        to:
          kind: Service
          name: argo-rollouts-stable-service 3
          weight: 100 4
      
        alternateBackends:
          - kind: Service
            name: argo-rollouts-canary-service 5
            weight: 0 6

      1

      コンテナー内で実行するためにアプリケーションが使用するポートの名前を指定します。

      2

      ルートを保護するために使用される TLS 設定を指定します。

      3

      対象となる安定したサービスの名前。

      4

      このフィールドは、Route Rollout プラグインによって安定した重みに自動的に変更されます。

      5

      対象となる canary サービスの名前。

      6

      このフィールドは、Route Rollout プラグインにより、canary の重みに自動的に変更されます。

   4. Create をクリックしてルートを作成します。その後、Routes ページに表示されます。

2. ルートで参照されるサービス (canary および stable) を作成します。

   1. Web コンソールの Administrator パースペクティブで、Networking Services をクリックします。
   2. Create Service をクリックします。

   3. Create Service ページで、YAML view をクリックし、以下のスニペットを追加します。以下の例では、argo-rollouts-canary-service という名前の canary サービスを作成します。canary トラフィックはこのサービスに転送されます。

      apiVersion: v1
      kind: Service
      metadata:
        name: argo-rollouts-canary-service
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
      
        selector: 2
          app: rollouts-demo

      1

      コンテナー内で実行するためにアプリケーションが使用するポートの名前を指定します。

      2

      selector フィールドの内容が、安定したサービスおよび Rollout カスタムリソース (CR) と同じであることを確認します。

      重要

      Route オブジェクトで指定された canary サービスの名前が、Service オブジェクトで指定された canary サービスの名前と一致していることを確認します。

   4. Create をクリックして canary サービスを作成します。

      ロールアウトは、作成されたサービスを canary ReplicaSet の Pod テンプレートハッシュで自動的に更新します。例: rollouts-pod-template-hash: 7bf84f9696。

   5. これらの手順を繰り返して安定したサービスを作成します。次の例では argo-rollouts-stable-service という安定したサービスを作成します。安定したトラフィックがこのサービスに送られます。

      apiVersion: v1
      kind: Service
      metadata:
        name: argo-rollouts-stable-service
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
      
        selector: 2
          app: rollouts-demo

      1

      コンテナー内で実行するためにアプリケーションが使用するポートの名前を指定します。

      2

      selector フィールドの内容が canary サービスと Rollout CR と同じであることを確認します。

      重要

      Route オブジェクトで指定された安定したサービスの名前が、Service オブジェクトで指定された安定したサービスの名前と一致していることを確認します。

   6. Create をクリックして安定したサービスを作成します。

      ロールアウトは、安定した ReplicaSet の Pod テンプレートハッシュを使用して、作成されたサービスを自動的に更新します。例: rollouts-pod-template-hash: 1b6a7733。

3. Route および Service オブジェクトを参照する Rollout CR を作成します。

   1. Web コンソールの Administrator パースペクティブで、Operator Installed Operator Red Hat OpenShift GitOps Rollout に移動します。

   2. Create Rollout ページで、YAML view をクリックし、次のスニペットを追加します。次の例では、rollouts-demo という Rollout CR を作成します。

      apiVersion: argoproj.io/v1alpha1
      kind: Rollout
      metadata:
        name: rollouts-demo
      spec:
        template: 1
          metadata:
            labels:
              app: rollouts-demo
          spec:
            containers:
            - name: rollouts-demo
              image: argoproj/rollouts-demo:blue
              ports:
              - name: http
                containerPort: 8080
                protocol: TCP
              resources:
                requests:
                  memory: 32Mi
                  cpu: 5m
      
        revisionHistoryLimit: 2
        replicas: 5
        strategy:
          canary:
            canaryService: argo-rollouts-canary-service 2
            stableService: argo-rollouts-stable-service 3
            trafficRouting:
              plugins:
                argoproj-labs/openshift:
                  routes:
                    - rollouts-demo-route  4
            steps: 5
            - setWeight: 30
            - pause: {}
            - setWeight: 60
            - pause: {}
        selector: 6
          matchLabels:
            app: rollouts-demo

      1

      作成する Pod を指定します。

      2

      この値は、作成された canary Service の名前に一致する必要があります。

      3

      この値は、作成された stable Service の名前と一致する必要があります。

      4

      この値は、作成された Route CR の名前に一致する必要があります。

      5

      ロールアウトの手順を指定します。この例では、トラフィックの 30%、60%、100% を段階的に canary バージョンにルーティングします。

      6

      selector フィールドの内容が、canary サービスおよび stable サービスと同じであることを確認します。

   3. Create をクリックします。
   4. Rollout タブの Rollout セクションで、ロールアウトの Status フィールドに Phase: Healthy と表示されていることを確認します。

4. ルートがトラフィックの 100% をアプリケーションの安定バージョンに送信していることを確認します。

   注記

   Rollout リソースの最初のインスタンスが作成されると、ロールアウトによって、stable バージョンおよび canary バージョンのアプリケーションに送信されるトラフィックの量が調整されます。最初のインスタンスでは、Rollout リソースの作成により、すべてのトラフィックがアプリケーションの stable バージョンにルーティングされ、トラフィックが canary バージョンに送信される部分がスキップされます。

   1. Networking Routes に移動し、検証する Route リソースを探します。

   2. YAML タブを選択し、以下のスニペットを表示します。

      例: Route

      kind: Route
      metadata:
        name: rollouts-demo-route
      spec:
        alternateBackends:
        - kind: Service
          name: argo-rollouts-canary-service
          weight: 0 1
        # (...)
        to:
          kind: Service
          name: argo-rollouts-stable-service
          weight: 100 2

      1

      値が 0 の場合は、トラフィックの 0% が canary バージョンに転送されることを意味します。

      2

      値が 100 の場合、トラフィックの 100% が安定バージョンに送信されることを意味します。

5. ロールアウトでデプロイされたコンテナーイメージを変更して、アプリケーションの新しい canary バージョンをシミュレートします。

   1. Web コンソールの Administrator パースペクティブで、Operator Installed Operator Red Hat OpenShift GitOps Rollout に移動します。

   2. 既存の Rollout を選択し、.spec.template.spec.containers.image の値を argoproj/rollouts-demo:blue から argoproj/rollouts-demo:yellow に変更します。

      その結果、ロールアウトにデプロイされたコンテナーイメージが変更され、ロールアウトによって新規の canary デプロイメントが開始されます。

      注記

      Rollout リソースの .spec.strategy.canary.steps フィールドで定義されている setWeight プロパティーに従って、最初はルートへのトラフィックの 30% が canary バージョンに到達し、トラフィックの 70% が stable バージョンに向けられます。トラフィックの 30% が canary バージョンに移行されると、ロールアウトは一時停止されます。

      トラフィックの 30% が canary バージョンに送られ、70% が stable バージョンに送られるルートの例。

      spec:
        alternateBackends:
        - kind: Service
          name: argo-rollouts-canary-service
          weight: 30
        # (...)
        to:
          kind: Service
          name: argo-rollouts-stable-service
          weight: 70

6. Argo Rollouts CLI で次のコマンドを実行して、アプリケーションの別の canary バージョンを新たにシミュレートします。

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Rollout リソースが定義されている namespace を指定します。

   これにより、トラフィックの重みは、canary バージョンでは 60%、stable バージョンでは 40% に増加します。

   トラフィックの 60% が canary バージョンに送られ、40% が stable バージョンに送られるルートの例。

   spec:
     alternateBackends:
     - kind: Service
       name: argo-rollouts-canary-service
       weight: 60
     # (...)
     to:
       kind: Service
       name: argo-rollouts-stable-service
       weight: 40

7. 次のコマンドを実行して、canary バージョンのトラフィックの重みを 100% に増やし、アプリケーションの古い stable バージョンのトラフィックを破棄します。

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Rollout リソースが定義されている namespace を指定します。

   トラフィックの 0% が canary バージョンに送られ、100% が stable バージョンに送られるルートの例。

   spec:
     # (...)
     to:
       kind: Service
       name: argo-rollouts-stable-service
       weight: 100