Blue/Green Deployments in Kubernetes: A Quick Guide

Blue/Green deployments are a form of progressive delivery where a new version of the application is deployed while the old version still exists. The two versions coexist for a brief period of time while user traffic is routed to the new version, before the old version is discarded (if all goes well).

Blue/Green Deployments in Kubernetes: A General Process

- 1. The current version of the application is marked with a color (e.g blue)
  2. A new deployment is performed with brand new pods and is marked with the new color (i.e. green)
  3. Both versions exist at the same but the Kubernetes service is still pointing at the existing/blue version and thus not all users of the system can see the change yet
  4. Different types of tests (e.g. smoke tests) can be performed on the new version with no impact to existing users
  5. After a user-defined amount of time, the Kubernetes service is switched and now points to the new version. All live users can now use the new functionality without any downtime
    1. If the new version works as expected, the old version is destroyed. The new version becomes the “current version” and the Kubernetes service stays as is
    2. If the new version has issues, the Kubernetes service is switched back to the previous version. This has minimal impact on users. The new version is destroyed and everything is back to the original state

Does Kubernetes Support Blue/Green Deployments?

Kubernetes does not provide blue/green deployment functionality out of the box. What it does provide is the Deployment object which lets you do a “rolling update”. This allows you to update an application with zero downtime, by gradually replacing pods with the new version of an application.

Rolling updates are useful but the problem is that it’s difficult to roll back if something is wrong with the new version. Also, it doesn’t support running both versions in parallel as required by the blue/green pattern.

You can implement blue/green deployment in Kubernetes using a variety of techniques and tools. Let’s see how to do it with Codefresh, a software delivery platform powered by the Argo project.

Automated Blue/Green Deployments With Codefresh: Quick Overview

Kubernetes already comes with the basic building blocks (deployments and services) that make a blue/green deployment possible using plain kubectl commands. The challenge for a sound CI/CD solution is how to automate those kubectl commands so that blue/green deployments happen in a well controlled and repeatable manner.

Let’s see how to package these kubectl invocations into a pre-packaged Docker image offering a declarative way to do blue/green deployments.

TL;DR

The end goal is that in order to deploy using blue/green you can just insert the following build step in your codefresh.yml:

blueGreenDeploy:
   title: "Deploying new version ${{CF_SHORT_REVISION}}"
   image: codefresh/k8s-blue-green:master
   environment:
     - SERVICE_NAME=my-service
     - DEPLOYMENT_NAME=my-app
     - NEW_VERSION=${{CF_SHORT_REVISION}}
     - HEALTH_SECONDS=30
     - NAMESPACE=colors
     - KUBE_CONTEXT=myDemoAKSCluster

Here blue/green deployments happen in a completely declarative manner. All kubectl commands are abstracted.

The Blue/Green deploy step is essentially a docker image with a single executable that takes the following parameters as environment variables:

Environment Variable	Description
KUBE_CONTEXT	Name of your cluster in Codefresh dashboard
SERVICE_NAME	Existing K8s service
DEPLOYMENT_NAME	Existing k8s deployment
NEW_VERSION	Docker tag for the next version of the app
HEALTH_SECONDS	How many seconds both colors should coexist. After that new version pods will be checked for restarts
NAMESPACE	K8s Namespace where deployments happen

Prerequisites for Automated Blue/Green Deployments with Codefresh

The blue/green deployments steps expect the following assumptions:

- 1. An initial service and the respective deployment should already exist in your cluster.
  2. The service and the deployment need to use labels that define their version.

The second assumption is very important, as this is how the blue/green step detects the current version and can switch the load balancer to the next version.

You can use anything you want as a “version”, but the recommended approach is to use Git hashes and tag your Docker images with them. In Codefresh this is very easy because the built-in variable CF_SHORT_REVISION gives you the git hash of the commit that was pushed.

The build step of the main application that creates the Docker image that will be used in the blue/green step is a standard build step that tags the Docker image with the git hash

BuildingDockerImage:
   title: Building Docker Image
   type: build
   image_name: trivial-web
   working_directory: ./example/
   tag: '${{CF_SHORT_REVISION}}'
   dockerfile: Dockerfile

For more details, check out the example application that also contains a service and deployment with the correct labels as well as the full codefresh.yml file.

Running a Blue/Green Deployment in Codefresh

Once you meet the prerequisites above, running a blue/green deployment in CodeFresh is as simple as:

- 1. Modifying your application template, triggering a deployment in Codefresh
  2. The Codefresh pipeline step displays the following output:
  3. The blue/green step copies your existing deployment and changes its version, creating a second one with the updated Docker image.
    1. Note: At this point, both versions (old and new) of your application are deployed in the Kubernetes cluster. All live traffic is still routed to the old application.
  4. There is a waiting period (configurable as an environment parameter, shown in the previous section). During this period you are free to do any external checks on your own (e.g. check your health dashboard or run some kind of smoke testing).
  5. Once the waiting period is over, the script checks for the number of restarts in the pods of the new application. If there are any errors, it destroys the new deployment and the cluster is rolled back to the initial state. Your users are not affected in any way.
  6. If there are no pod restarts, the service is switched to point to the new deployment and the old deployment is discarded.

You can also see the changes in the Codefresh Kubernetes dashboard. The following example uses an Azure Kubernetes cluster, but any cluster will work as long as the labels are present in the manifest files.

And there you have it! Now you can deploy your own application using the blue/green strategy.

The blue/green Docker image is also available in Docker Hub.

New to Codefresh? Create Your Free Account Today!

Learn Progressive Delivery in the CodeFresh GitOps Certification Program

CodeFresh is offering a new certification program that can help you adopt GitOps in your organization. Within the course, we cover:

- - What is progressive delivery
  - How to use Argo Rollouts for blue/green and canary deployments
  - How to manage Secrets with GitOps

The course includes a live exercise that can help you learn progressive delivery hands on, including how to install the Argo Rollouts controller, release an application with blue/green deployments, and monitor deployment progress.

Learn more about the certification program or enroll today!