Argo Rollouts: Beyond Kubernetes Rolling Updates
Argo Rollouts replaces Kubernetes' basic RollingUpdate with safer, controlled strategies like canary and blue-green. It gradually shifts traffic to new versions while monitoring metrics, automating rollbacks if KPIs degrade.
Why it exists
The native Kubernetes Deployment object's RollingUpdate strategy is often too risky for production. It lacks fine-grained control over rollout speed and traffic flow, cannot query external metrics to verify an update's health, and cannot automatically roll back on failure. It provides little control over the blast radius, making it a blunt instrument for critical services.
The mental model
Think of Argo Rollouts as a smart traffic cop for your Kubernetes deployments. Instead of just replacing old pods with new ones, it stands at the intersection (your ingress or service mesh) and directs a small percentage of traffic to the new version. It then checks its monitors (Prometheus, Datadog) to see if key business metrics are healthy before gradually sending more traffic, ready to halt and revert at the first sign of trouble.
How it works
You define an Argo Rollout custom resource, which replaces the standard Deployment resource. This Rollout object manages ReplicaSets but adds advanced strategy options. For a canary deployment, you specify steps like 'send 10% of traffic to the new version, pause for 5 minutes, then run an analysis'. This analysis can query a metric provider to check error rates or latency. Argo Rollouts achieves this traffic shifting by integrating with and manipulating the configuration of a service mesh (like Istio) or an ingress controller (like NGINX or an AWS ALB).
When to use it
Use Argo Rollouts for critical, high-volume production services where a failed deployment has a significant user or business impact. It's essential when you want to de-risk releases by tying promotion to business KPIs (like conversion rates) or system KPIs (like P99 latency), not just basic pod readiness probes.
When not to use it
For simple applications, internal tools, or development environments, a standard Kubernetes RollingUpdate is often sufficient and simpler. If you don't use a compatible ingress controller or service mesh, you lose the primary benefit of traffic shaping and should stick with the native Deployment object.
One canonical example
A team uses a canary strategy for their checkout service. The Rollout CRD is configured to first shift 5% of traffic to the new version. It then pauses and runs an AnalysisRun that queries Prometheus for the new version's HTTP 5xx error rate. If the error rate remains below 0.1% for ten minutes, the rollout proceeds to 25% traffic. If the error rate spikes at any point, the rollout is automatically aborted and rolled back to the previous stable version.
Interview question
When would an engineering team most likely choose Argo Rollouts over a standard Kubernetes RollingUpdate strategy?
- a.To reduce the number of running pods during a deployment to save infrastructure costs.
- b.To ensure zero downtime for critical production services by instantly switching all traffic to the new version.
- c.When deploying simple, non-critical internal tools to a development cluster.
- d.To gradually shift traffic to a new application version, monitor its performance using external metrics, and automatically roll back on failure.Correct
Why? this is the answer
The card highlights that Argo Rollouts is chosen for critical services to enable gradual traffic shifting, monitor health with external metrics, and automate rollbacks, capabilities absent in native Kubernetes RollingUpdate. Option C describes a scenario where Argo Rollouts is explicitly not recommended.
Just read this? Test yourself on what you have been reading.
Read the original → argoproj.github.io
- #kubernetes
- #ci/cd
- #progressive delivery
- #devops
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles