Argo Rolloutsを使用して段階的なアプリケーションリリースを実装する

Argo Rollouts は、Kubernetes Operator 実装であり、ブルーグリーン、カナリア、カナリア分析、実験、プログレッシブ配信機能など、Kubernetes のより高度なデプロイメント機能を提供し、クラウドネイティブのアプリケーションとサービスに対して自動化された GitOps ベースのプログレッシブ配信を可能にします。

次の機能がサポートされています:

ブルーグリーンアップデート戦略
カナリアアップデート戦略
より細かく重み付けされたトラフィック分割
自動ロールバック
手動判断
カスタマイズ可能な指標クエリとビジネスKPI分析
イングレスコントローラの統合: NGINX、ALB
サービスメッシュ統合: Istio、Linkerd、SMI
メトリクス統合: Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs、Datadog、New Relic、Graphite、InfluxDB

実施原則

Deployment オブジェクトと同様に、Argo Rollouts コントローラーは、Deployment オブジェクトと同じポッドテンプレートを使用して、Rollout リソースの spec.template で定義された ReplicaSets の作成、スケーリング、および削除を管理します。

spec.template が変更されると、新しい ReplicaSet が導入されていることが Argo Rollouts コントローラーに通知されます。コントローラーは、spec.strategy フィールドの戦略を使用して、古い ReplicaSet から新しい ReplicaSet へのロールアウトをどのように進めるかを決定します。この新しいレプリカセットがスケールアップされると (オプションで分析経由)、コントローラーはそれを安定しているとマークします。

安定した ReplicaSet から新しい ReplicaSet への spec.template 遷移で別の変更が発生した場合 (つまり、リリース中にアプリケーションのバージョンが変更された場合)、以前の新しい ReplicaSet はスケールダウンされ、コントローラーは更新された spec.template フィールドを反映した ReplicasSet をリリースしようとします。

建築

以下は、Argo Rollouts によって管理されるデプロイメントのすべてのコンポーネントを示しています。

Argoロールアウトアーキテクチャ

ロールアウトコントローラ

これは、クラスターのイベントを監視し、ロールアウトタイプのリソースが変更されたときに反応するメインコントローラーです。コントローラーはロールアウトのすべての詳細を読み取り、クラスターをロールアウト定義で説明されているのと同じ状態にします。

Argo Rollouts は、通常のデプロイメントリソースに加えられた変更を改ざんしたり、それに応答したりしないことに注意してください。つまり、他の方法を使用してアプリケーションをデプロイするクラスターに Argo Rollouts をインストールできます。

ロールアウトリソース

Rollout リソースは、Argo Rollouts によって導入および管理されるカスタム Kubernetes リソースです。基本的にはネイティブの Kubernetes Deployment リソースと互換性がありますが、カナリアやブルー/グリーンデプロイメントなどのより高度なデプロイメント方法を制御するための追加フィールドがあります。

Argo Rollouts コントローラーは、Rollout リソースの変更にのみ反応し、通常の Deployment リソースに対しては何も行いません。そのため、Argo Rollouts を使用して Deployment を管理する場合は、Deployment を Rollouts に移行する必要があります。

分析テンプレートと分析実行

分析は、ロールアウトをメトリックプロバイダーに接続し、ロールアウトが成功したかどうかを判断する特定のメトリックの特定のしきい値を定義するカスタム Kubernetes リソースです。分析ごとに、1 つ以上のインジケータークエリとその予想される結果を定義できます。インジケータークエリが正常であれば、Rollout は公開を続行します。インジケータが失敗を示した場合、自動的にロールバックされます。インジケータが成功/失敗の結果を提供できない場合、リリースは中断されます。

分析を実行するために、Argo Rollouts は AnalysisTemplate と AnalysisRun という 2 つのカスタム Kubernetes リソースを提供します。

AnalysisTemplate には、クエリするメトリックに関する指示が含まれています。ロールアウトに添付された実際の結果は、特定のロールアウト上の AnalysisTemplate またはクラスター上のグローバル AnalysisTemplate を定義して複数のロールアウトで ClusterAnalysisTemplate として共有できる AnalysisRun カスタムリソースですが、AnalysisRun リソースのスコープは特定のロールアウトに限定されます。

Rollout での分析とメトリックの使用は完全にオプションであり、API または CLI を介して手動でリリースを一時停止および再開したり、他の外部メソッド (スモークテストなど) を使用したりできます。 Argo ロールアウトにはインジケーターソリューションのみを使用する必要はなく、ロールアウトで自動 (分析ベース) のステップと手動のステップを組み合わせることもできます。

