Argo ロールアウトによるプログレッシブリリース

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

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

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

実施原則

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

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

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

ロールアウトする

Rollout は、Kubernetes Deployment オブジェクトと同等の Kubernetes CRD リソースです。より高度なデプロイメント機能またはプログレッシブ配信機能が必要な場合に、デプロイメントオブジェクトを置き換えることを目的としています。 Rollout は、Kubernetes Deployment では提供できない機能を提供します。

ブルーグリーンデプロイメント
カナリアデプロイメント
高度なトラフィックルーティングのためにIngressコントローラとサービスメッシュを統合する
ブルーグリーン分析とカナリア分析のためのメトリクスプロバイダーとの統合
成功または失敗の指標に基づいて自動的にリリースまたはロールバックする

プログレッシブデリバリー

プログレッシブ配信は、製品のアップデートを制御された段階的な方法でリリースするプロセスであり、これによりリリースのリスクが軽減され、多くの場合、自動化とメトリック分析を組み合わせて、アップデートの自動アップグレードまたはロールバックが実行されます。

プログレッシブデリバリーは、継続的デリバリーの進化形として説明されることが多く、CI/CD のスピードの利点をデプロイメントプロセスに拡張します。新しいバージョンを一部のユーザーに限定し、正しい動作を観察および分析し、その正確性を継続的に検証しながら徐々にトラフィックを増やします。

展開戦略

業界ではさまざまな展開戦略を説明するために一貫した用語を使用していますが、これらの戦略の実装はツールごとに異なることがよくあります。 Argo Rollouts の動作を明確にするために、以下では Argo Rollouts が提供するさまざまなデプロイメント戦略の実装について説明します。

RollingUpdate: 古いバージョンを新しいバージョンに徐々に置き換えます。新しいバージョンが登場すると、アプリケーションの総数を維持するために、古いバージョンは徐々に縮小されます。これはデプロイメントオブジェクトのデフォルトの戦略です。
再作成: 再作成では、新しいバージョンを起動する前にアプリケーションの古いバージョンを削除します。これにより、アプリケーションの 2 つのバージョンが同時に実行されることはありませんが、デプロイメント中にダウンタイムが発生します。
ブルーグリーン: ブルーグリーンリリース (レッドブラックと呼ばれることもあります) は、アプリケーションの 2 つのバージョンを同時に展開し、その間はアプリケーションの古いバージョンのみが実稼働トラフィックを受信します。これにより、開発者はライブトラフィックを新しいバージョンに切り替える前に、そのバージョンに対してテストを行うことができます。

カナリア: カナリアリリースとは、一部のユーザーにアプリケーションの新しいバージョンを公開し、残りのトラフィックを古いバージョンに提供することを指します。新しいバージョンが正しいことが検証されると、新しいバージョンが徐々に古いバージョンに置き換えられます。 NGINX Ingress や Istio などの Ingress コントローラーとサービスメッシュにより、カナリアのトラフィック分割パターンがネイティブのものよりも複雑になる可能性があります (たとえば、非常にきめ細かいトラフィック分割を実装したり、HTTP ヘッダーに基づいて分割したりするなど)。

上の画像は、2 つのステージ (トラフィックの 10% と 33% が新しいバージョンに送られる) を持つカナリアを示しています。 Argo Rollouts を使用すると、実際の使用状況に基づいてステージ数とトラフィックの割合を正確に定義できます。

建築

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

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

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

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

ロールアウトリソース

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

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

古いレプリカセットと新しいレプリカセット

これらは標準の Kubernetes ReplicaSet リソースのインスタンスであり、Argo Rollouts はアプリケーションに属するさまざまなバージョンを追跡するために、追加のメタデータを追加します。

また、ロールアウトに参加しているレプリカセットはコントローラーによって完全に自動的に管理されるため、外部ツールで改ざんしてはならないことにも注意してください。

イングレス/サービス

ユーザートラフィックがクラスターに入ると、適切なバージョンにリダイレクトされます。 Argo Rollouts は標準の Kubernetes サービスリソースを使用しますが、いくつかの追加のメタデータを使用します。

Argo Rollouts はネットワーク構成において非常に柔軟です。まず、ロールアウト中にさまざまなサービスを使用できます。これは、新しいバージョンのみ、古いバージョンのみ、または両方に適用できます。特に Canary デプロイメントの場合、Argo Rollouts は、ポッドの数に基づく単純な構成ではなく、特定の割合でトラフィックを分割するための複数のサービスメッシュおよび Ingress ソリューションをサポートします。

分析と分析実行

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

分析は、クエリするメトリックの単なるテンプレートです。ロールアウトに添付された実際の結果は AnalysisRun カスタムリソースであり、特定のロールアウトで分析を定義したり、クラスター上でグローバルに分析を定義して複数のロールアウトで共有したりできます。

