How do you implement progressive delivery with ArgoCD Rollouts (canary/blue-green)?

Imagine deploying a new version of software like opening a new lane on a highway. With a standard Kubernetes Deployment, you instantly redirect all traffic to the new lane — if there is a pothole, every car hits it. A canary release is like opening the new lane to only five percent of traffic first, monitoring for incidents, then gradually increasing to twenty-five, fifty, and finally one hundred percent. A blue-green deployment is like building an entirely parallel highway, verifying it with test traffic, and then switching the exit ramp so all cars seamlessly move to the new road. Argo Rollouts provides the traffic controller that orchestrates these patterns with automated analysis and instant rollback capabilities.

Argo Rollouts extends Kubernetes with a Rollout custom resource that replaces the standard Deployment. The Rollout spec includes a strategy section where you define either a canary or blueGreen configuration. For canary deployments, you specify steps that control the rollout progression — setWeight to adjust traffic percentage, pause to wait for a duration or manual approval, and analysis to run automated metric checks. The Rollout controller manages two ReplicaSets: the stable version serving production traffic and the canary version receiving the configured percentage. Traffic splitting is achieved through integration with service mesh or ingress controllers including Istio, Linkerd, Nginx, ALB, SMI, Traefik, and Ambassador, each using their native traffic management primitives.

Internally, the Argo Rollouts controller watches Rollout resources and manages the rollout state machine. When a new image or spec change is detected, the controller creates a canary ReplicaSet and begins executing the defined steps sequentially. At each analysis step, the controller creates an AnalysisRun resource that queries configured metrics providers — Prometheus, Datadog, NewRelic, CloudWatch, or custom webhook providers — and evaluates the results against success criteria. If an AnalysisRun determines the canary is unhealthy based on error rate thresholds or latency percentiles, the controller automatically aborts the rollout and scales the canary ReplicaSet to zero, restoring all traffic to the stable version. For blue-green deployments, the controller maintains an active and preview Service, each pointing to different ReplicaSets. The preview Service receives the new version for testing, and upon promotion, the active Service selector is switched to point to the new ReplicaSet.

In production, teams typically integrate Argo Rollouts with ArgoCD by simply replacing the Deployment kind with Rollout in their Git manifests. ArgoCD recognizes the Rollout CRD and provides native health status tracking in its dashboard. A common pattern for the checkout-worker service is a canary strategy with five steps: set weight to ten percent, run a five-minute Prometheus analysis checking error rates and p99 latency, set weight to thirty percent, run another analysis for ten minutes, then set weight to one hundred percent. The AnalysisTemplate queries like rate(http_requests_total{status=~"5.*",service="checkout-worker"}[5m]) / rate(http_requests_total{service="checkout-worker"}[5m]) ensure the canary's error rate stays below the configured threshold before each promotion step.

The most critical gotcha is that Argo Rollouts traffic splitting only works if you have a supported traffic router configured. Without Istio VirtualServices, Nginx annotations, or another supported ingress controller, the weight-based traffic splitting has no effect and the canary just runs alongside the stable version without controlled traffic distribution — it falls back to basic replica-ratio-based splitting which is imprecise. Another common mistake is setting analysis intervals too short; a two-minute analysis window may not capture enough data points for statistically significant error rate calculations, leading to false positives that promote a bad canary. Engineers should also understand that argo rollouts differ from ArgoCD — they are separate projects with separate controllers, and you need both installed to get GitOps-driven progressive delivery.