メトリックに加えて、Kubernetes ジョブを実行したり、Webhook を実行したりして、リリースの成功を判断することもできます。

メトリックプロバイダー

Argo Rollouts には、分析リソースで使用してデプロイメントを自動的にアップグレードまたはロールバックできる、いくつかの一般的なメトリックプロバイダーのネイティブ統合が含まれています。具体的な設定オプションについては、各プロバイダーのドキュメントを参照してください。

Argo Rollouts には、分析リソースで使用してリリースを自動的にアップグレードまたはロールバックできる、いくつかの一般的なメトリクスプロバイダーとの統合が含まれています。

インストール

次のコマンドを使用して Argo Rollouts をインストールするだけです。

 $ kubectl create namespace argo-rollouts $ kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/download/v1.6.0/install.yaml

これにより、Argo Rollouts コントローラーが実行される argo-rollouts という名前空間が作成されます。

 $ kubectl get pods -n argo-rollouts NAME READY STATUS RESTARTS AGE argo-rollouts-b9bbbc884-5h5jz 1/1 Running 0 7m21s $ kubectl get crd |grep argo analysisruns.argoproj.io 2023-09-21T06:20:34Z analysistemplates.argoproj.io 2023-09-21T06:20:34Z clusteranalysistemplates.argoproj.io 2023-09-21T06:20:34Z experiments.argoproj.io 2023-09-21T06:20:35Z rollouts.argoproj.io 2023-09-21T06:20:35Z

さらに、コマンドライン管理とビジュアルリリースに非常に便利な kubectl プラグインをインストールすることもできます。 curl を使用して Argo Rollouts kubectl プラグインをインストールします。

 # https://ghproxy.com/https://github.com//argoproj/argo-rollouts/releases/download/v1.6.0/kubectl-argo-rollouts-linux-amd64 $ curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.6.0/kubectl-argo-rollouts-linux-amd64

次に、kubectl-argo-rollouts バイナリ実行権限を付与します。

 $ chmod +x ./kubectl-argo-rollouts-linux-amd64

バイナリを PATH に移動します。

 $ sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

プラグインが正常にインストールされたことを確認するには、次のコマンドを実行します。

 $ kubectl argo rollouts version kubectl-argo-rollouts: v1.6.0+7eae71e BuildDate: 2023-09-06T18:36:42Z GitCommit: 7eae71ed89f1a3769864435bddebe3ca05384df3 GitTreeState: clean GoVersion: go1.20.7 Compiler: gc Platform: linux/amd64

カナリアリリース

次に、いくつかの簡単な例を使用して、Rollout の展開、アップグレード、リリース、中断を説明し、Rollout のさまざまな機能を紹介します。

1. ロールアウトを展開する

まず、ロールアウトリソースとリソース用の Kubernetes サービスオブジェクトをデプロイします。この例のロールアウトでは、カナリア更新戦略を採用し、トラフィックの 20% をカナリアに送信し、その後手動で解放し、最後にアップグレードの残りの時間中にトラフィックを徐々に自動的に増加させます。この戦略は、次のロールアウトで説明できます。

 # basic-rollout.yaml apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: replicas: 5 # 定义5个副本strategy: # 定义升级策略canary: # 金丝雀发布steps: # 发布的节奏- setWeight: 20 - pause: {} # 会一直暂停- setWeight: 40 - pause: { duration: 10 } # 暂停10s - setWeight: 60 - pause: { duration: 10 } - setWeight: 80 - pause: { duration: 10 } revisionHistoryLimit: 2 # 下面部分其实是和Deployment 兼容的selector: matchLabels: app: rollouts-demo template: 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

以下に示すように、サービスリソースオブジェクトも含まれます。

 # basic-service.yaml apiVersion: v1 kind: Service metadata: name: rollouts-demo spec: ports: - port: 80 targetPort: http protocol: TCP name: http selector: app: rollouts-demo

上記の 2 つのリソースオブジェクトを直接作成します。

 $ kubectl apply -f basic-rollout.yaml $ kubectl apply -f basic-service.yaml

ロールアウトの最初の作成では、アップグレードがまだ行われていないため、レプリカがすぐに 100% にスケーリングされます (カナリアアップグレードの手順、分析などはスキップされます)。

 $ kubectl get pods -l app=rollouts-demo NAME READY STATUS RESTARTS AGE rollouts-demo-687d76d795-7xztq 1/1 Running 0 4m48s rollouts-demo-687d76d795-bnnwx 1/1 Running 0 4m48s rollouts-demo-687d76d795-dtlns 1/1 Running 0 4m48s rollouts-demo-687d76d795-q6867 1/1 Running 0 4m48s rollouts-demo-687d76d795-zlzdv 1/1 Running 0 4m48s

