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

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

• Deployment PodSpec (container images, commands, 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 it can be limited due to:

• No fine-grained control over the speed of a new release, by default Kubernetes will wait for the new pod to get into a 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 status of a new release.
• Unable to automatically abort or 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 offers Flagger as one of its GitOps components to deal with progressive delivery on Kubernetes.

Flagger helps developers 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)
• The next step would be 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.

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 apply 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 are a few features that can make the difference in choosing your progressive delivery tool for Kubernetes

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

We hope this helps you get an idea of how ArgoCD Rollout and Flagger work with Canary deployments and Istio, in addition to giving you a general overview of the two solutions.