How Argo Rollouts Works: Canary & Blue-Green Strategies

Introduction: what Argo Rollouts actually does

Argo Rollouts is more than just “another way to deploy to Kubernetes.” It changes how traffic flows to new versions of your app so you can expose changes gradually instead of flipping everything at once.

Instead of updating a Deployment and immediately sending 100% of users to a new ReplicaSet, Argo Rollouts creates a dedicated Rollout object. The Rollouts controller then walks through a series of steps you define: spinning up new pods, shifting a slice of traffic, pausing, checking metrics, and either promoting or rolling back.

To understand how Argo Rollouts works, it helps to break it down into three core pieces:

• The Rollout resource that replaces a standard Deployment.
• The strategies it supports are mainly Canary and Blue-Green.
• The way it integrates with traffic management layers like ingress controllers and service meshes.

What Is a Rollout Resource in Argo Rollouts?

A Rollout is a Kubernetes Custom Resource that is very similar to a Deployment. It has a pod template, replica count, labels, and selectors. The difference is that it also includes a strategy section that describes how to migrate from the old version to the new one.

Under the hood, when you apply a Rollout manifest:

• The Argo Rollouts controller watches for changes to Rollout objects.
• It creates and owns ReplicaSets representing your stable version and your canary or preview version.
• It coordinates traffic routing between those ReplicaSets using your configured ingress or service mesh.

You still use standard Kubernetes objects, Services, ReplicaSets, Ingresses, but the Rollouts controller becomes the brain orchestrating them.

How does a Rollout progress?

Each time you update the Rollout’s pod template (for example, a new Docker image tag), the controller:

1. Creates a new ReplicaSet for the updated version.
2. Scales that ReplicaSet up according to your strategy.
3. Adjusts traffic weights between the old and new ReplicaSets.
4. Pauses at configured “gates” for manual checks or automated analysis.
5. Either promotes the new version to 100% or rolls it back.

The exact behavior depends on whether you choose a canary or blue‑green strategy.

How canary deployments work in Argo Rollouts

In a canary rollout, you gradually shift traffic from the stable version to the new one in small increments.

In the Rollout spec, you define a list of steps. Each step can:

• Increase the traffic weight to the canary (for example from 5% to 20%).
• Pause for a fixed duration or until a human manually resumes.
• Run an analysis to check metrics before moving on.

A simple canary might look like: 5% → 20% → 50% → 100%, with a pause after each jump.

Pauses and manual promotion

Pauses are where humans regain control over automated pipelines. During a pause, the stable version still serves most traffic, while a small percentage hits the canary.

Operators or SREs can:

• Inspect dashboards and logs.
• Validate that critical user flows still behave as expected.
• Decide to continue, hold, or abort.

When things look healthy, they unpause the Rollout (for example via kubectl argo rollouts resume) and the controller proceeds to the next step.

Automated analysis and rollbacks

Argo Rollouts also supports analysis runs. These are automated checks against external metrics systems (such as Prometheus, Datadog, or New Relic) that run at each step.

If an analysis run detects degraded metrics, higher error rates, increased latency, or failing business KPIs, the controller can automatically:

• Abort the rollout.
• Shift traffic back to the stable ReplicaSet.
• Mark the current version as failed for later investigation.

This closes the loop between deployment and observability and is the core of safe, progressive delivery.

How blue‑green deployments work in Argo Rollouts

Preview vs active services

In a blue‑green strategy, you keep a “blue” environment (current production) and a “green” environment (the new version) running side by side.

Argo Rollouts models this with two Services:

• A preview service that always points at the new ReplicaSet.
• An active service that continues to point at the stable ReplicaSet until you promote.

While the rollout is in preview, internal teams can hit the preview service URL to test the new version in a production‑like environment without exposing it to every user.

Promotion and instant switchovers

When you are ready to go live, you promote the rollout. The controller simply re‑points the active service from the blue ReplicaSet to the green one.

Because both environments are already warm and running, this switch can be nearly instantaneous. If you detect problems, you can roll back by pointing the active service back to the previous ReplicaSet.

When to choose blue‑green vs canary

Blue‑green shines when you:

• Need clear separation between old and new versions.
• Want a dedicated preview URL for business or QA testing.
• Prefer an instant cutover with a fast, manual decision.

Canary is better when you:

• Care about gradually ramping exposure.
• Want to validate behavior on a subset of real traffic.
• Rely heavily on metric‑driven automatic promotion and rollback.

Argo Rollouts supports both so you can align the strategy with each service’s risk profile.

Traffic Management and Routing in Argo Rollouts

Working with ingress controllers

To control how much traffic reaches each ReplicaSet, Argo Rollouts integrates with ingress controllers that support weighted routing. Common options include:

• NGINX Ingress
• AWS ALB Ingress Controller
• GKE Ingress and other controllers with canary annotations

The Rollouts controller updates ingress annotations to reflect the current traffic weights defined in your canary steps. For example, it might set the canary backend to 20% and the stable backend to 80%.

Working with service meshes

If you use a service mesh like Istio or Linkerd, Argo Rollouts can modify VirtualServices or similar routing objects.

In that case, the mesh handles:

• Splitting traffic between versions at the L7 layer.
• Applying advanced routing rules such as header‑ or cookie‑based routing.
• Enforcing retries, timeouts, and circuit breakers.

Argo Rollouts focuses on when to change weights, while the mesh focuses on how the traffic is actually forwarded.

Header and cookie-based canaries

Beyond simple percentages, you can also route specific user cohorts to the canary by matching headers or cookies.

Examples include:

• Only sending internal employees to the new version.
• Routing beta testers or early‑access customers via a special cookie.
• Targeting a subset of regions or partners.

This lets you run sophisticated experiments while keeping the overall rollout controlled.

Observability and Monitoring in Argo Rollouts

kubectl argo rollouts plugin

The kubectl argo rollouts plugin gives you a CLI tailored for managing rollouts. With it, you can:

• Watch rollouts live using kubectl argo rollouts get rollout <name> –watch.
• Promote, pause, or abort rollouts.
• Inspect analysis runs and their metric results.

This provides a human‑friendly interface on top of the controller’s internal state.

Argo Rollouts dashboard and ecosystem

Many teams also deploy the Argo Rollouts dashboard, which visualizes rollout status, traffic weights, and analysis outcomes.

Combined with your existing observability stack, Grafana, Kibana, or vendor dashboards, it becomes much easier to:

• Correlate rollout steps with metric changes.
• Explain to stakeholders what happened during a release.
• Build runbooks around common failure scenarios.

FAQs

Latest Post:

• How Argo Rollouts Works: Canary & Blue-Green Strategies
• Argo Rollouts Features: Blue-Green, Canary & Traffic Control
• Argo Rollouts vs Kubernetes Deployments: Key Differences & Benefits
• Is Argo Rollouts Safe? Security & Production Readiness Explained
• Business Use Cases for Argo Rollouts: Safe Deployments, KPIs & Continuous Delivery