ArgoCD Rollout vs Flagger: Setup Guide and Analysis

With the rise of high frequency application deployment, CI/CD has been adopted by the modern software development industry. But many organizations are still looking for a solution that will give them more control over the delivery of their applications such as the Canary deployment method or even Blue Green.

Called Progressive Delivery, this process will give organizations the ability to run multiple versions of their application and reduce the risk of pushing a bad release.

In this post we will focus on Canary deployment as there’s a high demand for organizations to run testing in production with real users and real traffic which Blue Green deployment cannot do.
‍

- ArgoCD vs Flagger: Overview

- Why not use Kubernetes RollingUpdate?

- What is ArgoCD Rollout?

- What is Flagger?
- How ArgoCD Rollout and Flagger Work with Istio?
- How does ArgoCD Rollout compare with Flagger?
- Conclusion
‍

ArgoCD vs Flagger: Overview

‍

A Canary deployment will be triggered by ArgoCD Rollout and Flagger if one of the changes get applied:

Deployment PodSpec (container image, command, ports, env, resources, etc)
ConfigMaps mounted as volumes or mapped to environment variables
Secrets mounted as volumes or mapped to environment variables

‍

Why not Use Kubernetes RollingUpdate?

Kubernetes offers by default their RollingUpdate deployment strategy but can be limited:

No fine grained control over the speed of a new release, by default Kubernetes will wait for the new pod to gets in ready state and that’s it.
Can’t manage traffic flow, without traffic split it is impossible to send a percentage of the traffic to a newer release and adjust its percentage.
No ability to verify external metrics such as Prometheus custom metrics to verify the state of a new release.
Unable to automatically abort and rollback the update

‍

What is ArgoCD Rollout?

Just a year after ArgoCD creation, in 2019 the group behind the popular ArgoCD decided to overcome these limitations from Kubernetes by creating ArgoCD Rollout as a Kubernetes Controller used to achieve canary, blue green, canary analysis, experimentation, and progressive delivery features to Kubernetes with the most popular service mesh and ingress controllers.

‍

What is Flagger?

Created in 2018 by the FluxCD community, FluxCD has been growing massively since its creation and offer Flagger as one of their GitOps component to deal with progressive delivery on Kubernetes.

Flagger helps developers to solidify their production releases by applying canary, A/B testing and blue green deployment strategies.
It has direction integration with service mesh such as Istio and Linkerd but also ingress controllers like NGINX or even Traefik.

‍

How ArgoCD Rollout and Flagger Work with Istio?

If you are using Istio as a service mesh to deal with Traffic Management and want to use Canary as a deployment strategy:

ArgoCD Rollout will transform your Kubernetes Deployment as a ReplicaSet.
To start you would need to create the Istio DestinationRule and Virtual Service but also the two Kubernetes Services (stable and canary)

Next step would be creating creating your rollout, ArgoCD Rollout will manage the Virtual Service to match with the current desired canary weight and your DestionationRule that will contain the label for the canary ReplicaSet.

Example:

   
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: reviews-rollout
 namespace: default
spec:
 replicas: 1
 selector:
   matchLabels:
     app: reviews
     version: stable
 template:
   metadata:
     labels:
       app: reviews
       version: stable
       service.istio.io/canonical-revision: stable
   spec:
     serviceAccountName: bookinfo-reviews
     containers:
     - name: reviews
       image: docker.io/istio/examples-bookinfo-reviews-v1:1.18.0
       imagePullPolicy: IfNotPresent
       env:
       - name: LOG_DIR
         value: "/tmp/logs"
       ports:
       - containerPort: 9080
       volumeMounts:
       - name: tmp
         mountPath: /tmp
       - name: wlp-output
         mountPath: /opt/ibm/wlp/output
       securityContext:
         runAsUser: 1000
     volumes:
     - name: wlp-output
       emptyDir: {}
     - name: tmp
       emptyDir: {}
 strategy:
   canary:
     canaryService: reviews-canary
     stableService: reviews-stable
     trafficRouting:
       istio:
         virtualService:
           name: reviews
         destinationRule:
           name: reviews
           canarySubsetName: canary
           stableSubsetName: stable
     steps:
       - setWeight: 20
       - pause: {} # pause indefinitely
       - setWeight: 40
       - pause: {duration: 10s}
       - setWeight: 60
       - pause: {duration: 10s}
       - setWeight: 80
       - pause: {duration: 10s}

Here’s a documentation link for the Istio ArgoCD Rollout integration ->https://argoproj.github.io/argo-rollouts/features/traffic-management/istio/

Flagger relies on a k8s custom resource called Canary, example below:

   
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
 name: reviews
 namespace: default
spec:
 # deployment reference
 targetRef:
   apiVersion: apps/v1
   kind: Deployment
   name: reviews
 # the maximum time in seconds for the canary deployment
 # to make progress before it is rollback (default 600s)
 progressDeadlineSeconds: 60
 service:
   # service port number
   port: 9080
 analysis:
   # schedule interval (default 60s)
   interval: 15s
   # max number of failed metric checks before rollback
   threshold: 5
   # max traffic percentage routed to canary
   # percentage (0-100)
   maxWeight: 50
   # canary increment step
   # percentage (0-100)
   stepWeight: 10

As seen on L11, you don’t have to define your deployment but can call its name so the k8s deployment is managed outside of the Canary custom resource.Once you applied this, Flagger will automatically create the Canary resources:

   
# generated
deployment.apps/reviews-primary
service/reviews
service/reviews-canary
service/reviews-primary
destinationrule.networking.istio.io/reviews-canary
destinationrule.networking.istio.io/reviews-primary
virtualservice.networking.istio.io/reviews

As you can see, it created the Istio Destinationrule and Virtual service to achieve traffic management for canary deployment.

‍

How Does ArgoCD Rollout Compare to Flagger?

Both solutions support the same service mesh and share a very similar analysis process but there’s a few features that can make the difference in choosing your progressive delivery tool for Kubernetes

	ArgoCD Rollout	Flagger
+	- Great UI/dashboard to manage releases - ArgoCD dashboard (not Rollout dashboard) can interact with ArgoCD Rollout to approve promotions. - Kubectl plugin which makes it easy to query via a CLI rollout status.	- Automatically creates the Kubernetes Services, Istio DestinationRule, and Virtual Service. - Load tester can run advanced testing scenarios.
-	- ArgoCD Rollout needs you to create Kubernetes Services, Istio DestinationRules, and Vertical Services manually. - No authentication or RBAC for the Rollout dashboard.	- CLI only, no UI/dashboard. - Logs can lack information, in addition to being difficult to visualize. - No Kubectl plugin to easily fetch deployment information. - Documentation may not be as detailed as ArgoCD Rollout.

‍

Conclusion

Both solutions are backed up by strong communities so there’s not a bad option that really stands out.
You may already be using FluxCD, in this case Flagger makes sense as an option to achieve progressive delivery and the same goes for ArgoCD and ArgoCD Rollout.

At Bluelight, we do enjoy the simplicity of Flagger, but if you’re a team of multiple platform engineers that would need to manage production releases, a dashboard/UI with ArgoCD Rollout could be a better option for you?

We hope this helped you get an idea on how ArgoCD Rollout and Flagger work with Canary deployments and Istio but also a general overview of the two solutions.

Blog