The K8s Deployment resource enables us to manage ReplicaSet resources at a higher level. The Deployment controller tracks image update history (versioning) and manages the sequence of Pod replacement during updates. This enables us to rollback to previous versions and control how many ‘new’ members of a ReplicaSet are deployed at a time. However, the Deployment controller hasn’t proven to deliver real-world safe and intelligent updates.

Enter Argo Rollouts, a subset of the Argo project. The first thing to know is that Argo Rollouts is a project to itself, it does not require Argo CD. Argo Rollouts’ purpose is to address the shortcomings of Deployment resources.

The Rollouts project introduces a new controller and set of CRDs to manage ReplicaSet resources. It is metric and traffic shaper aware. That means it knows how to correlate metrics that are collected from a set of new (canary) and existing (stable/baseline) pods running in a cluster for performance analysis, and how to modify traffic shaping configs (nginx/linkerd/istio) for fine-grain and flexible service introduction.

It goes further to better understand and manage versions and state of ReplicaSet resources during and post-update. The end result is a ReplicaSet manager that can perform intelligent (B/G, A-B, Canary) updates/rollbacks. Rather than go on-and-on, I will provide this link to the project docs (Kudos to the Argo Rollouts docs team, very easy to digest) https://argoproj.github.io/argo-rollouts/

Net/net, Argo Rollouts changes the way we manage Deployment/ReplicaSet relationships. It greatly enhances the evaluation of a healthy Deployment, adds canary rollout capabilities, and exposes a more flexible rollout/rollback pattern.