Introducing Argo Rollouts

Less than a year ago, we started building Argo CD, a declarative, GitOps continuous delivery tool for Kubernetes. The project has been growing in popularity, with many developers and DevOps engineers adopting it. A huge thanks to our awesome community of contributors and users!

Today, we are excited to announce Argo Rollouts a new, Kubernetes-native, open source project brought to you by the Argo community and Intuit to provide missing deployment strategies like Blue/Green and Canary in a Kubernetes native and GitOps friendly manner. Argo Rollouts augments the functionality of the Kubernetes Deployment resource with additional deployment strategies.

You can watch the introduction and demo of Argo Rollouts at KubeCon Barcelona 2019 here!

Why Argo Rollouts?

Argo Rollouts fills the need for the missing industry standard deployment strategies like Canary and Blue Green in Kubernetes. If a user wanted to use these strategies previously, they would have to orchestrate the deployment strategies themselves. Users were forced to craft fragile Jenkins scripts and overly repetitive Kubernetes manifests.

Using the learnings from those attempts, the Argoproj team tried to offer Pre-Sync, Sync, and Post-Sync hooks in Argo CD as a potential solution. However, we found that solution falls short of the ideal user experience we wanted to provide. It did not provide the visibility we would like to have during a deployment and still put the onus on the user to orchestrate the deployments.

We went back to the drawing board and realized that the logic can be encapsulated into a Custom Resource Definition. From there, we came up with the following fundamental requirements for Argo Rollouts to guide us during development:

• The deployment orchestration is abstracted from the users
• Reuse as much of the Kubernetes deployment object spec as possible to make adoption easy
• Provide a GitOps friendly model that seamlessly plugs into Argo CD
• Application deployments should be reliable and idempotent

How does Argo Rollouts controller work?

Argo Rollouts introduces a controller into a Kubernetes cluster to manage a new object type called a Rollout. A Rollout object is identical to a Deployment object except for a couple of keys fields. Below is an example of a Kubernetes Deployment spec converted to use an Argo Rollout using the BlueGreen deployment strategy.

Three changes were required to convert a Deployment into a Rollout:

1. Changing kind from Deployment to Rollout
2. Changing apiVersion to argoproj.io/v1alpha1
3. Adding a specific deployment strategy in the rollout (Blue Green in the example above)

For the specific deployment strategy, Argo Rollouts currently provides Blue Green and ReplicaSet Based Canary.

Blue Green Deployments

For context, Blue Green deployments allow users deploy and run both the new and the old versions of their applications at the same time. The old version will receive the regular traffic, and developers can run tests on the new version until they feel comfortable with rolling out the new version. Then, the traffic is cut over from the old version to the new version, and the old version is eventually scaled down.

Network View in Argo CD showing what pods are being selected by the Service’s Selector

The Argo Rollouts controller achieves this strategy by managing the ReplicaSets and filtering the traffic by modifying Service selectors. The ReplicaSets are created from the spec.template field of the Rollout and services are specified in the spec.strategy.blueGreen field. Each ReplicaSet created by the rollout has a unique hash (in the rollouts-pod-template-hash in the label) that the controller will add to the service’s selector to limit traffic to that one ReplicaSet.

When the spec.template field changes, the Rollout will create a new ReplicaSet and wait for it to become available. Once that occurs, the controller will modify the preview Service’s selector to send traffic to the new Replicaset and enter a paused state by setting the spec.paused field to true. During this time, the Rollout will pause and wait until an external operator (like a CD system or a user) changes the value to false. After the Rollout is unpaused, the Rollout will modify the active service’s selector to point it at the new ReplicaSet and scale down the old one.

ReplicaSet Based Canary Deployments

A canary rollout is a deployment strategy where the operator releases a new version of their application to a small percentage of the real traffic. Canaries are often used to verify the new release is functional and performant without having the risk of exposing the new version to all traffic.

In a ReplicaSet-based Canary rollout, the traffic is split evenly among all running pods. To achieve the canary rollout, users specify a list of steps to execute to transition to the new version using the spec.Strategy.Canary field. The available steps are setWeight, which indicates the percentage of the overall replica count that should be in the new replicaset and pause, which freezes the Rollout until a specified event occurs. When a new version is introduced, the Argo Rollout controller will execute each of these steps. Once it does, the controller will mark the current template within the rollout to be the new stable resource. Below is an example of a Canary Rollout:

When a new template is introduced in the above example, the rollout will first create the new replicaset with a replicas count of 1 and scale down the stable replicaset to 9 to achieve a weight of 10%. Once the pods are marked as available, the rollout will enter a paused state for 30 seconds before resuming. The controller will incrementally progress to a weight of 50% (5 new and 5 stable). At that point, the rollout will enter a paused state until an external operator unpauses it because the pause does not have a duration. After unpausing, the controller will slowly roll all the replicas to the new ReplicaSet before marking it as the new stable ReplicaSet as it executed all the steps.

A rollout with 5 replicas using the canary strategy to splitting 20% of traffic to a new version

Trying out Argo Rollouts

You can get started in 2 easy steps

• Install the Argo Rollouts controller into your namespace with the following commands:

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

• Switch your deployment to a Rollout by switching the kind and apiVersion and adding a deployment strategy like the examples above.

Argo Rollouts features

• Blue Green Deployments
• ReplicaSet-based Canary Deployments with customizable steps
• Integration with Argo CD
• HPA support
• Controller level Prometheus metrics

Going forward

We plan to continue growing Argo Rollouts functionality in the upcoming months. We want to incorporate Istio and other service mesh tools to support smarter traffic shaping, implement support for running multiple concurrent versions of software for experimentation and build a promotion-automation CRD. If any of this sounds exciting to you, please reach out in the Argoproj slack channel!

Thank You!

The Argoproj Community