第5章 OpenShift Service Mesh の Argo Rollouts を使用したトラフィックのルーティング

Red Hat OpenShift GitOps の Argo Rollouts は、OpenShift Routes や Istio ベースの OpenShift Service Mesh などのさまざまなトラフィック管理メカニズムをサポートします。

Argo Rollouts で使用するトラフィックマネージャーの選択は、クラスターワークロードをデプロイするために使用している既存のトラフィック管理ソリューションによって異なります。たとえば、Red Hat OpenShift Routes は基本的なトラフィック管理機能を提供するため、サイドカーコンテナーを使用する必要はありません。ただし、Red Hat OpenShift Service Mesh は Istio を使用して、より高度なルーティング機能を提供しますが、サイドカーコンテナーの設定が必要です。

OpenShift Service Mesh を使用して、2 つのアプリケーションバージョン間でトラフィックを分割できます。

canary バージョン: トラフィックを段階的にルーティングするアプリケーションの新しいバージョン。
安定バージョン: アプリケーションの最新バージョン。canary バージョンが安定し、すべてのユーザートラフィックがそのバージョンに送信されるようになると、canary バージョンが新しい安定バージョンになります。以前の安定バージョンは破棄されます。

Argo Rollouts 内の Istio サポートは、ゲートウェイおよび VirtualService リソースを使用してトラフィックルーティングを処理します。

Gateway: ゲートウェイを使用して、メッシュの受信トラフィックと送信トラフィックを管理できます。ゲートウェイは OpenShift Service Mesh のエントリーポイントであり、アプリケーションに送信されるトラフィック要求を処理します。
VirtualService: VirtualService は、トラフィックルーティングルールと、stable サービスや canary サービスなどの基盤となるサービスに送信されるトラフィックの割合を定義します。

デプロイメントシナリオの例

たとえば、サンプルのデプロイメントシナリオでは、初期インスタンス中にトラフィックの 100% がアプリケーションの stable バージョンに送信されます。アプリケーションは想定どおりに実行されており、新規バージョンのデプロイは追加で試行されません。

ただし、アプリケーションの新しいバージョンをデプロイした後、Argo Rollouts はアプリケーションの新しいバージョンに基づいて新しい canary アデプロイメントを作成し、トラフィックの一部がその新しいバージョンにルーティングされます。

Service Mesh を使用すると、Argo Rollouts は VirtualService リソースを自動的に変更して、stable アプリケーションバージョンと canary アプリケーションバージョン間でトラフィック分割されたパーセンテージを制御します。以下の図では、トラフィックの 20% が最初のプロモーション後に canary アプリケーションバージョンに送信され、80% は stable サービスによって stable バージョンに送信されます。

stable バージョンのトラフィックの 80%、canary バージョンのトラフィックの 20%

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

次の項目を作成することで、OpenShift Service Mesh を使用して Argo Rollouts を設定できます。

ゲートウェイ
2 つの Kubernetes サービス: stable と canary。これらはサービスの各バージョン内の Pod を指します。
VirtualService
rollout カスタムリソース (CR)

以下の手順例では、ロールアウトによってトラフィックの 20% が canary バージョンにルーティングされます。手動プロモーションの後、ロールアウトによってトラフィックの 40% がルーティングされます。別の手動プロモーションの後、すべてのトラフィックが新しいアプリケーションバージョンにルーティングされるまで、ロールアウトは複数の自動プロモーションを実行します。

前提条件

管理者として OpenShift Container Platform クラスターにログインしている。
OpenShift Container Platform クラスターに Red Hat OpenShift GitOps がインストールされている。
OpenShift Container Platform クラスターに Argo Rollouts がインストールされている。
システムに Argo Rollouts CLI がインストールされている。
OpenShift Service Mesh Operator をクラスターにインストールし、ServiceMeshControlPlane を設定している。

手順

メッシュの受信トラフィックを受け入れる Gateway オブジェクトを作成します。
1. 次のスニペットコンテンツを含む YAML ファイルを作成します。
  rollouts-demo-gateway というサンプルゲートウェイ
```
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: rollouts-demo-gateway 1
spec:
  selector:
    istio: ingressgateway 2
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
```
  1
  ゲートウェイの名前
  2
  Ingress ゲートウェイの名前を指定します。このゲートウェイは、公開されるポートおよびプロトコルを設定しますが、これにはトラフィックルーティングの設定は含まれません。
2. 以下のコマンドを実行して、YAML ファイルを適用します。
```
$ oc apply -f gateway.yaml
```
アプリケーションの canary および stable バージョンのサービスを作成します。
1. Web コンソールの Administrator パースペクティブで、Networking Services に移動します。
2. Create Service をクリックします。
3. Create Service ページで、YAML view をクリックし、以下のスニペットを追加します。次の例では、rollouts-demo-stable という安定したサービスを作成します。安定したトラフィックがこのサービスに送られます。
```
apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo-stable
spec:
  ports: 1
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector: 2
    app: rollouts-demo
```
  1
  コンテナー内で実行するためにアプリケーションが使用するポートの名前を指定します。
  2
  selector フィールドの内容が stable サービスと Rollout CR で同じであることを確認します。