Argo Rollouts kubectl プラグインを使用すると、Rollout と関連リソースオブジェクトを視覚化し、リアルタイムのステータスの変化を表示できます。デプロイメントプロセス中にロールアウトを監視するには、プラグインの get rollout --watch コマンドを実行します。次に例を示します。

 $ kubectl argo rollouts get rollout rollouts-demo --watch

ロールアウトを見る

2. アップデートのロールアウト

展開が完了しました。次に、更新する必要があります。デプロイメントと同様に、Pod テンプレートフィールドに変更を加えると、新しいバージョン (ReplicaSet) がデプロイされます。ロールアウトを更新するには、通常、コンテナイメージのバージョンを変更してから、 kubectl apply を実行する必要があります。利便性のために、ロールアウトプラグインは別の set image コマンドも提供します。たとえば、ここでは次のコマンドを実行して、上記のロールアウトをコンテナの黄色バージョンで更新します。

 $ kubectl argo rollouts set image rollouts-demo \ rollouts-demo=argoproj/rollouts-demo:yellow rollout "rollouts-demo" image updated

ロールアウト更新中、コントローラはロールアウト更新戦略で定義された手順を実行します。この例のロールアウトでは、カナリアに 20% のトラフィックウェイトを設定し、ユーザーがリリースをキャンセルまたは促進するまでロールアウトを一時停止します。画像を更新した後、一時停止状態になるまでロールアウトを再度確認します。

 $ kubectl argo rollouts get rollout rollouts-demo --watch

ロールアウトを見る

デモロールアウトが 2 番目のステップに到達すると、ロールアウトが一時停止され、5 つのレプリカのうち 1 つがポッドの新しいバージョンを実行しているのに対し、残りの 4 つは古いバージョンをまだ実行していることがプラグインからわかります。これは、setWeight: 20 ステップで定義された 20% のカナリアウェイトに相当します。

3. ロールアウトを促進する

上記の更新後、ロールアウトは一時停止状態になり、ロールアウトが期間のない一時停止ステップに達すると、再開/継続されるまで一時停止状態のままになります。ロールアウトを手動で次のステップに切り替えるには、プラグインの promotion 注文。

 $ kubectl argo rollouts promote rollouts-demo rollout 'rollouts-demo' promoted

切り替え後、Rollout は残りの手順を引き続き実行します。私たちの場合、残りの手順は完全に自動化されているため、Rollout は最終的に新しいバージョンに完全に移行するまで手順を完了します。すべてのステップが完了するまで、ロールアウトを再度監視します。

 $ kubectl argo rollouts get rollout rollouts-demo --watch

ロールアウトを見る

prove コマンドは、残りのすべてのステップと分析をスキップする --full フラグもサポートしています。

安定バージョンが ReplicaSet リビジョン:2 に切り替わったことがわかります。カナリア分析の失敗によって自動的に、またはユーザーによって手動で更新が中止された場合、Rollout は安定バージョンにフォールバックします。

4. 割り込みロールアウト

次に、更新中にロールアウトを手動で中止する方法を見てみましょう。まず、set image コマンドを使用してコンテナの新しい red バージョンをデプロイし、ロールアウトが再び一時停止ステップに到達するまで待機します。

 $ kubectl argo rollouts set image rollouts-demo \ rollouts-demo=argoproj/rollouts-demo:red rollout "rollouts-demo" image updated

今回は、ロールアウトを次のステップに切り替えるのではなく、更新を中止して安定バージョンに戻します。プラグインには、更新プロセス中にいつでもロールアウトを手動で中止するための中止コマンドも用意されています。

 $ kubectl argo rollouts abort rollouts-demo

ロールが中止されると、レプリカセットの安定バージョン (この場合は黄色のバージョン) がスケールアップされ、他のバージョンはスケールダウンされます。レプリカセットの安定バージョンが実行中で正常であっても、期待されるバージョン (赤色のバージョン) が実際に実行されているバージョンではないため、ロールアウト全体は依然として劣化していると見なされます。

ロールアウトを見る

Rollout が壊れたバージョンではなく再び正常なバージョンと見なされるためには、目的の状態を以前の安定したバージョンに戻す必要があります。この場合は、以前の黄色のイメージを使用して、set image コマンドを再実行するだけです。

 $ kubectl argo rollouts set image rollouts-demo \ rollouts-demo=argoproj/rollouts-demo:yellow

このコマンドを実行すると、ロールアウトがすぐに正常になり、新しいレプリカセットを作成するアクティビティがないことがわかります。

ロールアウトを見る

