Working with Argo : Part-2

This blog is part of the GitOps series, and in this post lets understand about different progressive delivery models and how to use argo rollouts to achieve a simple blue green deployment.

Feel free to checkout my previous blogs related GitOps and Argocd

GitOps Fundaments
ArgoCD Fundaments
Working with Argo : Part-1

Argo Rollouts

#

Argo Rollouts is a progressive delivery controller created for Kubernetes. It allows you to deploy your application with minimal/zero downtime by adopting a gradual way of deployment.

What is Progressive Delivery

#

Progressive Delivery is a modern deployment strategy that gradually rolls out new changes to a subset of users before making them available to everyone. This reduces risk and improves control over software releases, with minimum downtime and easy rollbacks.

Ways to achieve progressive delivery.

• Blue-Green Deployment.
• Canary Deployment.
• Feature Flags (Toggle Deployment)

Blue-Green Deployment

#

Its also called as zero downtime deployment strategy that runs two identical environments — Blue (current / old version) and Green (new version). Both of them run in parallel.

Overview:

• Users interact with the blue environment while the new version is deployed (called the green environment)
• Once the green environment is tested and confirmed stable, traffic is switched from blue to green environment.
• The blue environment will not be taken down and runs in parallel with green environment and in case of any issues, traffic can be rolled back to blue environment.

Note:

1. The older environment (blue) , can either be terminated immediately once everything is confirmed as stable in green and does not impact the end users traffic.
2. There are patterns where the blue environment is not terminated and will keep running in the background with small footprint, which helps the team to switch over to older application version is required in the future, and gradually sunset the blue environment.

Blue-Green deployment with Argo Rollouts:

Before we start with the blue green deployment we need to install argo rollouts controller onto the cluster and the argo rollout cli locally.

Run the below command to install the controller.

argocd app create argo-rollouts-controller --project default --repo https://github.com/Vinay-Venkatesh/GitOps/ --path "argocd-deps/rollouts/" --sync-policy auto --sync-option CreateNamespace=true --dest-namespace argo-rollouts --dest-server https://kubernetes.default.svc

https://argo-rollouts.readthedocs.io/en/stable/installation/

The deployment is converted to kind Rollout.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: app-rollout
spec:
  replicas: 2
  strategy:
    blueGreen: 
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: simple-web-app
  template:
    metadata:
      labels:
        app: simple-web-app
    spec:
      containers:
      - name: simple-webapp
        image: docker.io/codedact/sample-app:v1
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP

If you further notice in the above manifest the strategy is set to blueGreen and there are two types of service that will run in parallel — activeService (latest-1 : blue) and previewService (latest : green) the promotion from blue to green environment is set to manual.

strategy:
    blueGreen: 
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false

Deploying the blue green application onto cluster via argocd cli.

argocd app create blue-green-demo-app \
--project default \
--repo https://github.com/Vinay-Venkatesh/GitOps \
--path "./blue-green" \
--sync-policy automatic \
--dest-namespace default \
--dest-server https://kubernetes.default.sv

Now that the application is deployed successfully, lets update the image tag from v1 to v2 and notice the changes in argocd.

source code : https://github.com/Vinay-Venkatesh/GitOps/blob/main/blue-green/rollout.yaml

Following changes happen in Argocd:

• Argo Rollouts creates another replica set with the new version
• The old version is still there and gets live/active traffic
• ArgoCD will mark the application as out-of-sync. DO NOT sync it manually again.
• ArgoCD will also mark the health of the application as “suspended” because we have setup the autoPromotionEnabled: False
• In real time feature deployments even though the next version of our application is already deployed, all live traffic still goes to the old version.

Commands to check the rollouts

kubectl argo rollouts list rollouts
kubectl argo rollouts status simple-rollout
kubectl argo rollouts get rollout simple-rollout

Because autoPromotionEnabled: False the status of the deployment will be paused . This is our hint that Argo Rollouts is waiting our go/no-go decision.

Now it is our chance to do some tests for the preview version. Maybe we want to run some integration tests or give this URL to our QA team to check it

With this we will have two choices

• Either we believe that version 2.0 is running fine and we will promote it to our live users (who are still looking at 1.0)
• Or there is an issue with version 2.0 and we want to discard it or prepare a hotfix. In both cases there is zero downtime and the live users are never affected by problematic releases.
  

If we didn’t like how version 2.0 runs we could discard it completely with the undo commands of the Argo Rollouts CLI.

Promoting the environments

Lets assume that internal tests are completed and the QA team gives a go-ahead for version 2.0 release and it is time to show this version to all the live users.

To manually promote the deployment and switch all traffic to the new version:

kubectl argo rollouts promote app-rollout

Command to monitor the rollout in realtime

kubectl argo rollouts get rollout app-rollout - watch

The deployment has finished successfully now. All live users see version 2.0 of the application without any service disruption.

Canary Deployment

#

Canary Deployment is an improved progressive delivery strategy where a new version of an application is released gradually to a small subset of users before rolling it out to everyone.

Overview:

• Deploy the current stable version (v1) — All traffic flows to this version.
• Deploy the canary version (v2) — A new version is deployed alongside v1, but only a small % of traffic is sent to it.
• Monitor the canary traffic — Observe performance, error rates, and user experience.
• Increase traffic to v2 gradually — If no issues arise, increase from 10% → 30% → 50% → 100%.
• Full rollout or rollback — If successful, v2 becomes the new stable version. If issues are detected, rollback to v1 instantly.

Caveats of Canary Deployment

#

• Canary deployments are more advanced than blue/green ones and are also more complex to set up and is not natively supported by kuberentes service.
• You need Ingress controllers, service mesh (Istio, Linkerd) or load balancers for traffic splitting effectively.
• You must actively monitor the canary version’s performance, error rates, and user feedback before rolling out to more users. Lack of proper observability can result in delayed detection of failures.