4. Create をクリックして stable サービスを作成します。
5. Create Service ページで、YAML view をクリックし、以下のスニペットを追加します。以下の例では、rollouts-demo-canary という canary サービスを作成します。canary トラフィックはこのサービスに転送されます。
```
apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo-canary
spec:
  ports: 1
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector: 2
    app: rollouts-demo
```
  1
  コンテナー内で実行するためにアプリケーションが使用するポートの名前を指定します。
  2
  selector フィールドの内容が canary サービスと Rollout CR と同じであることを確認します。
6. Create をクリックして canary サービスを作成します。

着信トラフィックを stable サービスと canary サービスにルーティングするための VirtualService を作成します。

YAML ファイルを作成し、以下の YAML をこれにコピーします。以下の例では、rollouts-demo-vsvc という名前の VirtualService を作成します。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: rollouts-demo-vsvc
spec:
  gateways:
  - rollouts-demo-gateway 1
  hosts:
  - rollouts-demo-vsvc.local
  http:
  - name: primary
    route:
    - destination:
        host: rollouts-demo-stable 2
        port:
          number: 15372 3
      weight: 100
    - destination:
        host: rollouts-demo-canary 4
        port:
          number: 15372
      weight: 0
  tls: 5
  - match:
    - port: 3000
      sniHosts:
      - rollouts-demo-vsvc.local
    route:
    - destination:
        host: rollouts-demo-stable
      weight: 100
    - destination:
        host: rollouts-demo-canary
      weight: 0

1: ゲートウェイの名前
2: 対象となる安定したサービスの名前。
3: トラフィックをリッスンするために使用されるポート番号を指定します。
4: 対象となる canary サービスの名前。
5: VirtualService を保護するために使用される TLS 設定を指定します。

以下のコマンドを実行して、YAML ファイルを適用します。
```
$ oc apply -f virtual-service.yaml
```

Rollout CR を作成します。この例では、Istio がトラフィックマネージャーとして使用されます。
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:
  replicas: 5
  strategy:
    canary:
      canaryService: rollouts-demo-canary 1
      stableService: rollouts-demo-stable 2
      trafficRouting:
        istio:
          virtualServices:
          - name: rollouts-demo-vsvc
            routes:
            - primary
      steps: 3
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {}
      - setWeight: 60
      - pause: {duration: 30}
      - setWeight: 80
      - pause: {duration: 60}
  revisionHistoryLimit: 2
  selector: 4
    matchLabels:
      app: rollouts-demo
  template:
    metadata:
      labels:
        app: rollouts-demo
        istio-injection: enabled
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        resources:
          requests:
            memory: 32Mi
            cpu: 5m
```
  1
  この値は、作成された canary Service の名前に一致する必要があります。
  2
  この値は、作成された stable Service の名前と一致する必要があります。
  3
  ロールアウトの手順を指定します。この例では、トラフィックの 20%、40%、60%、100% を段階的に canary バージョンにルーティングします。
  4
  selector フィールドの内容が、canary サービスおよび stable サービスと同じであることを確認します。
3. Create をクリックします。
4. Rollout タブの Rollout セクションで、ロールアウトの Status フィールドに Phase: Healthy と表示されていることを確認します。
ルートがトラフィックの 100% をアプリケーションの安定バージョンに送信していることを確認します。
1. 次のコマンドを実行して、ロールアウトの進行状況を確認します。
```
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
```
  1
  Rollout リソースが定義されている namespace を指定します。
  出力例
```
Name:            rollouts-demo
Namespace:       argo-rollouts
Status:          ✔ Healthy
Strategy:        Canary
  Step:          8/8
  SetWeight:     100
  ActualWeight:  100
Images:          argoproj/rollouts-demo:blue (stable)
Replicas:
  Desired:       5
  Current:       5
  Updated:       5
  Ready:         5
  Available:     5

NAME                                       KIND        STATUS     AGE    INFO
⟳ rollouts-demo                            Rollout     ✔ Healthy  4m50s
└──# revision:1
   └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  4m50s  stable
      ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  4m49s  ready:1/1
      ├──□ rollouts-demo-687d76d795-bv5zf  Pod         ✔ Running  4m49s  ready:1/1
      ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  4m49s  ready:1/1
      ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  4m49s  ready:1/1
      └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  4m49s  ready:1/1
```
  注記
  Rollout リソースの最初のインスタンスが作成されると、ロールアウトによって、stable バージョンおよび canary バージョンのアプリケーションに送信されるトラフィックの量が調整されます。最初のインスタンスでは、Rollout リソースの作成により、すべてのトラフィックがアプリケーションの stable バージョンにルーティングされ、トラフィックが canary バージョンに送信される部分がスキップされます。
2. サービスメッシュが stable サービスに対してトラフィックの 100% を送信し、canary サービスに対して 0% を送信していることを確認するには、次のコマンドを実行します。
```
$ oc describe virtualservice/rollouts-demo-vsvc -n <namespace>
```
3. ターミナルに表示される以下の出力を表示します。
```
route
- destination:
    host: rollouts-demo-stable
  weight: 100 1
