Argo Rollouts

Progressive Delivery Blue-Green Canary Analysis Rollback

A comprehensive guide to Argo Rollouts covering progressive delivery, blue-green, canary, analysis, rollback, and practical implementation strategies for Kubernetes.

Progressive Delivery Blue-Green Canary Analysis

What is Argo Rollouts?

Argo Rollouts is a Kubernetes controller that provides advanced deployment capabilities such as canary, blue-green, and progressive delivery strategies. It extends Kubernetes with a Rollout custom resource that supports traffic management, metric analysis, and automated rollbacks.

Argo Rollouts is the recommended tool for progressive delivery on Kubernetes, offering features like:

Canary Deployments: Gradually increase traffic to the new version
Blue-Green Deployments: Instant switch between environments
Metric Analysis: Automatically evaluate success criteria
Automated Rollbacks: Rollback when metrics degrade
Traffic Management: Integration with Istio, NGINX, AWS ALB, and more

Key Principle: Argo Rollouts enables progressive delivery—gradually rolling out new versions with real-time analysis and automated decision-making, reducing risk and enabling faster deployments.

Argo Rollouts Components

Rollout CRD

Advanced deployment controller

The Rollout custom resource replaces Deployment for advanced strategies. It manages the desired state, tracks progress, and handles canary/blue-green logic.

Custom deployment orchestration

AnalysisTemplate

Metric evaluation

AnalysisTemplates define metrics, thresholds, and evaluation intervals. They can be reused across different Rollouts for consistent analysis.

Metric-based success evaluation

AnalysisRun

Instance of analysis

An AnalysisRun is created from an AnalysisTemplate to evaluate a specific rollout step. It tracks the results and determines success or failure.

Real-time metric evaluation

Traffic Router

Traffic management integration

Traffic routers (Istio, NGINX, AWS ALB, SMI) control how traffic is split between versions during canary deployments.

Traffic splitting

Installing Argo Rollouts

                # Install Argo Rollouts
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# Install kubectl plugin
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# Verify installation
kubectl get pods -n argo-rollouts
kubectl argo rollouts version
            

Prerequisites:

Kubernetes 1.16+
Service mesh (Istio) or ingress controller for traffic management
Prometheus for metrics analysis (optional)

Canary Deployment with Argo Rollouts

Canary deployments gradually roll out a new version to a subset of users, allowing real-world validation before full rollout.

                # Canary Rollout with Istio
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary-rollout
spec:
  replicas: 5
  strategy:
    canary:
      maxSurge: 1
      maxUnavailable: 0
      steps:
      - setWeight: 10      # Start with 10% traffic
      - pause: {duration: 30s}
      - setWeight: 25
      - pause: {duration: 1m}
      - setWeight: 50
      - pause: {duration: 2m}
      - setWeight: 100     # Full rollout
      trafficRouting:
        istio:
          virtualService:
            name: rollout-vs
            routes:
            - primary
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2
        ports:
        - containerPort: 8080

# Istio VirtualService for traffic splitting
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: rollout-vs
spec:
  hosts:
  - myapp-service
  http:
  - route:
    - destination:
        host: myapp-stable
        subset: stable
      weight: 90
    - destination:
        host: myapp-canary
        subset: canary
      weight: 10

# Service configuration
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
            

Canary Best Practices:

Start with very low traffic (1-5%) for high-risk changes
Use pauses to monitor metrics at each step
Integrate metric analysis for automated rollback
Use traffic routing for fine-grained control
Monitor canary health during rollout

Blue-Green Deployment

Blue-green deployments maintain two environments (blue=current, green=new) and switch traffic instantly after validation.

                # Blue-Green Rollout
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: bluegreen-rollout
spec:
  replicas: 3
  strategy:
    blueGreen:
      activeService: active-svc
      previewService: preview-svc
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 60
      previewReplicaCount: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2
        ports:
        - containerPort: 8080

# Active Service (production)
apiVersion: v1
kind: Service
metadata:
  name: active-svc
spec:
  selector:
    app: myapp
    # color: active  # Added by Rollout
  ports:
  - port: 80
    targetPort: 8080

# Preview Service (testing)
apiVersion: v1
kind: Service
metadata:
  name: preview-svc
spec:
  selector:
    app: myapp
    # color: preview  # Added by Rollout
  ports:
  - port: 80
    targetPort: 8080

# Promote manually after validation
kubectl argo rollouts promote bluegreen-rollout

# View rollout status
kubectl argo rollouts get rollout bluegreen-rollout
            

Blue-Green Best Practices:

Use autoPromotionEnabled: false for manual validation
Set scaleDownDelaySeconds for graceful shutdown
Use previewReplicaCount to save costs during validation
Integration with analysis for automated promotion
Test the green environment thoroughly before switching

Metric Analysis for Automated Decisions

Analysis allows Argo Rollouts to automatically evaluate metrics and make decisions based on real-time data.

                # AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  - name: namespace
  metrics:
  - name: success-rate
    interval: 30s
    successCondition: result[0] > 0.95
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{service="{{args.service-name}}", namespace="{{args.namespace}}", status!~"5.."}[1m]))
          /
          sum(rate(http_requests_total{service="{{args.service-name}}", namespace="{{args.namespace}}"}[1m]))

# Rollout with Analysis
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 30s}
      - analysis:
          templates:
          - templateName: success-rate
          args:
          - name: service-name
            value: myapp-service
          - name: namespace
            value: default
      - setWeight: 25
      - pause: {duration: 1m}
      - analysis:
          templates:
          - templateName: success-rate
          args:
          - name: service-name
            value: myapp-service
          - name: namespace
            value: default
      - setWeight: 100

