The simplest guide to using Blue/Green deployment in Kubernetes

Editors Note 8/17/2018 – This blog post provides a good basis to learn functionally how Blue/Green works in Kubernetes. For actually implementing Blue/Green in your own pipelines, we recommend this updated post.

Blue/Green deployments are one of the mainstays of deployment strategies. In fact, it’s the very first deployment strategy I learned ( directly editing production over FTP doesn’t count). Thanks to Kubernetes, we can actually get this done in a much more streamlined way than what was previously possible!

Lets jump in!

What is Blue/Green Deployment

A Blue/Green deployment is a way of accomplishing a zero-downtime upgrade to an existing application. The “Blue” version is the currently running copy of the application and the “Green” version is the new version. Once the green version is ready, traffic is rerouted to the new version.

The user will experience no downtime and will seamlessly switch between blue and green versions of the application.

Blue/Green With Kubernetes

In Kubernetes this is slightly different because our blue and green versions are actually a set of containers and the load balancer is built into Kubernetes. It’s possible to do blue/green deployments lots of ways with Kubernetes. In this example, we’ll use deployments and services to get the job done. The same idea will work for replicaSets.

To make this work, we’re going to build our images and tag them with our commit SHA. We’ll use that SHA as a unique id for modifying everything. In this case, we’ll use the existing (blue) deployment to generate the YAML for the new (green) deployment. We’ll replace all the commit SHAs with the new commit SHAs and redeploy. This will create a deployment with a new name and image.

Building the Docker image

The build step is out of the box and should be familiar to everyone. In this case, I decided to use ${{CF_SHORT_REVISION}} as my tag. This will make sure that I always have a unique image name and I’ll use it again in my deployment.

1

2

3

4

5

6

7

BuildingDockerImage:

title:Building Docker Image

type:build

image_name:containers101/demochat

working_directory:./

dockerfile:Dockerfile

tag:'${{CF_SHORT_REVISION}}'

Configure Blue/Green Step

Codefresh has a built in step for working with Kubernetes and Helm, we’ll pull that and set some environmental variable that we can use in our commands. Since I’ve already connected a Kubernetes cluster to Codefresh I can now reference it here. In this case “helmdemo@jFrog-Helm”. And I’ll set the namespace I want to work in.

1

2

3

4

5

6

BlueGreenDeploy:

title:PerformaBlue Green Deployment

image:codefresh/kube-helm:master

environment:

-KUBE_CONTEXT=helmdemo@jFrog-Helm

-NAMESPACE=bluegreen

Set context

I’ll reference the cluster I’ve already connected so the rest of the commands will use this cluster.

1

kubectlconfiguse-context${KUBE_CONTEXT}

Record the current version (blue version)

We need to know what’s currently deployed so we can replace it and remove it later. We’ll save this as a local variable.

1

export BlueVersion=$(kubectl get service demochat-o=jsonpath='{.spec.selector.version}'--namespace=${NAMESPACE})

Deploy the updated image

As we saw in our diagram earlier, our service is made up of a deployment and a service that exposes it. We’ll take the existing deployment, and replace the image tag with the image we’ve just built.

This will create a new deployment that we can verify before switching our service over.

After this step, there will be two deployments for our application. The original or “blue” version and the new “green” version. The diff between the two deployments will look something like this

Issue a health check for our green version

The previous command will deploy our new image but it doesn’t know if it was successful or now. Maybe the pull secret wasn’t configured, or the image itself won’t start. When using any automated deployment pipeline you should have validated this image well before we started a deployment.