- destination:
    host: rollouts-demo-canary
  weight: 0 2
```
  1
  値が 100 の場合、トラフィックの 100% が安定バージョンに送信されることを意味します。
  2
  値が 0 の場合は、トラフィックの 0% が canary バージョンに転送されることを意味します。
ロールアウトでデプロイされたコンテナーイメージを変更して、アプリケーションの新しい canary バージョンをシミュレートします。
1. 次のコマンドを実行して、.spec.template.spec.containers.image の値を argoproj/rollouts-demo:blue から argoproj/rollouts-demo:yellow に変更します。
```
$ oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow -n <namespace>
```
  その結果、ロールアウトにデプロイされたコンテナーイメージが変更され、ロールアウトによって新規の canary デプロイメントが開始されます。
  注記
  Rollout リソースの .spec.strategy.canary.steps フィールドで定義されている setWeight プロパティーに従って、最初はルートへのトラフィックの 20% が canary バージョンに到達し、トラフィックの 80% が stable バージョンに向けられます。トラフィックの 20% が canary バージョンに転送されると、ロールアウトは一時停止されます。
2. 次のコマンドを実行して、ロールアウトの進行状況を確認します。
```
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
```
  1
  Rollout リソースが定義されている namespace を指定します。
  次の例では、トラフィックの 80% が stable サービスにルーティングされ、トラフィックの 20% が canary サービスにルーティングされます。手動で次のレベルにプロモートするまで、デプロイメントは無期限に一時停止されます。
  出力例
```
Name:            rollouts-demo
Namespace:       argo-rollouts
Status:          ॥ Paused
Message:         CanaryPauseStep
Strategy:        Canary
  Step:          1/8
  SetWeight:     20
  ActualWeight:  20
Images:          argoproj/rollouts-demo:blue (stable)
                 argoproj/rollouts-demo:yellow (canary)
Replicas:
  Desired:       5
  Current:       6
  Updated:       1
  Ready:         6
  Available:     6

NAME                                       KIND        STATUS     AGE    INFO
⟳ rollouts-demo                            Rollout     ॥ Paused   6m51s
├──# revision:2
│  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy  99s    canary
│     └──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running  98s    ready:1/1
└──# revision:1
   └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  9m51s  stable
      ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  9m50s  ready:1/1
      ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  9m50s  ready:1/1
      ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  9m50s  ready:1/1
      └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  9m50s  ready:1/1
```
  トラフィックの 80% が canary バージョンに送られ、20% が stable バージョンに送られるルートの例。
```
route
- destination:
    host: rollouts-demo-stable
  weight: 80 1
- destination:
    host: rollouts-demo-canary
  weight: 20 2
```
  1
  値が 80 の場合、トラフィックの 80% が stable バージョンに送信されることを意味します。
  2
  値が 20 の場合は、トラフィックの 20% が canary バージョンに転送されることを意味します。

デプロイメントを手動で次のプロモート手順にプロモートします。

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

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

次のコマンドを実行して、ロールアウトの進行状況を確認します。

$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

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

次の例では、トラフィックの 60% が stable サービスにルーティングされ、トラフィックの 40% が canary サービスにルーティングされます。手動で次のレベルにプロモートするまで、デプロイメントは無期限に一時停止されます。

出力例

Name:            rollouts-demo
Namespace:       argo-rollouts
Status:          ॥ Paused
Message:         CanaryPauseStep
Strategy:        Canary
  Step:          3/8
  SetWeight:     40
  ActualWeight:  40
Images:          argoproj/rollouts-demo:blue (stable)
                 argoproj/rollouts-demo:yellow (canary)
Replicas:
  Desired:       5
  Current:       7
  Updated:       2
  Ready:         7
  Available:     7

NAME                                       KIND        STATUS     AGE    INFO
⟳ rollouts-demo                            Rollout     ॥ Paused   9m21s
├──# revision:2
│  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy  99s    canary
│     └──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running  98s    ready:1/1
└──# revision:1
   └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  9m51s  stable
      ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  9m50s  ready:1/1
      ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  9m50s  ready:1/1
      ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  9m50s  ready:1/1
      └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  9m50s  ready:1/1

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

route
- destination:
    host: rollouts-demo-stable
  weight: 60 1
- destination:
    host: rollouts-demo-canary
  weight: 40 2

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

次のコマンドを実行して、canary バージョンのトラフィックの重みを 100% に増やし、アプリケーションの以前の stable バージョンのトラフィックを破棄します。
```
$ oc argo rollouts promote rollouts-demo -n <namespace> 1
```
1
Rollout リソースが定義されている namespace を指定します。
1. 次のコマンドを実行して、ロールアウトの進行状況を確認します。
```
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
```
  1
  Rollout リソースが定義されている namespace を指定します。

正常に完了すると、stable サービスに対する重みは 100%、canary サービスに対する重みは 0% になります。

第5章 OpenShift Service Mesh の Argo Rollouts を使用したトラフィックのルーティング

デプロイメントシナリオの例

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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links