ロールアウトがまだ期待された状態に達していない場合 (中止された、または更新中の場合など)、リソースマニフェストの安定したバージョンが再適用されると、ロールアウトはこれが更新ではなくロールバックであることを検出し、分析と手順をスキップして安定したレプリカセットを迅速にデプロイします。

Argo ロールアウトと NGINX Ingress 統合

上記の例のロールアウトでは、トラフィックを制御するために Ingress コントローラまたはサービスメッシュは使用されません。 Kubernetes Service を使用して、新しいレプリカと古いレプリカの数の比率に基づいて、おおよそのカナリアウェイトを実装します。したがって、このロールアウトには制限があります。よりきめ細かいカナリアを実装するには、Ingress コントローラーまたはサービスメッシュが必要です。

次に、Argo Rollouts がトラフィック制御のために NGINX Ingress Controller とどのように統合されるかについて説明します。

もちろん、最初に ingress-nginx コントローラーがクラスターにインストールされていることを確認してください。 NGINX Ingress をトラフィックルーターとして使用する場合、Rollout Canary ポリシーで次の必須フィールドを定義する必要があります。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: strategy: canary: # 引用一个Service，控制器将更新该服务以指向金丝雀ReplicaSet canaryService: rollouts-demo-canary # 引用一个Service，控制器将更新该服务以指向稳定的ReplicaSet stableService: rollouts-demo-stable trafficRouting: nginx: # 指向稳定Service 的规则所引用的Ingress # 该Ingress 将被克隆并赋予一个新的名称，以实现NGINX流量分割。 stableIngress: rollouts-demo-stable

canary.trafficRouting.nginx.stableIngress で参照される Ingress には、canary.stableService で参照されるサービスをターゲットとするバックエンドを持つホストルールが必要です。

次に、上記の説明に従って、例のリソースマニフェストファイルを定義します。

 # rollout.yaml apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: replicas: 1 strategy: canary: canaryService: rollouts-demo-canary stableService: rollouts-demo-stable trafficRouting: nginx: stableIngress: rollouts-demo-stable steps: - setWeight: 5 - pause: {} revisionHistoryLimit: 2 selector: matchLabels: app: rollouts-demo template: 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

上記のリソースリストでは、rollouts-demo という Rollout リソースを定義します。 canaryService と stableService はそれぞれ 2 つの Service リソースを参照します。 StableIngress は Ingress リソースを指します。ステップは、カナリアリリースの手順を定義します。ここでは 2 つのステップを定義します。最初のステップでは重みを 5% に設定し、2 番目のステップでは一時停止します。この方法では、最初のステップでトラフィックの 5% をカナリアに送信し、その後手動で解放することができます。最後に、アップグレードの残り時間中にトラフィックが自動的に徐々に増加します。対応するサービスリソースオブジェクトは次のとおりです。

 # service.yaml apiVersion: v1 kind: Service metadata: name: rollouts-demo-canary spec: ports: - port: 80 targetPort: http protocol: TCP name: http selector: app: rollouts-demo # 该selector 将使用金丝雀ReplicaSet 的pod-template-hash 进行更新，比如rollouts-pod-template-hash: 7bf84f9696 --- apiVersion: v1 kind: Service metadata: name: rollouts-demo-stable spec: ports: - port: 80 targetPort: http protocol: TCP name: http selector: app: rollouts-demo # 该selector 将使用稳定版的ReplicaSet 的pod-template-hash 进行更新，比如rollouts-pod-template-hash: 789746c88d

最後に、Ingress オブジェクトを定義する必要があります。

 # ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rollouts-demo-stable spec: ingressClassName: nginx rules: - host: rollouts-demo.local http: paths: - path: / pathType: Prefix backend: service: # 引用服务名称，也在Rollout spec.strategy.canary.stableService 字段中指定name: rollouts-demo-stable port: number: 80

次に、前の例のリソースオブジェクトを削除します。

 $ kubectl delete -f basic-rollout.yaml $ kubectl delete -f basic-service.yaml

次に、上記のリソースオブジェクトを作成します。

 $ kubectl apply -f rollout.yaml $ kubectl apply -f service.yaml $ kubectl apply -f ingress.yaml

マニフェストを適用すると、クラスター内に次のリソースオブジェクトが表示されます。

 $ kubectl get ro NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE rollouts-demo 1 1 1 1 69s $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rollouts-demo-canary ClusterIP 10.111.85.229 <none> 80/TCP 72s rollouts-demo-stable ClusterIP 10.110.107.123 <none> 80/TCP 72s $ kubectl get ing NAME CLASS HOSTS ADDRESS PORTS AGE rollouts-demo-rollouts-demo-stable-canary nginx rollouts-demo.local 80 41s rollouts-demo-stable nginx rollouts-demo.local 80 41s

