Progressive Delivery with ArgoCD Rollouts allows you to deploy new versions of your applications without downtime, gradually shifting traffic to the new version while monitoring for issues.
Let’s see this in action with a simulated rollout. Imagine we have a simple web service deployed via Argo CD. We want to update it from v1.0.0 to v1.1.0.
Here’s a snippet of a Kubernetes Deployment that Argo CD might manage:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-web-app
spec:
replicas: 3
selector:
matchLabels:
app: my-web-app
template:
metadata:
labels:
app: my-web-app
spec:
containers:
- name: web-app-container
image: my-docker-repo/my-web-app:v1.0.0
ports:
- containerPort: 8080
Now, we introduce Argo CD Rollouts. The core component is the Rollout custom resource, which replaces the standard Deployment.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-web-app
spec:
replicas: 3
selector:
matchLabels:
app: my-web-app
template:
metadata:
labels:
app: my-web-app
spec:
containers:
- name: web-app-container
image: my-docker-repo/my-web-app:v1.1.0 # New image
ports:
- containerPort: 8080
strategy:
canary:
increments: [25, 50, 75] # Traffic shifts in 25% increments
steps:
- setWeight: 10
- pause: { duration: 5m } # Wait 5 minutes
- setWeight: 30
- pause: { duration: 5m }
- setWeight: 60
- pause: { duration: 5m }
- setWeight: 100
# Analysis can be added here to automatically promote/abort
# analysis:
# templates:
# - templateName: basic-success-rate
# args:
# - name: service-name
# value: my-web-app-service
# - name: namespace
# value: default
When Argo CD updates the spec.template.spec.containers[0].image in the Rollout resource to my-docker-repo/my-web-app:v1.1.0, the Rollouts controller kicks in. It doesn’t just replace all pods at once. Instead, it spins up a new set of pods with the v1.1.0 image, creating a "canary" deployment.
The strategy.canary.steps define the rollout process. Initially, setWeight: 10 means 10% of the traffic is directed to the new v1.1.0 pods, while 90% continues to go to the old v1.0.0 pods (which are managed by a separate ReplicaSet under the hood). The pause: { duration: 5m } step then holds the rollout for 5 minutes, giving you time to observe metrics.
During this pause, you’d typically check your monitoring dashboards. Look at error rates, latency, and business metrics for both the old and new versions. If everything looks good, the rollout proceeds to the next step, setWeight: 30, increasing traffic to v1.1.0 to 30%. This continues through the defined steps.
If at any point during a pause or after an automated analysis step, metrics indicate a problem (e.g., error rate spikes above 1%), the Rollout can be configured to automatically abort, scaling down the canary and promoting the stable version back to 100% of traffic. Alternatively, a manual kubectl argo rollouts promote my-web-app or kubectl argo rollouts abort my-web-app command can be used.
The increments field provides a higher-level view of the traffic shifting. In this example, the steps are explicitly defined, but increments can also be used to define a more automated sequence like [10, 30, 50, 75, 100]. The steps array provides finer-grained control, allowing for manual pauses and automated analysis checks between traffic shifts.
The mental model here is that you’re not just deploying code; you’re managing risk. Rollouts introduce a controlled experiment where the new version is tested on a small, isolated subset of users before being fully committed. The Rollout resource is the orchestrator, managing the lifecycle of the canary and stable versions, and the traffic routing between them, typically via an Ingress or Service Mesh integration.
What most people don’t realize is that the "stable" version during a canary deployment isn’t just a static backup. It’s an actively managed ReplicaSet that continues to serve traffic. When a canary is promoted, the old stable ReplicaSet is scaled down, and the successful canary ReplicaSet becomes the new stable ReplicaSet. This makes rollback incredibly fast because the "old" version is still running and ready to take over.
The next concept to explore is integrating automated analysis directly into the Rollout definition to make these decision points truly autonomous.