Argo Rollouts – What Is It, How It Works & Tutorial

Argo Rollouts is a solution for performing progressive delivery of deployments to Kubernetes clusters. It helps you improve deployment reliability and performance using blue-green and canary rollouts.

This article will explain more about Argo Rollouts, how it works, and how to get started using it in your own cluster. We’ll finish by sharing a simple example of how to launch a canary rollout for a Kubernetes deployment.

What we will cover:

1. What is Argo Rollouts?
2. How does Argo Rollouts work — deployment strategies
3. Argo Rollouts use cases
4. Demo: How to use Argo Rollouts

Argo Rollouts is a Kubernetes tool that implements advanced rollout strategies for deployments in your cluster. This means using techniques such as blue-green deployments and canary deployments to gradually move traffic to a new app release instead of having all requests immediately switch over. It enables you to limit the damage caused by broken deployments because they’ll initially serve only a subset of users.

The tool is implemented as a Kubernetes controller and a collection of Custom Resource Definitions (CRDs). The main CRD is Rollout — it acts as a replacement for the Kubernetes Deployment object and allows you to define deployments that use the advanced update strategies that Argo provides. Without creating a Rollout, you can only use the rolling update and complete recreation deployment strategies that are included with Kubernetes.

When you add a Rollout object to your cluster, the Argo controller detects its presence and then creates, replaces, and removes Pods as required. You can then manage the rollout using Argo’s Kubectl plugin, such as exposing the new deployment to more users or initiating a rollback. These actions can also be automated based on data supplied by external sources — for example, HTTP request metrics collated by an Ingress controller or analysis of network activity exposed by your service mesh.

Although the Kubernetes Deployment object provides useful controls for simple scenarios, it’s not robust enough to support real-world rollouts at scale. Argo Rollouts adds the missing features that let you precisely manage rollout progression and automate more parts of your deployment workflow.

What is the difference between Argo CD and Argo Rollouts?

Argo Rollouts is often used in conjunction with Argo CD, the Argo project’s continuous delivery (CD) tool. Argo CD implements declarative GitOps-driven CD for Kubernetes, while Rollouts offers a controller and CRDs that let you robustly manage blue-green and canary deployments. You can use Argo Rollouts without ArgoCD, or vice versa, but combining them both produces a fully automated end-to-end workflow for safely deploying changes to your apps.

In this section, we will explain core concepts in Argo Rollout, the differences between the main supported rollout strategies, and the Argo Rollouts deployment workflow.

Understanding app rollout strategies

There are four main strategies used to roll out application changes. The one you select defines what happens when you launch a new version of an app into your Kubernetes cluster:

• Blue-Green — Blue-green deployments, available in Argo Rollouts, start the new version’s Pods but don’t direct any traffic to them. The old version (blue) remains live and continues to serve your production users. Developers can manually test against the new release (green) to verify it’s functioning correctly.
• Canary — Canary deployments start the new version and use it to handle a portion of live traffic. You can gradually increase the amount of traffic that’s served by the new release, allowing any problems to be detected and resolved before too many users experience them.
• Rolling Update — A rolling update starts the new deployment’s Pods, then gradually scales down the old deployment until only the new one is left running. (Note: This is the default behavior of regular Kubernetes Deployments.)
• Recreate — This strategy removes the old deployment from your cluster, then launches the new release and immediately exposes it to traffic. This can be advantageous when you’re introducing backward-incompatible changes that require a clean break to function correctly, but the gap between the old deployment stopping and the new one starting means some downtime will occur. (Note: Recreate is supported by regular Kubernetes Deployments.)

Because the Rolling Update and Recreate deployment strategies are already available in Kubernetes, Argo Rollouts is mainly used when you need Blue-Green or Canary deployments.

Argo Rollouts deployment workflow

The core Argo Rollouts workflow is as follows:

1. Deploy your new app release.
2. Test the new release.
   For blue-green deployments, this will be done by developers, whereas canary deployments will be tested by a small percentage of real users. As you gain confidence in the canary, you can increase the proportion of traffic that’s directed to it.
3. Once you’re sure the deployment has been successful, promote it to a full rollout.
   Argo will then remove the old deployment and ensure all traffic is directed to the new one. At this point, you can begin iterating on your next change, ready to repeat the cycle.

One of the key benefits of Argo Rollouts is that these steps can be automated, so you don’t have to keep checking your deployments before they proceed. For example, you could configure Argo to automatically increase the percentage of traffic that targets your canary deployment every 10 minutes, or specify that a rollout should be aborted if there’s a spike in HTTP error codes. This facilitates greater DevOps efficiency without compromising deployment reliability.

As we’ve outlined above, Argo Rollouts enables more advanced Kubernetes deployment techniques. Here are some key use cases:

• Expose new app releases to a limited group of users via blue-green or canary deployments.
• Take control over rollout speed and progression for example, by expanding access to an additional 20% of traffic each hour, but only if no errors have occurred.
• Automate rollbacks in the event of failures using metrics generated by external systems (such as request latency or failure data sourced from a Prometheus instance).
• Use GitOps and declarative configuration to define your deployment rollouts and easily apply changes using IaC methods.

These benefits illustrate how Argo Rollouts fills in the blanks left by the built-in Kubernetes Deployment object.

Let’s walk through a tutorial on how to use Argo Rollouts to implement a canary deployment workflow in your Kubernetes cluster.

Before continuing, ensure you’ve got Kubectl actively connected to a cluster. You’ll also need Helm to make it easier to install Argo Rollouts.

1. Install Argo Rollouts

First, register Argo’s Helm chart repository in your local Helm configuration:

Next, use Helm to install Argo Rollouts from its official chart:

Wait a few moments while Kubernetes pulls the required container images and starts your Pods.

In the meantime, run the following commands to add the Argo Rollouts Kubectl plugin to your local system:

You should now be able to run kubectl argo rollouts commands successfully:

Now, you’re ready to begin creating rollouts in your cluster!

2. Create a Rollout object

You need a Rollout object to configure the rollout strategy that will be used for your deployment. The Rollout should include either a template that configures the Pods to deploy or a reference to an existing Kubernetes Deployment. In this example, we’re creating the Deployment using a template within the Rollout object:

This Rollout object specifies that 10 replicas of a Pod running the nginx:latest container image will be deployed. The Canary rollout strategy is used with four different traffic weighting steps: on each rollout, 20% of Pods are replaced with the new deployment, then the rollout is paused until it’s manually resumed. Thereafter, the deployment is expanded to replace another 20% of Pods each minute, until an 80% rollout is achieved. 

At this point, you should promote the rollout so it becomes the new live one — we’ll see how to do this in the following steps.

3. Deploy the Rollout

Save the manifest shown above, then use Kubectl to create the Rollout object in your cluster:

Now you can use the kubectl get rollout command to monitor the rollout’s progress:

You can get more detailed information about the rollout by using the commands provided by the Argo Rollouts Kubectl plugin:

Because this is the deployment’s initial rollout, the canary stage is immediately progressed through all the steps defined in the manifest. This results in the 10 Pod replicas becoming available. 

Now, let’s see what happens when an update is applied.

4. Update the Rollout

Changing the container image that your Rollout deploys is an easy way to simulate a change to your application. Open the manifest you created above, then change the value of the spec.template.spec.containers.image field to nginx:1.24. This will cause an older NGINX version to be deployed.

Next, use Kubectl to apply the change to your cluster and initiate a new rollout:

You can now repeat the kubectl argo rollouts get rollout command to monitor the rollout’s progress:

You can see that two new Pods have been created in the canary stage, while eight old Pods have been retained. This is because our Rollout manifest specifies new deployments will only replace 20% of the Pods to begin with.

The rollout is Paused due to the manual trigger step we included. To resume the rollout, use the promote command:

You’ll see that four of your Pods (40% of the total replica count) now run the canary deployment:

Wait a couple of minutes, then repeat the command—you should see the rollout has automatically progressed up to 80%, as configured by the steps in your manifest file.

5. Promote the Rollout

Because no further steps are defined after the 80% stage, the rollout will halt indefinitely once it’s reached. To complete the rollout, run the promote command again—this will replace all the remaining old Pods with new ones that run the updated deployment.

Now, only the latest rollout revision will be active:

We’ve successfully used Argo Rollouts to implement a canary deployment workflow in Kubernetes! However, we’ve only covered the basics — there are plenty more features to discover in the documentation, including automatic rollbacks, advanced traffic routing configuration, and the ability to launch experiments that involve multiple app versions.

Although Argo Rollouts provides more control over how app revisions reach your cluster, it doesn’t help you apply changes to the cluster itself. Try a dedicated CI/CD platform like Spacelift to simplify IaC management for Kubernetes and stay on top of your infrastructure. This gives you the most powerful Kubernetes experience when operating your clusters at scale.

Spacelift brings with it a GitOps flow, so your Kubernetes Deployments are synced with your Kubernetes Stacks, and pull requests show you a preview of what they’re planning to change. It also has an extensive selection of policies, which lets you automate compliance checks and build complex multi-stack workflows.

If you want to learn more, create a free account today or book a demo with one of our engineers.

Argo Rollouts provides a Kubernetes controller and CRDs that implement support for additional rollout strategies beyond those enabled by plain Deployments and ReplicaSets. It lets you progressively deliver changes to users via canary or blue-green deployments that are only promoted once you’ve verified there are no issues. You can connect metrics sources to automate progression and rollback events, improving deployment performance and safety.