rollouts-demo-rollouts-demo-stable-canary という名前の新しい Ingress オブジェクトが追加されたことがわかります。このオブジェクトはカナリアイングレスであり、nginx.stableIngress で参照されるユーザー管理の Ingress のクローンです。 nginx イングレスコントローラはこれを使用して、カナリアトラフィック分割を実装します。生成された Ingress の名前は、<ROLLOUT-NAME>-<INGRESS-NAME>-canary を使用して作成されます。

ここで、ロールアウトオブジェクトの特定のステータスも表示できます。

ロールアウト

次に、イメージのバージョンを変更してリリースを更新し、一時停止状態になるまで待機します。

 $ kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow kubectl argo rollouts get rollout rollouts-demo

ロールアウトの一時停止

この時点では、Rollout のカナリアバージョンと安定バージョンの両方が実行されており、トラフィックの 5% がカナリアバージョンにルーティングされています。注目すべき点は、2 つのポッドのみを実行しているにもかかわらず、このリリースでは 5% のカナリアウェイトを達成できたことです。これは、トラフィックの分割が Ingress コントローラで行われるため可能になります。

デモにアクセスして、次の概要を把握できます。

ロールアウトデモ

ロールアウトコントローラーによって生成された Ingress コピーを調べたところ、元の Ingress から次の変更が加えられていることがわかりました。

注釈に、NGINX 固有のカナリア注釈が 2 つ追加されました。
Ingress ルールには、バックエンドをカナリアサービスにポイントするルールが含まれます。

対応するリソースリストは次のとおりです。

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "5" name: rollouts-demo-rollouts-demo-stable-canary namespace: default spec: ingressClassName: nginx rules: - host: rollouts-demo.local http: paths: - backend: service: name: rollouts-demo-canary port: number: 80 path: / pathType: Prefix

ロールアウトがステップを進むにつれて、canary-weight アノテーションはステップの現在の setWeight と一致するように調整されます。 NGINX Ingress コントローラーは、元の Ingress、カナリア Ingress、カナリアの重み付けアノテーションを調べて、2 つの Ingress 間で分散するトラフィックの割合を決定します。 NGINX Ingress がカナリアトラフィック分割を実装する方法については、NGINX Ingress セクションですでに詳しく説明しました。

最後に、promote コマンドを実行してロールアウトを次のステップに進め、カナリアリリースを完了します。

 $ kubectl argo rollouts promote rollouts-demo rollout 'rollouts-demo' promoted

もちろん、この時点ですべてのアプリケーションはコンテナーの黄色バージョンに切り替わります。

ロールアウトデモ

ダッシュボード

Argo Rollouts Kubectl プラグインは、ロールアウトを視覚化するためのローカルダッシュボードを提供します。

ダッシュボードを起動するには、Rollouts リソースオブジェクトを含む名前空間で kubectl argo rollouts dashboard コマンドを実行し、localhost:3100 にアクセスします。

argo ロールアウト ui

「ロールアウト」をクリックすると詳細ページに移動し、ロールアウトの構成情報を確認したり、再起動、リブート、中断などの一般的な操作を UI インターフェイスで直接実行したりできます。

ロールアウトの詳細

分析と漸進的な相互作用

Argo Rollouts は、段階的な配信を推進するための分析を実行するためのいくつかの方法を提供します。まず、いくつかの CRD リソースを理解する必要があります。

ロールアウト: ロールアウトは、更新中に AnalysisRuns と Experiments を作成したり、更新を進めたり、更新を中止したりできる追加の blueGreen および canary 更新戦略を提供する、デプロイメントリソースのドロップイン代替品です。
実験: 実験 CRD を使用すると、ユーザーは 1 つ以上のレプリカセットを一時的に実行できます。一時的な ReplicaSet を実行することに加えて、Experiments CRD は ReplicaSet とともに AnalysisRuns を起動することもできます。通常、これらの AnalysisRuns は、新しい ReplicaSet が期待どおりに動作していることを確認するために使用されます。
AnalysisTemplate: AnalysisTemplate は、実行すべきメトリック、頻度、成功または失敗と見なされる値など、カナリア分析の実行方法を定義するテンプレートです。 AnalysisTemplate は入力値でパラメータ化できます。
ClusterAnalysisTemplate: ClusterAnalysisTemplate は AnalysisTemplate に似ていますが、スコープがグローバルであり、クラスター全体の任意のロールアウトで使用できます。
AnalysisRun: AnalysisRun は AnalysisTemplate のインスタンス化です。 AnalysisRuns は、最終的には完了するという点でジョブに似ており、完了した実行は成功、失敗、または不確定と見なされ、実行の結果によって、ロールアウトの更新がそれぞれ続行されるか、中止されるか、一時停止されるかが左右されます。

