ACK One は Argo CD GitOps と Argo Rollouts を統合し、Git コミットによってトリガーされるカナリアリリースを自動化します。このチュートリアルでは、必要なコンポーネントのデプロイ、GitOps で管理されるアプリケーションの設定、そして手動昇格または Prometheus メトリックに基づく自動昇格によるカナリアリリースの実行方法を順を追って説明します。
前提条件
開始する前に、以下をご確認ください:
-
フリート管理が有効です。詳細については、「マルチクラスター管理の有効化」をご参照ください。
-
ACK クラスターが作成され、ACK One フリートインスタンスに関連付けられていること。詳細については、「ACK マネージドクラスターの作成」および「フリートインスタンスへのクラスターの関連付け」をご参照ください。
-
フリートインスタンスの kubeconfig ファイルがあり、kubectl がフリートインスタンスに接続されていること。ACK One コンソールからダウンロードしてください。
-
Alibaba Cloud CLI がインストールおよび設定済みです。「Alibaba Cloud CLI のインストール」と「Alibaba Cloud CLI の設定」をご参照ください。
-
最新の Argo Rollouts kubectl プラグインがインストールされていること。詳細については、「Controller Installation」をご参照ください。
GitHub リポジトリを使用する場合、中国本土のリージョンで ACK クラスターを作成することは避けてください。クラスターがすでに中国本土にある場合は、GitHub サービスプロバイダーを使用してください。このチュートリアルでは、中国 (香港) リージョンにデプロイされたフリートインスタンスと関連付けられた ACK クラスターを使用します。
基本概念
GitOps は、Git リポジトリを信頼できる唯一の情報源 (single source of truth) として使用し、アプリケーションの構成を管理し、継続的デプロイメントを推進するフレームワークです。詳細については、「GitOps の概要」をご参照ください。
Argo Rollouts は、ブルーグリーンデプロイメント、カナリアリリース、プログレッシブデリバリーなどの高度なデプロイメント戦略を提供する Kubernetes コントローラーです。詳細については、「Argo Rollouts ドキュメント」をご参照ください。
カナリアリリースは、一部のユーザーから開始して、新しいアプリケーションバージョンにトラフィックを段階的に移行するデプロイメント戦略です。トラフィックは Ingress コントローラーを介して制御されるため、本番環境で新しいバージョンを検証し、すべてのユーザーに影響を与えることなく、トラフィックをリダイレクトすることで即座にロールバックできます。
仕組み
Rollout リソースの spec.template への変更 (通常は Git にコミットされたイメージタグの更新) が、新しいカナリア分析をトリガーします。Argo CD がコミットを検出し、更新されたマニフェストをクラスターに同期すると、Argo Rollouts は Rollout 仕様で定義されたステップに従ってトラフィックの移行を開始します。
カナリアリリース中:
-
カナリアサービスは、新しいバージョンにトラフィックをルーティングします。
-
安定版サービスは、現在のバージョンにトラフィックをルーティングします。
-
NGINX Ingress コントローラーは、各ステップで定義された重みに基づいてトラフィックを分割します。
spec.templateへの変更のみが新しいカナリア分析をトリガーします。spec.template外のラベル、アノテーション、またはその他のメタデータへの変更は、ロールアウトを開始しません。
ステップ 2:ACK クラスターへの ack-arms-prometheus アドオンのデプロイ
Managed Service for Prometheus (ack-arms-prometheus アドオン) は、ステップ 4 の自動カナリア昇格で使用される Ingress メトリックを収集します。
-
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
-
[クラスター] ページで、対象のクラスターを見つけてその名前をクリックします。左側のペインで、[運用管理] > [アドオン] を選択します。
-
[アドオン] ページで、[ログとモニタリング] タブをクリックし、[ack-arms-prometheus] を見つけます。
-
[インストール済み] と表示されている場合、アドオンはすでにアクティブです。
-
[インストール] と表示されている場合、[インストール] をクリックします。
-
ステップ 4:カナリアリリースの実行
rollout.yaml のコンテナイメージタグを更新し、変更を Git にプッシュすることでカナリアリリースをトリガーします。Argo CD がコミットを検出し、Argo Rollouts がトラフィックの移行を開始します。
以下のいずれかのプロモーション方法を選択してください。
-
手動昇格 — 各トラフィックステップを進める前に、カナリアをご自身でレビューします。
-
Prometheus メトリックによる自動昇格 — 成功率のしきい値を満たすと、Argo Rollouts がカナリアを自動的に昇格させます。
オプション 1:手動昇格
このアプローチでは、最初のトラフィックステップの後にカナリアを一時停止し、続行する前に新しいバージョンを検証できます。
トラフィックステップ: 20% → 一時停止 (無期限) → 40% (5 分) → 60% (5 分) → 80% (5 分) → 100%
それぞれ 5 分の 3 つの時間指定ステップがあるため、最初の手動承認後の昇格には約 15 分かかります。
-
rollout.yamlを新しいイメージタグと最初のステップ後の手動一時停止で更新し、コミットしてプッシュします:apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: replicas: 4 strategy: canary: canaryService: rollouts-demo-canary stableService: rollouts-demo-stable trafficRouting: nginx: stableIngress: rollouts-demo-stable steps: - setWeight: 20 - pause: {} # 無期限の一時停止 — {} を期間に置き換えて手動で進めます - setWeight: 40 - pause: {duration: 5m} - setWeight: 60 - pause: {duration: 5m} - setWeight: 80 - pause: {duration: 5m} revisionHistoryLimit: 2 selector: matchLabels: app: rollouts-demo template: metadata: labels: app: rollouts-demo spec: containers: - name: rollouts-demo image: argoproj/rollouts-demo:yellow # 新しいイメージタグ ports: - name: http containerPort: 8080 protocol: TCP resources: requests: memory: 32Mi cpu: 5m -
ロールアウトが 20% のトラフィックで一時停止するのを監視します:
kubectl argo rollouts get rollout rollouts-demo --watch期待される出力:期間が設定されていないため、ロールアウトは最初の
pause: {}ステップで停止します。再開した後にのみ進行します。
-
rollout.yamlの一時停止期間を更新してカナリアリリースを再開し、コミットしてプッシュします:steps: - setWeight: 20 - pause: {duration: 10s} # {} を期間に置き換えて再開しますその後、リリースが完了するのを監視します:
kubectl argo rollouts get rollout rollouts-demo --watch昇格中の期待される出力:

完了後の期待される出力:

オプション 2:Prometheus メトリックによる自動昇格
このアプローチでは、Managed Service for Prometheus を使用して、カナリアの HTTP 成功率を継続的に評価します。分析ウィンドウ全体で成功率が 95% 以上を維持している場合、カナリアは自動的に昇格します。10 回連続でしきい値を下回った場合、リリースは自動的にロールバックされます。
トラフィックステップ: 20% (5 分) → 40% (5 分、ここで分析開始) → 60% (5 分) → 80% (5 分) → 100%
合計プロモーション時間: 約20分。
ステップ 4a:メトリック分析による Rollout の設定
rollout.yaml を新しいイメージタグと分析設定で更新し、コミットしてプッシュします:
strategy:
canary:
analysis:
templates:
- templateName: success-rate
startingStep: 2 # 初期のトラフィックが安定した後、40% のステップで分析を開始します
args:
- name: service-name
value: rollouts-demo-stable
canaryService: rollouts-demo-canary
stableService: rollouts-demo-stable
trafficRouting:
nginx:
stableIngress: rollouts-demo-stable
steps:
- setWeight: 20
- pause: {duration: 5m}
- setWeight: 40
- pause: {duration: 5m}
- setWeight: 60
- pause: {duration: 5m}
- setWeight: 80
- pause: {duration: 5m}
revisionHistoryLimit: 2
selector:
matchLabels:
app: rollouts-demo
template:
metadata:
labels:
app: rollouts-demo
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:blue # 新しいイメージタグ
ステップ 4b:Managed Service for Prometheus エンドポイントの取得
Managed Service for Prometheus は、次の Kubernetes サービスとして公開されます:
http://{ServiceName}.{Namespace}.svc.{ClusterDomain}:{ServicePort}
デフォルトのクラスター ドメインを使用し、arms-prom 名前空間にデプロイされている ack-arms-prometheus アドオンのエンドポイントは次のとおりです。
http://arms-prom-server.arms-prom.svc.cluster.local:9090
ステップ 4c:AnalysisTemplate の作成
次の内容で analysis.yaml を作成します。successCondition は、5 分間のウィンドウで、すべてのカナリアリクエストに対する 2xx 応答の比率が 95% 以上の場合にカナリアステップをパスさせます。
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 # 95% 以上のリクエストが成功した場合に昇格
failureLimit: 10 # 10 回連続で失敗した場合は中止
provider:
prometheus:
address: http://arms-prom-server.arms-prom.svc.cluster.local:9090
query: |
sum(
irate(nginx_ingress_controller_requests{status=~"(1|2).*", canary!="" ,service="{{args.service-name}}"}[5m]))
/
sum(irate(nginx_ingress_controller_requests{canary!="",service="{{args.service-name}}"}[5m])
)
PromQL クエリは、1xx/2xx カナリアリクエストのレートを、合計カナリアリクエストレートで割ります。canary!="" ラベルセレクターは、カナリア Ingress アノテーションを介してルーティングされるトラフィックをフィルター処理します。これにより、安定版トラフィックではなく、カナリアトラフィックのみが評価されることが保証されます。service ラベルは、クエリの範囲を特定のアプリケーションに限定します。
ステップ 4d:メトリック収集のための継続的なトラフィックの生成
Prometheus が成功率を評価するには、安定したリクエストストリームが必要です。別のターミナルで次のコマンドを実行します。
-
Ingress の外部 IP を取得します:
kubectl get ingress期待される出力:
NAME CLASS HOSTS ADDRESS PORTS AGE rollouts-demo-rollouts-demo-stable-canary nginx rollouts-demo.local 8.217.XX.XX 80 9h rollouts-demo-stable nginx rollouts-demo.local 8.217.XX.XX 80 9h -
ホストマッピングをローカルの Hosts ファイルに追加します:
8.217.XX.XX rollouts-demo.local -
アプリケーションに継続的なリクエストを送信します:
while true; do curl -s "http://rollouts-demo.local/" | grep -o "<title>.*</title>"; sleep 200ms; done
ステップ 4e:自動ロールアウトの監視
kubectl argo rollouts get rollout rollouts-demo --watch
期待される出力:
Alibaba Cloud コンソールで成功率メトリックを表示するには:
-
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
-
クラスター名をクリックします。左側ペインで、[操作] > [Prometheus モニタリング] を選択します。
-
[Prometheus モニタリング] ページで、[ネットワークモニタリング] タブをクリックし、次に [Ingress] をクリックします。