ロールアウトでの分析とメトリックの使用は完全にオプションであり、API または CLI を介して手動でリリースを一時停止および促進したり、他の外部メソッドを使用したりできることに注意してください。 Argo Rollouts のメトリクスソリューションのみを使用する必要はなく、ロールアウトで自動 (分析ベース) のステップと手動のステップを混在させることもできます。

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

メトリックプロバイダー

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

CLI と UI

ロールアウトは、Argo Rollouts CLI または統合 UI を使用して表示および管理することもできます (どちらもオプション)。

インストール

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

 $ kubectl 名前空間 argo-rollouts を作成します
$ kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/download/v1.2.2/install.yaml

ここで argo-rollouts という名前空間が作成され、その下で Argo Rollouts コントローラーが実行されます。

 $ kubectl get pods -n argo-rollouts
名前 準備完了 ステータス 再起動 年齢
argo-rollouts-845b79ff9-crx9v 1/1 実行中 0 58秒

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

 # https://github.91chi.fun/https://github.com//argoproj/argo-rollouts/releases/download/v1.2.2/kubectl-argo-rollouts-linux-amd64
 $カール -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.2.2/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 ロールアウト バージョン
kubectl-argo-rollouts: v1.2.2+22aff27
 ビルド日: 2022-07-26T17:24:43Z
 Gitコミット: 22aff273bf95646e0cd02555fbe7d2da0f903316
 GitTreeState: クリーン
 Goバージョン: go1.17.6
 コンパイラ: gc
 プラットフォーム: linux/amd64

使用

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

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

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

 # 基本的なロールアウト.yaml
 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ロールアウトデモ
仕様:
 replicas: 5 # 5つのレプリカを定義する
 戦略: #アップグレード戦略を定義する
 canary: # カナリアリリース
 ステップ: # リズムをリリース
 - 重みを設定: 20
 - pause: {} # 常に一時停止します
 - 重みを設定: 40
 - pause: {duration: 10 } # 10秒間一時停止
 - 重みを設定: 60
 - 一時停止: { 継続時間: 10 }
 - 重みの設定: 80
 - 一時停止: { 継続時間: 10 }
 リビジョンヒストリー制限: 2 # 次の部分は実際にはデプロイメントと互換性があります
 セレクタ：
 一致ラベル:
 アプリ: ロールアウトデモ
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: ロールアウトデモ
 仕様:
 コンテナ:
 - 名前: ロールアウトデモ
 画像: argoproj/rollouts-demo:blue
 ポート:
 - 名前: http
 コンテナポート: 8080
 プロトコル: TCP
 リソース：
 リクエスト:
 メモリ: 32Mi
 CPU: 5m

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

 # 基本サービス.yaml
 APIバージョン: v1
種類: サービス
メタデータ:
 名前: ロールアウトデモ
仕様:
 ポート:
 - ポート: 80
 ターゲットポート: http
 プロトコル: TCP
 名前: http
 セレクタ：
 アプリ: ロールアウトデモ

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

 $ kubectl apply -f 基本的なロールアウト.yaml
 $ kubectl apply -f 基本サービス.yaml

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

 $ kubectl ポッドを取得 -l app=rollouts-demo
名前 準備完了 ステータス 再起動 年齢
rollouts-demo-687d76d795-6ppnh 1/1 実行中 0 53秒
rollouts-demo-687d76d795-8swrk 1/1 実行中 0 53秒
rollouts-demo-687d76d795-fnt2w 1/1 実行中 0 53秒
rollouts-demo-687d76d795-mtvtw 1/1 実行中 0 53秒
rollouts-demo-687d76d795-sh56l 1/1 実行中 0 53秒

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

 $ kubectl argo rollouts ロールアウトを取得します rollouts-demo --watch

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

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

 $ kubectl argo rollouts set image rollouts-demo \
 ロールアウトデモ=argoproj/ロールアウトデモ:黄色
ロールアウト「rollouts-demo」イメージが更新されました

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

 $ kubectl argo rollouts ロールアウトを取得します rollouts-demo --watch

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

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

上記の更新後、ロールアウトは一時停止状態になり、ロールアウトが期間のない一時停止ステップに達すると、再開/昇格されるまで一時停止状態のままになります。ロールアウトを手動で次のステップに切り替えるには、プラグインのプロモーションコマンドを実行します。

 $ kubectl argo ロールアウト ロールアウトデモをプロモートする
ロールアウト「rollouts-demo」が昇格されました

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

 $ kubectl argo rollouts ロールアウトを取得します rollouts-demo --watch

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

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

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

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

 $ kubectl argo rollouts set image rollouts-demo \
 ロールアウトデモ=argoproj/ロールアウトデモ:red