分析する

背景分析

カナリアがデプロイメント手順を実行している間、分析はバックグラウンドで実行できます。

次の例では、カナリアの重みが 100% に達するまで、10 分ごとに 20% ずつ徐々に増加します。バックグラウンドでは、success-rate という名前の AnalysisTemplate に基づいて AnalysisRun が開始され、Prometheus サーバーにクエリを実行して 5 分間隔/サンプルで HTTP 成功率を測定します。終了時間はなく、停止されるか失敗するまで継続します。測定されたメトリックが 95% 未満で、そのような測定値が 3 つあった場合、分析は失敗と見なされました。分析が失敗するとロールアウトが中止され、カナリアの重みはゼロに戻され、ロールアウトは劣化したものとみなされます。それ以外の場合、ロールアウトがすべてのカナリアステップを完了すると、ロールアウトは成功したと見なされ、コントローラーは分析の実行を停止します。

Rollout リソースオブジェクトは次のとおりです。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook spec: # ... strategy: canary: analysis: templates: - templateName: success-rate startingStep: 2 # 延迟开始分析，到第3步开始args: - name: service-name value: guestbook-svc.default.svc.cluster.local steps: - setWeight: 20 - pause: { duration: 10m } - setWeight: 40 - pause: { duration: 10m } - setWeight: 60 - pause: { duration: 10m } - setWeight: 80 - pause: { duration: 10m }

上記では成功率テンプレートを引用しました。

 apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: args: - name: service-name metrics: - name: success-rate interval: 5m # NOTE: prometheus queries return results in the form of a vector. # So it is common to access the index 0 of the returned array to obtain the value successCondition: result[0] >= 0.95 failureLimit: 3 provider: prometheus: address: http://prometheus.example.com:9090 query: | sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m] )) / sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] ))

インライン分析

分析はインライン分析ステップとして実行することもできます。分析がインラインで実行される場合、そのステップに到達すると AnalysisRun が開始され、実行が完了するまで先に進むことがブロックされます。分析実行の成功または失敗によって、デプロイメントが次のステップに進むか、デプロイメントが完全に中止されるかが決まります。

以下に示す例では、カナリアの重みを 20% に設定し、5 分間一時停止してから分析を実行します。分析が成功した場合はロールアウトが続行され、失敗した場合は中止されます。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook spec: # ... strategy: canary: steps: - setWeight: 20 - pause: { duration: 5m } - analysis: templates: - templateName: success-rate args: - name: service-name value: guestbook-svc.default.svc.cluster.local

上記のオブジェクトでは、分析をロールアウトステップのステップとしてインライン化します。トラフィックの 20% が 5 分間停止すると、成功率分析テンプレートが実行されます。

ここでの AnalysisTemplate は上記のバックグラウンド分析の例と同じですが、間隔が指定されていないため、分析は 1 回実行されて完了します。

 apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: args: - name: service-name - name: prometheus-port value: 9090 metrics: - name: success-rate successCondition: result[0] >= 0.95 provider: prometheus: address: "http://prometheus.example.com:{{args.prometheus-port}}" query: | sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m] )) / sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] ))

さらに、カウントフィールドと間隔フィールドを指定することで、より長い期間にわたって複数の測定を実行することもできます。

 metrics: - name: success-rate successCondition: result[0] >= 0.95 interval: 60s count: 5 provider: prometheus: address: http://prometheus.example.com:9090 query: ...

複数のテンプレートの分析

Rollout は、AnalysisRun を構築するときに複数の AnalysisTemplates を参照できます。この方法では、複数の AnalysisTemplates から分析を作成できます。複数のテンプレートが参照されている場合、コントローラーはそれらを結合します。コントローラーは、すべてのテンプレートの metrics フィールドと args フィールドを結合します。以下のように表示されます。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook spec: # ... strategy: canary: analysis: templates: - templateName: success-rate - templateName: error-rate args: - name: service-name value: guestbook-svc.default.svc.cluster.local --- apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: args: - name: service-name metrics: - name: success-rate interval: 5m successCondition: result[0] >= 0.95 failureLimit: 3 provider: prometheus: address: http://prometheus.example.com:9090 query: | sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m] )) / sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] )) --- apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: error-rate spec: args: - name: service-name metrics: - name: error-rate interval: 5m successCondition: result[0] <= 0.95 failureLimit: 3 provider: prometheus: address: http://prometheus.example.com:9090 query: | sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code=~"5.*"}[5m] )) / sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] ))

