Q39: Progressive Delivery & Release Strategies: Blue/Green vs. Canary vs. Shadow / Mirroring with Argo Rollouts. - DevOps & Kubernetes (50 Qs)

Progressive Delivery Patterns

Deploying directly to 100% of user traffic introduces severe blast-radius risk. Progressive delivery mitigates this by validating software against live traffic before full promotion.

ini

1. Blue/Green Deployment:
   [ Load Balancer ] ---> [ Blue Environment (v1 - Active) ]
   (Switches 100% to) ---> [ Green Environment (v2 - Idle -> Active) ]

2. Canary Deployment (Percentage-Based):
   [ Load Balancer ] --- 95% Traffic ---> [ Stable Deployment (v1) ]
                     ---  5% Traffic ---> [ Canary Deployment (v2) ] (Monitors Prometheus metrics)

3. Traffic Shadowing / Mirroring:
   [ Envoy Proxy ] --- 100% Production Traffic ---> [ Production App (v1) ]
                   --- Shadow Copy (Async)     ---> [ Test App (v2 - Discards responses) ]

Production Canary Automation with Argo Rollouts

Argo Rollouts replaces the standard Kubernetes Deployment controller, evaluating real-time Prometheus SLIs to automatically promote or roll back releases:

yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  replicas: 10
  strategy:
    canary:
      analysis:
        templates:
          - templateName: error-rate-analysis
        args:
          - name: service-name
            value: payment-service
      steps:
        - setWeight: 10 # Route 10% traffic to canary
        - pause: { duration: 5m } # Wait 5 minutes for metrics
        - setWeight: 50 # If error rate < 0.5%, promote to 50%
        - pause: { duration: 10m }