Argo Rollouts
itCloud native tools and technologies
Argo Rollouts
Argo Rollouts is a Kubernetes controller for controlled application releases. It manages Rollout resources and their ReplicaSets through canary or blue-green strategies.
The central mental model is exposure controlled by evidence.
new pod template
|
v
new ReplicaSet -> limited exposure -> evidence -> promote or abort
| | |
+----------- Rollout controller --+
A Kubernetes Deployment can replace Pods gradually. Argo Rollouts adds explicit stages, traffic control, metric analysis, experiments, manual judgment, and automated failure handling.
Argo Rollouts does not build an image or choose a safe release policy for you. It executes the strategy and analysis rules that you declare.
The control loop
A Rollout resembles a Deployment. It has a selector, replica count, and Pod template. A change to spec.template creates a new ReplicaSet.
The Rollout controller then compares actual state with the selected strategy. It scales ReplicaSets, advances steps, updates Service selectors, and adjusts configured traffic-router resources.
The controller recognizes two important revisions:
- stable ReplicaSet — the last version that completed promotion;
- new ReplicaSet — the version currently moving through the strategy.
Stable is a controller status, not a claim that the application has no defects. Your probes, analysis, and operating process supply the evidence behind promotion.
The first creation behaves differently from an update. The controller scales the first ReplicaSet to steady state without running the progressive strategy. The strategy applies once a stable ReplicaSet exists.
Canary: increase exposure in stages
A canary strategy exposes the new ReplicaSet gradually. Its steps list can change weight, pause, run analysis, or start an experiment.
stable 100% -> canary 10% -> observe -> canary 25% -> observe -> promote
| |
+---- failure -> abort ---+
Without a traffic router, setWeight changes the ratio of stable and canary Pods. Kubernetes Service routing then distributes requests across those Pods. Replica rounding makes the requested percentage approximate, especially at low replica counts.
With a traffic router, the controller changes routing configuration independently from replica counts. This enables finer percentages and, for supported integrations, header routes or mirrored traffic.
Traffic routing adds dependencies. You need separate stable and canary Services, a supported router configuration, enough capacity for each traffic share, and observability that distinguishes both versions.
By default, traffic-routed canaries keep the stable ReplicaSet fully scaled during the update. That preserves fast abort behavior but can raise capacity cost. dynamicStableScale trades some rollback speed for lower resource use.
Blue-green: prepare, then switch
A blue-green strategy runs the old and new ReplicaSets at the same time. An active Service sends production traffic to stable. An optional preview Service reaches the new version before promotion.
The controller changes each Service selector by adding the target ReplicaSet hash. Promotion switches the active Service to the new ReplicaSet.
Blue-green gives you a clear cutover point. It is often easier to adopt because production traffic reaches only one version at a time. It still requires enough capacity for both versions during the transition.
Pre-promotion analysis can test the preview before cutover. Post-promotion analysis can check the live result. A failing post-promotion analysis aborts the Rollout and returns traffic to the previous stable ReplicaSet.
The old ReplicaSet remains available for a scale-down delay after promotion. This delay gives network providers time to update before old Pods disappear.
Analysis turns signals into decisions
An AnalysisTemplate defines one or more measurements and the conditions that classify their results. A ClusterAnalysisTemplate makes the template reusable across namespaces.
An AnalysisRun is one execution of a template. It can query a metric provider, call a web endpoint, or run a Kubernetes Job. Its result can be successful, failed, inconclusive, or erroneous.
The result changes Rollout behavior:
| Result | Typical Rollout effect |
|---|---|
| Successful | Continue or complete promotion |
| Failed | Abort the update |
| Inconclusive | Pause for manual judgment |
| Error | Follow the analysis failure behavior; often abort |
Background analysis runs while canary steps advance. Inline analysis blocks at a specific step. Blue-green analysis can run before or after promotion.
An analysis rule is only as good as its signal. A high success rate can hide slow responses. A low error count may be meaningless at low request volume. Use thresholds, intervals, and failure limits that match the application's traffic and risk.
Start metrics in dry-run mode. A dry-run metric records results without changing the Rollout outcome. This reveals query errors and noisy thresholds before they control production traffic.
Experiments create temporary comparison stacks
An Experiment runs one or more temporary ReplicaSets. It can start AnalysisRuns beside them and optionally create Services.
A canary step can block on an Experiment. The common pattern runs baseline and canary templates together, then compares their measurements under similar conditions.
Experiments are temporary release evidence, not permanent multiversion hosting. They finish after their duration or required analyses, then scale their ReplicaSets to zero.
Promotion, pause, abort, and rollback
A timed pause resumes when its duration expires. An indefinite pause waits for a promotion action.
promote advances one paused step. Full promotion skips remaining steps and analysis, so reserve it for an explicit incident or override procedure.
abort stops the update and returns serving traffic to the stable ReplicaSet. The Rollout remains degraded because the declared Pod template still describes the rejected version.
To restore healthy desired state, apply a known-good template or a fixed forward version. Argo Rollouts does not change Git. A GitOps controller still sees the same Rollout specification after an abort.
Reapplying an older specification normally creates another update and repeats its steps. A configured rollback window can fast-track recent revisions by skipping those steps.
Where Argo Rollouts fits
Argo Rollouts fits applications that:
- run on Kubernetes;
- release frequently enough to justify a controlled process;
- can run old and new versions together when using canary;
- expose useful health or business metrics quickly;
- have reversible traffic and application behavior;
- can tolerate the additional controller, routing, and analysis dependencies.
It is a weaker fit for infrastructure controllers, queue workers with unsafe concurrent versions, or applications that write incompatible shared state. It also targets one workload in one cluster. It does not coordinate dependencies across several services or clusters.
Canary does not make an incompatible database migration safe. Old and new application versions may run concurrently. Design schemas and APIs for that overlap before shifting traffic.
Argo Rollouts is standalone. It does not require Argo CD or GitOps. Argo CD can apply a Rollout and understand its health, while Argo Rollouts manages the live release transition.
A path to competent use
- Learn stable, new, weight, pause, promotion, abort, and analysis outcomes.
- Run the official basic canary in a disposable cluster and watch each ReplicaSet change.
- Abort a release and reconcile desired state back to a known-good template.
- Try blue-green with active and preview Services.
- Add a dry-run analysis using a signal you already trust.
- Test failed, inconclusive, and unavailable metric-provider cases.
- Add traffic routing only after you can observe routing state and both application versions.
- Rehearse controller upgrades, capacity loss, failed promotion, and GitOps recovery before production adoption.