ArgoCDとArgo Rolloutsによるブルーグリーンデプロイの実践ガイド

ArgoCDとArgo Rolloutsによるブルーグリーン戦略の実装

Kubernetesにおいて安定したゼロダウンタイムリリースを実現するには、GitOpsフレームワークとブルーグリーンデプロイの連携が不可欠です。ArgoCD単体ではトラフィック制御や環境分離が難しいため、Argo Rolloutsとの統合が必須となります。本記事では、これらの技術を組み合わせたアーキテクチャと具体的な実装手順について解説します。

GitOpsとブルーグリーン戦略の相性

GitOpsはコードベースでインフラを管理する手法ですが、バージョン切り替え時のリスク軽減が課題でした。ArgoCD単体ではロールバックが可能ですが、トラフィックシフトや環境分離には限界があります。一方、Argo Rolloutsの導入により、パラメータ調整可能なブルーグリーンデプロイを実現でき、ゼロダウンタイムでのリリースが可能になります。

ブルーグリーンデプロイ構成モデル

以下のようなアーキテクチャで動作させます。各コンポーネントの役割と設計意図を明確にします。

• アプリケーション: ArgoCDで管理されるKubernetesデプロイメント
• 環境分離: BlueとGreenそれぞれに独立したDeployment/Serviceを配置（通信制限はNetworkPolicyで実装）
• トラフィック制御: RolloutsのTrafficSplit機能で配分比率を変更し、手動切替を可能に

注意事項: NetworkPolicyやKEDAの設定はクラスタ環境に依存するため、具体的な導入方法は各クラスタドキュメントを参照してください。

連携環境構築手順と前提条件

ArgoCDとRolloutsの統合には、クラスタ環境やアプリケーションの準備が必要です。以下のステップを順に実施してください。

Kubernetesクラスターの事前設定

1. クラスタアクセス確認: kubectl get nodesで接続可能かテストします。

2. Namespace作成: BlueとGreenを分離するため、argo-blueとargo-greenを作成します。
   bash
kubectl create namespace argo-blue
kubectl create namespace argo-green

3. ネットワーク制限の設定:

4. 各Namespace間の通信はNetworkPolicyで隔離（例: 具体的なポリシーテンプレートはクラスタ依存）
5. 代替ソリューション: IstioやCalicoなどのネットワークオーケストレーションツールも検討可能

Helmチャートとの統合方法

ArgoCDはHelmチャートをサポートしており、以下のように定義できます。

代替アプローチ: Helm以外にもKustomizeや直接YAML管理も可能です。

リソース管理とコスト削減の最適化

リソース効率は運用コストに直結します。以下に具体的な設計例を示します。

Service/Deploymentの二重定義パターン

ブルーグリーン環境それぞれに独立したサービスを作成し、トラフィック配分を制御します。

• Blue環境: service-blue.yamlで定義（既存PVC再利用が必要な場合も考慮）
• Green環境: service-green.yamlで定義
• 共有Service: service-main.yamlでTrafficSplitを使用し、配分率を変更（手動切替が可能に）

ローリングアップデート時のステートフル管理

StatefulSetやVolumeClaimTemplateの使用には注意が必要です。

1. PVCの再利用: 既存のPersistentVolumeを新環境に引き継ぐように設定（例: volumeName指定）
2. Replica制御: RolloutSpecでレプリカ数と配分比率を明示的に定義（例: レプリカを2つずつ保持）
3. 代替ソリューション比較:
4. Flux + Kustomize: よりシンプルなデプロイフローも可能
5. GitOps vs IaC: 複雑な環境ではIaCツールとの連携が必要

トラフィックシフトの自動化設定

RolloutsのTrafficSplit機能で効率的なトラフィック移行が可能です。

RolloutSpec構成例と設計意図

以下は、ブルーグリーンデプロイを実装するためのrollout.yamlの基本構成です。各パラメータの設計意図を明記します。

プログレッシブデリバリーのパラメータ調整

進捗率や健康チェックの条件をカスタマイズします。

代替アプローチ: livenessProbeとreadinessProbeの併用で信頼性向上も可能

ロールバックフローと手動切り替えの設計

緊急時におけるロールバックプロセスや手動でのトラフィック制御を明確にします。

自動リトライ制御設定

Argo Rolloutsはデフォルトで自動リトライを行いますが、特定ケースでは無効化が必要です。

1. リトライ回数: retryLimitを0に設定し、自動リトライを停止（緊急時対応向け）

2. エラーメッセージ出力: ロールアウトが失敗した際の詳細なログを出力（例: kubectl rollout status -n argo-blue my-app-rollout）

3. Emergency Rollback用のStableバージョン固定:
   bash
# ステップ1: 同期設定
argocd app set <アプリ名> --sync-policy auto

# ステップ3: 権限制限（管理者専用）
kubectl create rolebinding manual-rollback -n argo-blue --clusterrole=argo-rollouts:rollout-undo --serviceaccount=default:argocd


インフラコスト削減のベストプラクティス

ブルーグリーンデプロイにおけるリソース効率化を図ります。

ノードプールの動的スケーリング

Blue環境に余剰なレプリカがある場合、KEDA（Kubernetes Event-Driven Autoscaler）でノード数を自動調整します。ただし、クラスタ依存のため注意が必要です。

• 監視対象: CPU使用率やトラフィック量
• 削減効果: 非ピーク時にレプリカを最小化し、コストを抑える

代替アプローチ: Horizontal Pod Autoscaler（HPA）も同様の目的に利用可能

Unusedリソースの自動検出メカニズム

定期的に不用なリソースを検出し、削除するためにはTerraform + ArgoCDによるポリシー管理が有効です。

1. Terraformで定義したResource配列: 未使用リソースを特定し、terraform destroyで削除
2. ArgoCDのGitOps: リポジトリに自動更新された設定ファイルを同期させ、リソースの状態を管理

まとめと代替アプローチ比較

ブルーグリーンデプロイの実装にはArgoCD + Argo Rolloutsの連携が不可欠です。トラフィック制御はTrafficSplitで明示的に設定し、手動切り替えを可能にします。コスト削減にはKEDAやTerraformによる自動スケーリングが効果的です。

代替ソリューション比較

これらのアプローチを比較検討し、プロジェクトのニーズに最適な選択を行いましょう。