Every Deployment Strategy, with Argo Rollouts

1. 1

   Install the controller and kubectl plugin

   Add an Application for the argo-rollouts chart (https://argoproj.github.io/argo-helm) into namespace argo-rollouts, like ESO in Mission 2.1. The kubectl plugin gives you a live terminal view of rollouts. Argo CD understands Rollout health natively.

   terminalcopy cmd

   $ brew install argoproj/tap/kubectl-argo-rollouts # or download from GitHub releases

   kubectl -n argo-rollouts get pods

   ── expected output ──

   NAME READY STATUS

   argo-rollouts-6d8f9c7b5-x4k2p 1/1 Running

2. 2

   Two Services: stable and canary

   The Rollout rewrites these Services' selectors (adding a pod-template-hash) so each one points at exactly one version, and the Ingress controller splits traffic between them. Duplicate service.yaml into web-stable and web-canary with identical selectors.

   apiVersion: v1
   kind: Service
   metadata:
     name: web-stable
   spec:
     selector: { app: web }
     ports: [{ port: 80, targetPort: 80 }]
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: web-canary
   spec:
     selector: { app: web }
     ports: [{ port: 80, targetPort: 80 }]

3. 3

   The Ingress that receives weighted traffic

   You only write the stable Ingress. Rollouts creates a canary Ingress next to it with NGINX's canary-weight annotation and updates the weight at each step.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: web
   spec:
     ingressClassName: nginx
     rules:
       - host: shop.local
         http:
           paths:
             - path: /
               pathType: Prefix
               backend:
                 service: { name: web-stable, port: { number: 80 } }

4. 4

   Define 'healthy' as a query

   Success rate of the canary's requests, from the NGINX Ingress metrics you scraped in the Observability course. Checked every minute; three failures abort. inconclusive results (no traffic yet) pause rather than fail.

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

5. 5

   Replace the Deployment with a Rollout

   The pod template is unchanged from the Deployment. Only kind and strategy differ. Background analysis runs from step 1; the steps shift traffic 10 → 30 → 60 → 100 with pauses. pause: {} with no duration waits for a human to promote, which is useful before the final step in prod.

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: web
   spec:
     replicas: 4
     revisionHistoryLimit: 3
     selector:
       matchLabels: { app: web }
     template:
       metadata:
         labels: { app: web }
       spec:
         containers:
           - name: web
             image: nginxdemos/hello:0.3
             ports: [{ containerPort: 80 }]
             readinessProbe: { httpGet: { path: /, port: 80 } }
             resources:
               requests: { cpu: 50m, memory: 32Mi }
               limits: { memory: 64Mi }
     strategy:
       canary:
         stableService: web-stable
         canaryService: web-canary
         trafficRouting:
           nginx:
             stableIngress: web
         analysis:
           templates: [{ templateName: success-rate }]
           startingStep: 1
           args:
             - name: canary-service
               value: shoplite-prod-web-canary-80
         steps:
           - setWeight: 10
           - pause: { duration: 2m }
           - setWeight: 30
           - pause: { duration: 3m }
           - setWeight: 60
           - pause: { duration: 5m }

6. 6

   Ship a canary and watch it

   Bump the tag in the overlay and push, exactly as before, because the GitOps flow doesn't change. Rollouts takes over once Argo applies the new spec.

   terminalcopy cmd

   $ cd apps/web/overlays/prod && kustomize edit set image nginxdemos/hello=nginxdemos/hello:0.4 && cd -

   git commit -am 'web(prod): canary 0.4' && git push

   kubectl argo rollouts get rollout web -n shoplite-prod --watch

   ── expected output ──

   Name: web

   Status: ॥ Paused

   Message: CanaryPauseStep

   Strategy: Canary

   Step: 1/6

   SetWeight: 10

   ActualWeight: 10

   Images: nginxdemos/hello:0.3 (stable)

   nginxdemos/hello:0.4 (canary)

   Replicas:

   Desired: 4

   Current: 5

    

   ⟳ web Rollout ॥ Paused

   ├──# revision:2

   │ ├──⧉ web-6c7d8e9f5 ReplicaSet ✔ Healthy canary

   │ └──α web-6c7d8e9f5-2 AnalysisRun ◌ Running

   └──# revision:1

   └──⧉ web-5b6c7d8e4 ReplicaSet ✔ Healthy stable

7. 7

   Blue-green for checkout

   Checkout talks to the payment provider, and the team wants the entire new version tested before any real user sees it. Blue-green gives a preview Service for smoke tests (prePromotionAnalysis), then an instant switch. The old ReplicaSet stays up for scaleDownDelaySeconds so rollback is instant too.

     strategy:
       blueGreen:
         activeService: checkout-active       # real users
         previewService: checkout-preview     # QA + smoke tests
         autoPromotionEnabled: false          # a human (or analysis) promotes
         prePromotionAnalysis:
           templates: [{ templateName: smoke-test }]
         scaleDownDelaySeconds: 600

   terminalcopy cmd

   $ kubectl argo rollouts promote checkout -n shoplite-prod

   ── expected output ──

   rollout 'checkout' promoted

Make each change, run the command, and read the error before revealing the diagnosis. Recognising these messages on sight is what makes you fast on a real team. Undo the change afterwards.