Progressive Delivery on Kubernetes with Argo Rollouts

Kubernetes' default RollingUpdate is fine until a bad version rolls out to everyone before anyone notices. Progressive delivery ships changes gradually, watches real metrics, and rolls back automatically if things degrade. Argo Rollouts is how you do it.

Why rolling updates aren't enough

A Deployment's rolling update swaps pods a few at a time, but it only checks that new pods become ready, not that they're actually healthy in production. A version that passes readiness probes but returns 500s to 5% of users will still roll out completely. You find out from your users.

What Argo Rollouts adds

Rollouts is a drop-in replacement for Deployment (a Rollout CRD) that adds:

• Canary deployments: shift a small % of traffic to the new version, then increase in steps.
• Blue-green deployments: run the new version alongside the old, switch traffic at once.
• Automated analysis: query Prometheus (or others) between steps and auto-rollback if a metric breaches a threshold.

A canary example

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: error-rate
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 100

10% of traffic goes to the new version; after 5 minutes an AnalysisTemplate checks the error rate; if it's healthy, traffic ramps to 50%, then 100%. If not, it rolls back automatically.

Analysis: the part that matters

The magic is gating each step on real signals:

kind: AnalysisTemplate
spec:
  metrics:
    - name: error-rate
      successCondition: result < 0.05
      provider:
        prometheus:
          query: |
            sum(rate(http_requests_total{job="myapp",status=~"5.."}[2m]))
              / sum(rate(http_requests_total{job="myapp"}[2m]))

If the 5xx rate of the canary exceeds 5%, the rollout fails and reverts, no human in the loop, no 3am page for a deploy you could have caught automatically. (Pair it with the observability-stack for the metrics.)

Canary vs blue-green

• Canary: gradual traffic shift, smallest blast radius, best for high-traffic services where you want to limit exposure. Needs a traffic manager (Istio, ALB, NGINX) for fine-grained weights.
• Blue-green: instant switch with instant rollback, simpler to reason about, but the new version serves 100% the moment you cut over. Good when you can't do partial traffic.

Fitting it into GitOps

Argo Rollouts pairs naturally with ArgoCD: commit the new image tag, ArgoCD syncs the Rollout, and Rollouts handles the progressive rollout with analysis. Your delivery is then: commit → gradual, metric-gated rollout → automatic promote or rollback. (See my gitops-kubernetes-platform.)

When it's worth it

• Yes: high-traffic, customer-facing services where a bad deploy hurts.
• Overkill: internal tools, low-traffic services, early-stage projects: a plain rolling update is fine. Don't add machinery you won't benefit from.

Progressive delivery turns "deploy and pray" into "deploy and verify." For the services that matter, it's the difference between catching a regression at 10% of traffic and catching it from an incident.

---

Want safe, automated deployments on Kubernetes? That's part of my consulting, reach out.