分析を実行すると、コントローラーは上記の成功率テンプレートとエラー率テンプレートを AnalysisRun オブジェクトにマージします。

以下の状況が発生した場合、コントローラーはテンプレートのマージに失敗することに注意してください。

テンプレート内の複数のメトリックが同じ名前を持つ
同じ名前の2つのパラメータに値がある

テンプレートパラメータの解析

AnalysisTemplates は、ロールアウトによって渡すことができる一連のパラメータを宣言できます。これらのパラメータは、メトリック構成と同様に使用でき、AnalysisRun の作成時にインスタンス化されます。パラメータプレースホルダは、以下に示すように {{ args.<name> }} として定義されます。

 apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: args-example spec: args: # required - name: service-name - name: stable-hash - name: latest-hash # optional - name: api-url value: http://example/measure # from secret - name: api-token valueFrom: secretKeyRef: name: token-secret key: apiToken metrics: - name: webmetric successCondition: result == 'true' provider: web: # placeholders are resolved when an AnalysisRun is created url: "{{ args.api-url }}?service={{ args.service-name }}" headers: - key: Authorization value: "Bearer {{ args.api-token }}" jsonPath: "{$.results.ok}"

AnalysisRun を作成すると、ロールアウトで定義されたパラメータが、以下に示すように AnalysisTemplate のパラメータと結合されます。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook spec: --- strategy: canary: analysis: templates: - templateName: args-example args: # required value - name: service-name value: guestbook-svc.default.svc.cluster.local # override default value - name: api-url value: http://other-api # pod template hash from the stable ReplicaSet - name: stable-hash valueFrom: podTemplateHashValue: Stable # pod template hash from the latest ReplicaSet - name: latest-hash valueFrom: podTemplateHashValue: Latest

さらに、分析パラメータは、メタデータを読み取ってそれを AnalysisTemplate にパラメータとして渡すために使用される valueFrom もサポートします。次の例では、メタデータ内の env タグと region タグを参照し、それらを AnalysisTemplate に渡します。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook labels: appType: demo-app buildType: nginx-app ... env: dev region: us-west-2 spec: ... strategy: canary: analysis: templates: - templateName: args-example args: ... - name: env valueFrom: fieldRef: fieldPath: metadata.labels['env'] # region where this app is deployed - name: region valueFrom: fieldRef: fieldPath: metadata.labels['region']

ブルーグリーンプレリリース分析

BlueGreen 戦略を使用したロールアウトでは、プレリリースを使用してトラフィックを新しいバージョンに切り替える前に AnalysisRun を開始できます。分析実行の成功または失敗によって、次のようにロールアウトがトラフィックを切り替えるか、ロールアウトを完全に中止するかが決まります。

 kind: Rollout metadata: name: guestbook spec: --- strategy: blueGreen: activeService: active-svc previewService: preview-svc prePromotionAnalysis: templates: - templateName: smoke-tests args: - name: service-name value: preview-svc.default.svc.cluster.local

上記の例では、新しい ReplicaSet が完全に利用可能になると、Rollout はプレリリース版の AnalysisRun を作成します。ロールアウトではトラフィックを新しいバージョンに切り替えませんが、分析の実行が正常に完了するまで待機します。

注: autoPromotionSeconds フィールドが指定されていて、Rollout が自動プロモーションが成功するまでその秒数を待機した場合、Rollout は AnalysisRun を成功としてマークし、トラフィックを新しいバージョンに自動的に切り替えます。 AnalysisRun がこれより前に完了した場合、Rollout は別の AnalysisRun を作成せず、autoPromotionSeconds の残り時間を待機します。

ブルーグリーンリリース後の分析

BlueGreen 戦略を使用したロールアウトでは、トラフィックが新しいバージョンに切り替わった後のリリース後分析も使用できます。リリース後の分析が失敗またはエラーになった場合、ロールアウトは中止状態になり、トラフィックは以前の安定したレプリカセットに戻ります。リリース後の分析が成功すると、ロールアウトは完全にリリースされたと見なされ、新しいレプリカセットは安定しているとマークされ、古いレプリカセットは scaleDownDelaySeconds (デフォルトでは 30 秒) に従ってスケールダウンされます。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook spec: --- strategy: blueGreen: activeService: active-svc previewService: preview-svc scaleDownDelaySeconds: 600 # 10 minutes postPromotionAnalysis: templates: - templateName: smoke-tests args: - name: service-name value: preview-svc.default.svc.cluster.local

故障条件

FailureConditionを使用して、分析の実行を構成して故障するように構成できます。次の例では、5分ごとにプロメテウスサーバーを継続的に投票して、エラーの総数を取得します。 10以上のエラーが発生した場合、分析の実行が失敗したと見なされます。

 metrics: - name: total-errors interval: 5m failureCondition: result[0] >= 10 failureLimit: 3 provider: prometheus: address: http://prometheus.example.com:9090 query: | sum(irate( istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code~"5.*"}[5m] ))

結果なしで実行します

分析実行Jの結果も決定的ではないと見なされ、実行が成功しなかったことも失敗しなかったことを示しています。結果のない実行により、パブリッシングは現在のステップで一時停止します。現時点では、手術を再開または終了するには、人間の介入が必要です。メトリックに成功または失敗の条件が定義されていない場合、分析の実行は決定的な性能の例になる可能性があります。

 metrics: - name: my-query provider: prometheus: address: http://prometheus.example.com:9090 query: ...

成功条件と失敗条件の両方が指定されている場合、不確定な分析の実行も発生する可能性がありますが、測定値はどちらの条件も満たしていません。

 metrics: - name: success-rate successCondition: result[0] >= 0.90 failureCondition: result[0] < 0.50 provider: prometheus: address: http://prometheus.example.com:9090 query: ...

非決定的分析の実行のシナリオの1つは、Argoロールアウトが自動的に分析の実行を実行して測定を実行できるようにすることですが、それでも測定値が許容されるかどうかを判断し、継続するか中絶するかを決定することです。

遅延分析の実行

分析の実行をすぐに開始する必要がない場合（つまり、メトリックプロバイダーにカナリアリリースのメトリックを収集する時間を与えるため）、分析の実行は特定のメトリックの分析を遅らせることができます。各メトリックは異なる遅延を持つように構成でき、特定のメトリックの遅延に加えて、バックグラウンド分析を伴うリリースは、特定のステップに達するまで分析実行の作成を遅らせることができます。

特定の分析インジケーターを遅らせるには：

 metrics: - name: success-rate # Do not start this analysis until 5 minutes after the analysis run starts initialDelay: 5m successCondition: result[0] >= 0.90 provider: prometheus: address: http://prometheus.example.com:9090 query: ...

バックグラウンド分析の開始遅延は、ステップ3まで実行されます（重量40％を設定）。

 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: guestbook spec: strategy: canary: analysis: templates: - templateName: success-rate startingStep: 2 steps: - setWeight: 20 - pause: { duration: 10m } - setWeight: 40 - pause: { duration: 10m }

ジョブメトリック

さらに、Kubernetesのジョブを使用して分析を実行できます。ジョブを使用する場合、ゼロの出口コードでジョブが完了した場合、メトリックは成功したと見なされます。そうしないと、メトリックが失敗したと見なされます。

 metrics: - name: test provider: job: metadata: annotations: foo: bar # annotations defined here will be copied to the Job object labels: foo: bar # labels defined here will be copied to the Job object spec: backoffLimit: 1 template: spec: containers: - name: test image: my-image:latest command: [my-test-script, my-service.default.svc.cluster.local] restartPolicy: Never

Webメトリック

特定の外部サービスに対してHTTP要求を実行して、測定結果を取得することもできます。次の例では、HTTPがURLへのリクエストを取得します。 WebHook応答はJSONコンテンツを返す必要があります。 JSONPATH式の結果は、成功条件および障害調整式で参照できる結果変数に割り当てられます。省略すると、ボディ全体が結果変数として使用されます。

 metrics: - name: webmetric successCondition: result == true provider: web: url: "http://my-server.com/api/v1/measurement?service={{ args.service-name }}" timeoutSeconds: 20 # defaults to 10 seconds headers: - key: Authorization value: "Bearer {{ args.api-token }}" jsonPath: "{$.data.ok}"

たとえば、次の例は、data.okフィールドが真であり、data.successpercentが0.90を超える場合、測定が成功することを示しています。

 { "data": { "ok": true, "successPercent": 0.95 } }

 metrics: - name: webmetric successCondition: "result.ok && result.successPercent >= 0.90" provider: web: url: "http://my-server.com/api/v1/measurement?service={{ args.service-name }}" headers: - key: Authorization value: "Bearer {{ args.api-token }}" jsonPath: "{$.data}"

もちろん、アルゴロールアウトの使用に関する詳細はまだたくさんあります。公式ドキュメントを参照してください：https：//argoproj.github.io/argo-rollouts/をご覧ください。

<<: K8sGPT、AI をベースにした究極のクラウドネイティブツール

>>: クラウドアプリケーションで最新の倉庫管理を更新する方法