カナリアリリースが正常に完了した後:
ステップ 5 (オプション):カナリアリリースのロールバック
カナリアリリース中に新しいバージョンで問題が発生した場合は、rollout.yaml のイメージタグを既知の安定バージョンに戻し、変更を Git にプッシュします。Argo CD が変更を同期し、Argo Rollouts がすべてのトラフィックを安定版バージョンに戻します。
失敗したカナリアの表示例
自動昇格が有効になっている場合、失敗したカナリアは、ロールバックが完了する前に次のような出力を生成します:
Name: rollouts-demo
Namespace: default
Status: ✖ Degraded
Message: RolloutAborted: Rollout aborted update to revision 2: Metric "success-rate" assessed Failed due to failed (10) > failureLimit (10)
Strategy: Canary
Step: 4/8
SetWeight: 40
ActualWeight: 40
Images: argoproj/rollouts-demo:yellow (stable)
argoproj/rollouts-demo:blue (canary, error)
10 回連続でメトリック評価が 95% のしきい値 (failureLimit: 10) を下回ると、ロールアウトは中止されます。その後、Argo Rollouts はすべてのトラフィックを自動的に安定版バージョンに戻します。
手動でのロールバック方法
安定版のイメージタグで rollout.yaml を更新し、コミットします:
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:yellow # 安定版のイメージタグに戻します
ロールバック後の期待される出力:
