Kubernetesは、コンテナ化されたアプリケーションをシームレスにデプロイ・スケールできる仕組みを提供し、ソフトウェア開発に革命をもたらしました。とはいえ、その基本となるローリングアップデート戦略には、経験豊富な開発者でも不安を覚える場面があります。新しいコードをプッシュすれば、結果は成功か失敗か——スイッチを切り替えるような仕組みで、段階的にロールアウトする手段も、問題が起きた際の安全網も用意されていないからです。
大規模かつトラフィックの多い本番環境では、ローリングアップデートはリスクが高すぎると見なされがちです。影響範囲をコントロールできず、展開が一気に進みすぎる場合があり、障害発生時の自動ロールバックも備わっていないためです。
そこで登場するのが、Argo Projectsが提供するArgo Rolloutsです。この強力なKubernetesコントローラーは、デプロイを次のレベルへと引き上げます。Argo Rolloutsを使えば、次のことが可能になります。
- アップデートのスピードと範囲をコントロール: 一度にすべてを切り替えるビッグバンリリースとはお別れです。限定したユーザーへ段階的に変更を展開でき、リスクを抑えつつ安心してリリースできます。
- トラフィックを思いどおりに振り分け: 新バージョン、旧バージョン、あるいは両方にユーザーを誘導可能。機能の検証やフィードバックの収集、スムーズな移行に役立ちます。
- 高度なチェックでアップデートを検証: 「動いているか?」という単純な確認にとどまらず、外部メトリクス、ストレステスト、カスタムチェックなどを組み合わせ、リリース可否を多角的に判断できます。
- 問題が起きた場合のロールバックを自動化: 手作業で変更を戻す必要はもうありません。エラーが発生すればArgo Rolloutsが自動でロールバックし、ダウンタイムを抑えてユーザー満足度を保ちます。
本記事では、Argo Rolloutsを使ったBlue-GreenデプロイとCanaryデプロイの手順を紹介し、より安全でスムーズ、そして自信を持ってリリースを進める方法を解説します。
Argo Rolloutsとは
Argo Rolloutsは、Kubernetes上にBlue-Green、Canary分析、実験、プログレッシブデリバリーといったデプロイ機能を追加する一連のCRDを備えた、強力なKubernetesコントローラーです。
Argo Rolloutsはイングレスコントローラーやサービスメッシュと連携でき、アップデート中に新バージョンへトラフィックを徐々にシフトできます。さらに、各種プロバイダーからメトリクスを収集・分析して主要なKPIを評価し、アップデート中の自動プロモーションやロールバックを実行できます。
Deploymentオブジェクトと同様に、Argo RolloutsコントローラーはReplicaSetの作成・スケーリング・削除を管理します。これらのReplicaSetはRolloutリソース内のspec.templateフィールドで定義され、Deploymentオブジェクトと同じPodテンプレートを使用します。なお、Argo RolloutsはStatefulSetやDaemonSetには対応していません。
spec.templateが変更されると、新しいReplicaSetを導入する合図としてArgo Rolloutsコントローラーに通知されます。コントローラーはspec.strategyフィールドで指定された戦略に基づき、旧ReplicaSetから新ReplicaSetへロールアウトをどう進めるかを決定します。新ReplicaSetがスケールアップし(必要に応じてAnalysisを通過すれば)、コントローラーはそれを「stable」としてマークします。
また、spec.WorkoadRefを利用すれば、既存のDeploymentを削除することなくArgo Rolloutsで管理することも可能です。
Argo Rolloutsデモ
前提条件
- Kubernetesクラスターが構築済みで、kubectlがインストール・設定されていること。
- お使いの端末にArgo Rollouts kubectlプラグインをインストール済みであること。
Argo Rolloutsをインストールする
- 以下のコマンドでクラスターにArgo Rolloutsをインストールします。その他のオプションは公式ドキュメントを参照してください。
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
Blue-Greenデプロイ戦略
Blue-Greenデプロイでは、同じ構成の環境を2つ同時に稼働させます。Blue環境は現行の本番環境を表し、Green環境はこれからデプロイする新バージョンを表します。この間、本番トラフィックを受け付けるのは旧バージョンのみです。これにより、ライブトラフィックを新環境に切り替える前に、新バージョンを十分に検証できます。

シンプルなDeploymentを例に、Argo RolloutsでBlue-Green戦略をどのように実現するかを見ていきましょう。
- 以下のコマンドで、サンプルのnginxアプリケーションをクラスターにデプロイします。これがBlue環境となります。
kubectl create deployment nginx --image nginx:1.19.10 --replicas 2

サンプルアプリケーションのPod
- このDeployment用にKubernetes Serviceを2つ作成します。1つは現行環境(Blue)用、もう1つは新環境(Green)用です。
kubectl expose deployment nginx --name nginx-active --port 80 --target-port 80
kubectl expose deployment nginx --name nginx-preview --port 80 --target-port 80