ロールアウト「rollouts-demo」イメージが更新されました

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

 $ kubectl argo ロールアウトを中止して、ロールアウト デモを実行します。

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

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

 $ kubectl argo rollouts set image rollouts-demo \
 ロールアウトデモ=argoproj/ロールアウトデモ:黄色

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

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

上記の例のロールアウトでは、トラフィックを制御するために Ingress コントローラまたはサービスメッシュは使用されません。代わりに、通常の Kubernetes サービスを使用して、新しいレプリカと古いレプリカの数の比率に基づいて、おおよそのカナリアウェイトを実装します。したがって、このロールアウトには、5 つのポッドのうち 1 つをスケーリングして新しいバージョンを実行することによって、最小の重みを 20% しか達成できないという制限があります。よりきめ細かいカナリアを実装するには、Ingress コントローラーまたはサービスメッシュが必要です。

ダッシュボード

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

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

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

分析と漸進的な相互作用

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

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

背景分析

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

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

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

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 # ...
 戦略：
 カナリア：
 分析：
 テンプレート:
 - テンプレート名: 成功率
 開始ステップ: 2 # 分析の開始をステップ3まで遅らせる
 引数:
 - 名前: サービス名
 値: guestbook-svc.default.svc.cluster.local
 手順:
 - 重みを設定: 20
 - 一時停止: { 継続時間: 10 分 }
 - 重みを設定: 40
 - 一時停止: { 継続時間: 10 分 }
 - 重みを設定: 60
 - 一時停止: { 継続時間: 10 分 }
 - 重みの設定: 80
 - 一時停止: { 継続時間: 10 分 }

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

 apiバージョン: argoproj.io/v1alpha1
種類: 分析テンプレート
メタデータ:
 名前: 成功率
仕様:
 引数:
 - 名前: サービス名
 メトリクス:
 - 名前: 成功率
 間隔: 5m
 # 注意: Prometheus クエリは結果をベクトル形式で返します。
 # そのため、返された配列のインデックス0にアクセスして値を取得するのが一般的です
 成功条件: 結果[0] >= 0.95
 失敗制限: 3
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: |
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5分]
 )) /
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5分]
 ))

インライン分析

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

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

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 # ...
 戦略：
 カナリア：
 手順:
 - 重みを設定: 20
 - 一時停止: { 継続時間: 5 分 }
 - 分析：
 テンプレート:
 - テンプレート名: 成功率
 引数:
 - 名前: サービス名
 値: guestbook-svc.default.svc.cluster.local

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

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

 apiバージョン: argoproj.io/v1alpha1
種類: 分析テンプレート
メタデータ:
 名前: 成功率
仕様:
 引数:
 - 名前: サービス名
 - 名前: プロメテウスポート
 値: 9090
 メトリクス:
 - 名前: 成功率
 成功条件: 結果[0] >= 0.95
 プロバイダー:
 プロメテウス:
 アドレス: "http://prometheus.example.com:{{args.prometheus-port}}"
 クエリ: |
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5分]
 )) /
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5分]
 ))

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

メトリクス:
 - 名前: 成功率
 成功条件: 結果[0] >= 0.95
 間隔: 60秒
 カウント: 5
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: ...

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

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

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 # ...
 戦略：
 カナリア：
 分析：
 テンプレート:
 - テンプレート名: 成功率
 - テンプレート名: エラー率
 引数:
 - 名前: サービス名
 値: guestbook-svc.default.svc.cluster.local
 ---
 apiバージョン: argoproj.io/v1alpha1
種類: 分析テンプレート
メタデータ:
 名前: 成功率
仕様:
 引数:
 - 名前: サービス名
 メトリクス:
 - 名前: 成功率
 間隔: 5m
 成功条件: 結果[0] >= 0.95
 失敗制限: 3
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: |
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5分]
 )) /
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5分]
 ))---
 apiバージョン: argoproj.io/v1alpha1
種類: 分析テンプレート
メタデータ:
 名前: エラー率
仕様:
 引数:
 - 名前: サービス名
 メトリクス:
 - 名前: エラー率
 間隔: 5m
 成功条件: 結果[0] <= 0.95
 失敗制限: 3
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: |
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code=~"5.*"}[5分]
 )) /
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5分]
 ))

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

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

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

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

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

 apiバージョン: argoproj.io/v1alpha1
種類: 分析テンプレート
メタデータ:
 名前: args-例