# Multiple metrics in analysis
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: comprehensive-analysis
spec:
  metrics:
  - name: success-rate
    interval: 30s
    successCondition: result[0] > 0.95
    failureLimit: 3
    provider:
      prometheus:
        query: "..."
  - name: latency
    interval: 30s
    successCondition: result[0] < 200
    failureLimit: 3
    provider:
      prometheus:
        query: "histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[1m])) by (le))"
            

Analysis Best Practices:

Define meaningful success conditions (error rate, latency)
Set appropriate failure limits (allow occasional spikes)
Use interval to control analysis frequency
Combine multiple metrics for comprehensive analysis
Test analysis templates in staging first

Automated Rollback

Argo Rollouts can automatically rollback when metrics degrade or analysis fails.

                # Rollout with automated rollback
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 30s}
      - analysis:
          templates:
          - templateName: success-rate
          args:
          - name: service-name
            value: myapp-service
          - name: namespace
            value: default
          startingStep: 2  # Step to start analysis from
      maxSurge: 1
      maxUnavailable: 0
  progressDeadlineSeconds: 600
  revisionHistoryLimit: 2

# Analysis with rollback behavior
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 30s
    successCondition: result[0] > 0.95
    failureCondition: result[0] < 0.80
    failureLimit: 3
    provider:
      prometheus:
        query: "..."

# Rollback commands
# Abort current rollout (rollback)
kubectl argo rollouts abort canary-rollout

# Promote to stable
kubectl argo rollouts promote canary-rollout

# Check rollout status
kubectl argo rollouts get rollout canary-rollout

# View rollout history
kubectl argo rollouts history canary-rollout
            

Rollback Considerations:

Analysis failure triggers automatic rollback
Manual rollback is available via abort
Rollback is safe—only affects the Rollout resource
Monitor rollback events for visibility
Test rollback procedures regularly

Traffic Router Integration

                # NGINX Ingress Traffic Router
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-canary
spec:
  strategy:
    canary:
      trafficRouting:
        nginx:
          stableIngress: stable-ingress
          additionalIngress:
          - canary-ingress
          annotationPrefix: canary
      steps:
      - setWeight: 10
      - pause: {duration: 30s}

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: stable-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: myapp-stable
            port: 80

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: myapp-canary
            port: 80

# AWS ALB Traffic Router
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: alb-canary
spec:
  strategy:
    canary:
      trafficRouting:
        alb:
          ingress: alb-ingress
          rootService: myapp-root
          servicePort: 80
      steps:
      - setWeight: 10
      - pause: {duration: 30s}
            

Traffic Router Support:

Istio: Full support with VirtualService
NGINX Ingress: Canary annotations
AWS ALB: Weighted target groups
SMI: Traffic splitting
Envoy: Traffic routing

Argo Rollouts vs Kubernetes Deployments

Feature	Kubernetes Deployment	Argo Rollouts
Rolling Update	Yes	Yes (canary, blue-green)
Canary	No	Yes
Blue-Green	No	Yes
Traffic Management	No	Yes (Istio, NGINX, ALB)
Metric Analysis	No	Yes
Automated Rollback	No	Yes
Pause/Resume	Yes (limited)	Yes (full)
Complexity	Low	Medium

When to Use Argo Rollouts:

Need canary or blue-green deployments
Require metric-based analysis for deployment decisions
Want automated rollback on failures
Need fine-grained traffic management
Implementing progressive delivery

Frequently Asked Questions

What is the difference between Argo Rollouts and Kubernetes Deployments?

Argo Rollouts extends Kubernetes Deployments with advanced progressive delivery capabilities: canary, blue-green, metric analysis, and automated rollback. Deployments only support rolling updates.

Can I use Argo Rollouts with ArgoCD?

Yes! ArgoCD can manage Rollout resources as part of your GitOps workflow. ArgoCD will sync and apply Rollout definitions, and Argo Rollouts will handle the progressive delivery logic.

What traffic routers are supported?

Argo Rollouts supports Istio, NGINX Ingress, AWS ALB, SMI (Service Mesh Interface), and Envoy. Integration is done via traffic routing plugins.

How does metric analysis work?

Analysis evaluates metrics (error rate, latency) against success conditions. If metrics degrade, the rollout can be automatically paused or rolled back. Prometheus and DataDog are supported as providers.

How do I rollback a Rollout?

Use `kubectl argo rollouts abort <rollout-name>` to abort the current rollout and rollback to the stable version. You can also use `kubectl argo rollouts promote` to promote the new version.

What is the difference between canary and blue-green?

Canary gradually increases traffic to the new version. Blue-green instantly switches traffic between two identical environments. Canary is more risk-averse; blue-green is faster.

Can I use Argo Rollouts with Helm?

Yes! Argo Rollouts works with Helm. You can template Rollout resources using Helm and deploy them with ArgoCD. Helm can also be used to manage Rollout configurations.

What are the prerequisites for Argo Rollouts?

Kubernetes 1.16+, a service mesh or ingress controller for traffic management, and optionally Prometheus for metric analysis. The kubectl plugin is recommended for CLI operations.

Previous: CI/CD Pipelines Next: Flux CD

Argo Rollouts enables advanced progressive delivery strategies for Kubernetes. Implement canary or blue-green deployments with metric analysis to reduce risk and accelerate deployments.