サンプルのServiceとEndpoint
- Blue-Green戦略に必要な設定を盛り込んだArgo Rolloutリソースを作成します。すべてのオプションは公式ドキュメントを参照してください。
cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: nginx
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: nginx
strategy:
blueGreen: #Indicates that the rollout should use the Blue-Green strategy
activeService: nginx-active # Reference to service that the rollout modifies as the active service.
previewService: nginx-preview # Name of the service that the rollout modifies as the preview service.
previewReplicaCount: 1 #The number of replicas to run under the preview service before the switchover.
# Indicates if the rollout should automatically promote the new ReplicaSet
# to the active service or enter a paused state. If not specified, the
# default value is true. +optional
autoPromotionEnabled: false
# WorkloadRef holds a references to a workload that provides Pod template
workloadRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
EOF
- 下図のように、新しいReplicaSetとArgo Rolloutの設定を確認します。

Pod、ReplicaSet、Argo Rolloutのステータス
- 初期のReplicaSetが管理するPodは自動では削除されません。Argo Rolloutが管理を引き継いだので、Deploymentのレプリカ数を手動で0にスケールダウンしておくことを推奨します。以下のコマンドで未管理のPodをスケールダウンしてください。
kubectl scale deployment nginx --replicas 0

- イメージのバージョンを
latestに変更し、新しいリビジョンをトリガーしてみましょう。
kubectl set image deployment/nginx nginx=nginx:latest

プロモーション前のBlue-Greenデプロイステータス
- Green環境の準備が整いました。
nginx-previewサービスを使えば、nginx-activeサービスが処理するライブトラフィックに影響を与えずに変更を検証できます。 - Argo Rolloutのダッシュボードでロールアウト状況をモニタリングすることも可能です。以下のコマンドでダッシュボードにアクセスできます。
kubectl argo rollouts dashboard -n default

Argo Rolloutダッシュボード上のロールアウトステータス
- 以下のコマンドで新バージョンを本番にプロモートします。
kubectl argo rollouts promote nginx

プロモーション後のBlue-Greenデプロイステータス
Canaryデプロイ戦略
Canaryデプロイは、すでに稼働中のバージョンと新バージョンの間でトラフィックを振り分け、一部のユーザーへ段階的に新バージョンを展開してから全面リリースする、フェーズ型のデプロイ手法です。
NGINXやIstioのようなイングレスコントローラーやサービスメッシュを併用すれば、より高度なトラフィック制御が可能になります。たとえば、細かな比率でのトラフィック分割や、HTTPヘッダーに基づく分割などです。

それでは、Argo RolloutsをCanaryデプロイで活用する方法を見ていきましょう。
- サンプルアプリケーションをクラスターにデプロイします。
kubectl create deployment nginx-canary --image nginx:1.19.10 --replicas 5
- このDeployment用にKubernetes Serviceを作成します。Blue-Greenデプロイとは異なり、Canaryでは新しいPodのエンドポイントがCanaryの割合に応じてKubernetes Serviceに追加されるため、同じDeploymentに対して2つのServiceを用意する必要はありません。
kubectl expose deployment nginx-canary --port 80 --target-port 80

サンプルアプリケーションのPodとService
- Canary戦略用のArgo Rolloutリソースを作成します。すべてのオプションは公式ドキュメントを参照してください。
cat <<EOF | kubectl apply -f -
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: nginx-canary
spec:
replicas: 5
selector:
matchLabels:
app: nginx-canary
workloadRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-canary
strategy:
canary: #Indicates that the rollout should use the Canary strategy
maxSurge: "25%"
maxUnavailable: 0
steps:
- setWeight: 10
- pause:
duration: 1h #Pause for 1 hour and wait promote to next canary stage
- setWeight: 30
- pause: {} # pause indefinitely and requires manual promote action
- setWeight: 100
- pause: {} # pause indefinitely and requires manual promote action
EOF

Pod、ReplicaSet、Argo Rolloutのステータス
- Blue-Greenデプロイの場合と同じく、Argo Rolloutが新ReplicaSetに属する新規Podをすべて管理できるよう、現行Deploymentのレプリカ数を0にスケールダウンする必要があります。
kubectl scale deployment nginx-canary --replicas 0
- 新しいバージョンのアプリケーションをデプロイし、Canaryデプロイの挙動を観察してみましょう。
kubectl set image deployment/nginx-canary nginx=nginx:latest

初期(10%)のCanaryデプロイステータス

Argoダッシュボード上のCanaryロールアウトステータス
- ロールアウトを次のCanaryステージへ手動でプロモートします。
kubectl argo rollouts promote nginx-canary

30%のCanaryロールアウトステータス

Argoダッシュボード上のCanaryロールアウトステータス

100%のCanaryロールアウトステータス

Argoダッシュボード上のCanaryロールアウトステータス
Argo RolloutsにはAnalysis機能が備わっており、デプロイ中またはデプロイ後にアプリケーションへ各種チェックやテストを定義・実行できます。これにより、新バージョンを本番トラフィックに完全にプロモートする前に、その安定性とパフォーマンスを検証できます。
まとめると、Argo Rolloutsはデプロイ手法を磨き上げ、シームレスで信頼性の高いアプリケーション更新を実現したいKubernetes担当者にとって、心強いツールです。豊富な機能を備えており、プログレッシブデリバリーの導入、ユーザー体験の向上、そしてソフトウェアアップグレード時のダウンタイム最小化を目指す企業にとって、有力な選択肢となるでしょう。