Easy Blue-Green Deployment on Openshift Container Platform using Argo Rollouts

I have been looking for a way on how to do blue-green deployment in kubernetes. Whenever you run a google search, top searches usually involves manual patching of your ingress resource or the service resource. I don’t want any manual patching since its error prone and imagine how cumbersome it will be if you have a fleet of multi-tenant applications to update.

In this post we will look into Argo Rollouts on how it can help us do blue-green deployment easily.

Kubernetes Deployment Strategies

Before we dive-in into Argo Rollouts, let’s review what deployment strategies are available in kubernetes. At the moment, kubernetes natively supports the following deployment strategies:

Rolling Update — pods in the replica set are updated one-by-one or as specified in the max surge percentage. This means that you have two different versions live at any given moment while the rolling update is happening.

Recreate — deletes the old pods and replaces them with the new version. Using recreate strategy will result in a down time since the old pods are destroyed and it can take awhile for the new pods to be up and running.

It most cases, we would encounter the following deployment requirements:

• no downtime
• only a single version accessible to end users
• QA to test the deployed version in production before letting end users use the new version

If we have requirements as such, then the best deployment strategy to use is a blue-green deployment.

Blue-Green —new pods are created without deleting the old one, once all new version of the pods are up and running, traffic is cutover from the old to the new pods.

The usual way to do this is by patching the pod selector of the service object to use the labels associated with the new pods.

If you are using Helm, usually a new release is created i.e. release-green, which contains all the resources except the ingress. The usual way to do a blue-green deployment using helm is we patch the ingress object to point to the release-green service object.

Since we do not want to do manual patching of kubernetes objects, we will use Argo Rollouts for our blue-green deployment.

Argo Rollouts

Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.

Argo Rollouts (optionally) integrates with ingress controllers and service meshes, leveraging their traffic shaping abilities to gradually shift traffic to the new version during an update. Additionally, Rollouts can query and interpret metrics from various providers to verify key KPIs and drive automated promotion or rollback during an update.

https://argoproj.github.io/argo-rollouts/

Argo Rollouts is part of the Argo project which includes the popular ArgoCD gitops tool.

The Argo Rollouts rollout kind is a drop-in replacement for the native deployment object. The only difference is that rollout has an additional section call “strategy” under the spec section of the manifest.

apiVersion: argoproj.io/v1alpha1 kind: 
Rollout metadata: 
name: example-rollout-canary 
spec: 
  replicas: 5 
  analysis: 
    successfulRunHistoryLimit: 10 
    unsuccessfulRunHistoryLimit: 
  selector: 
    matchLabels: 
     app: guestbook 
  template: 
    spec: 
      containers: 
        — name: guestbook 
          image: argoproj/rollouts-demo:blue 
  minReadySeconds: 30 
  revisionHistoryLimit: 3 
  paused: true 
  progressDeadlineSeconds: 600 
  restartAt: “2020–03–30T21:19:35Z” 
  strategy: 
    blueGreen: 
      prePromotionAnalysis: 
        templates: 
          — templateName: success-rate 
            args: 
              — name: service-name 
                value: guestbook-svc.default.svc.cluster.local 
       postPromotionAnalysis: 
         - templates: 
           — templateName: success-rate 
             args: 
              — name: service-name 
                value: guestbook-svc.default.svc.cluster.local
    previewService: preview-service 
    previewReplicaCount: 1 
    autoPromotionEnabled: false
    autoPromotionSeconds: 30
    scaleDownDelaySeconds: 30
    scaleDownDelayRevisionLimit: 2
    abortScaleDownDelaySeconds: 30
  ...
https://argoproj.github.io/argo-rollouts/features/specification/

Whenever you perform helm upgrade and your chart contains a rollout kind, Argo Rollout Controller takes over of the deployment and deploys a new replica set based on your settings and version.

The new replica set is labeled as “preview” and the “preview service” is connected to the new pods. Once all the new pods are up and running, Argo Rollout will promote, automatically or manually based on autoPromotionEnabled setting, the “preview” to “stable”. When the promotion is finished, both the “stable” and “preview” service is pointing to the “stable” pods.

Using the argo rollout plugin for kubectl, we can monitor our rollouts via commandline. There is also a built-in dashboard, using kubectl argo rollouts dashboard, available to monitor and manage the rollouts.

Benefits of Argo Rollouts

• It is a easy drop-in replacement for the native deployment kind to do blue-green deployment, just configure the spec.strategy in the manifest
• No need to develop code that will patch the ingress or service object and point it to the correct pods.
• If you are using helm, you can just do a helm upgrade and argo rollout will do the rest; no need to create another helm release and custom code to check helm releases.