仕様:
 引数:
 ＃ 必須
 - 名前: サービス名
 - 名前: 安定したハッシュ
 - 名前: 最新ハッシュ
 # オプション
 - 名前: api-url
 値: http://example/measure
 # 秘密から
 - 名前: APIトークン
 値:
 シークレットキーリファレンス:
 名前: トークンシークレット
 キー: apiToken
 メトリクス:
 - 名前: ウェブメトリック
 成功条件: 結果 == 'true'
 プロバイダー:
 ウェブ：
 # プレースホルダーは AnalysisRun の作成時に解決されます
 url: "{{ args.api-url }}?service={{ args.service-name }}"
 ヘッダー:
 - キー: 認証
 値: "Bearer {{ args.api-token }}"
 jsonPath: "{$.results.ok}"

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

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 ---
戦略：
 カナリア：
 分析：
 テンプレート:
 - テンプレート名: args-例
 引数:
 # 必須値
 - 名前: サービス名
 値: guestbook-svc.default.svc.cluster.local
 # デフォルト値を上書きする
 - 名前: api-url
 値: http://other-api
 # 安定したレプリカセットからのポッドテンプレートハッシュ
 - 名前: 安定したハッシュ
 値:
 podTemplateHashValue: 安定
 # 最新のレプリカセットからのポッドテンプレートハッシュ
 - 名前: 最新ハッシュ
 値:
 podTemplateHashValue: 最新

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

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
 ラベル:
 アプリタイプ: デモアプリ
 ビルドタイプ: nginx-app
 ...
 環境: 開発
 地域: us-west-2
仕様:
 ...
 戦略：
 カナリア：
 分析：
 テンプレート:
 - テンプレート名: args-例
 引数:
 ...
 - 名前: env
 値:
 フィールド参照:
 フィールドパス: metadata.labels['env']
 # このアプリがデプロイされているリージョン
 - 名前: 地域
 値:
 フィールド参照:
 フィールドパス: metadata.labels['region']

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

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

種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 ---
戦略：
 青緑:
 アクティブサービス: アクティブSVC
 プレビューサービス: preview-svc
 事前プロモーション分析:
 テンプレート:
 - テンプレート名: スモークテスト
 引数:
 - 名前: サービス名
 値: preview-svc.default.svc.cluster.local

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

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

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

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

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 ---
戦略：
 青緑:
 アクティブサービス: アクティブSVC
 プレビューサービス: preview-svc
 scaleDownDelaySeconds: 600 # 10 分
 プロモーション後の分析:
 テンプレート:
 - テンプレート名: スモークテスト
 引数:
 - 名前: サービス名
 値: preview-svc.default.svc.cluster.local

故障条件

failureCondition を使用すると、分析の実行が失敗するように構成できます。次の例では、Prometheus サーバーを 5 分ごとに継続的にポーリングして、エラーの合計数を取得します。 10 個以上のエラーが発生した場合、分析の実行は失敗したとみなされます。

メトリクス:
 - 名前: 合計エラー数
 間隔: 5m
 失敗条件: 結果[0] >= 10
 失敗制限: 3
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: |
 合計(
 istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code~"5.*"}[5分]
 ))

結果なしで実行

分析実行 j の結果は不確定であると見なすこともできます。これは、実行が成功も失敗もしていないことを示します。結果がない実行の場合、公開は現在のステップで一時停止されます。このとき、操作を再開したり終了したりするには、人による介入が必要です。メトリックに成功または失敗の条件が定義されていない場合、分析の実行は結論が出ない例になる可能性があります。

メトリクス:
 - 名前: my-query
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: ...

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

メトリクス:
 - 名前: 成功率
 成功条件: 結果[0] >= 0.90
 失敗条件: 結果[0] < 0.50
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: ...

非決定論的な分析実行のシナリオの 1 つは、Argo Rollouts が自動的に分析実行を実行し、測定値を収集できるようにしながら、測定値が許容できるかどうかの判断を下し、続行するか中止するかを決定できるようにすることです。

遅延分析実行

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

特定の分析インジケータを遅延するには:

メトリクス:
 - 名前: 成功率
 # 分析実行開始後5分までこの分析を開始しないでください
 初期遅延: 5分
 成功条件: 結果[0] >= 0.90
 プロバイダー:
 プロメテウス:
 アドレス: http://prometheus.example.com:9090
 クエリ: ...

バックグラウンド分析の実行開始をステップ 3 (重みを 40% に設定) まで遅延します。

 apiバージョン: argoproj.io/v1alpha1
種類: ロールアウト
メタデータ:
 名前: ゲストブック
仕様:
 戦略：
 カナリア：
 分析：
 テンプレート:
 - テンプレート名: 成功率
 開始ステップ: 2
 手順:
 - 重みを設定: 20
 - 一時停止: { 継続時間: 10 分 }
 - 重みを設定: 40
 - 一時停止: { 継続時間: 10 分 }

さらに、OpenKurise プロジェクトは最近、同様のプログレッシブリリースツールである Kruise Rollouts をリリースしました。ご興味がございましたら、https://github.com/openkruise/rollouts にアクセスして詳細をご確認ください。

<<: Kafka ネットワーク層ソースコード実装メカニズムにおけるメッセージの送受信プロセス全体の図解説明

>>: クラウドでのインシデント対応は、準備さえしておけば簡単です