Kubernetes Blue-Green Deployment

Blue-Green deployment is a strategy to achieve zero-downtime deployment. With cloud-native applications, it is common practice to reduce downtime when upgrading the application version. Due to the ease with which we can provision new infrastructure on the cloud, it becomes easier to adopt new ways of improving the deployment.

Blue Green deployment definition

In this post, we will look at how to use Blue-Green deployment with Kubernetes. One of the best places to look for definition is the glossary of terms provided by Cloud Native Computing Foundation (CNCF). The CNCF defines Blue Green deployment as

"A strategy for updating running computer systems with minimal downtime. The operator maintains two environments, dubbed “blue” and “green”. One serves production traffic (the version all users are currently using), whilst the other is updated. Once testing has concluded on the non-active (green) environment, production traffic is switched over (often via the use of a load balancer)."

The main point here is two identical environments named blue and green and the traffic switching using load balancer. Lets see how this can be applied to the Kubernetes environment.

How to perform Kubernetes Blue Green Deployment

We start by creating two versions of the application. Let's say V1 which is deployed to the live environment. This forms our Blue environment. To keep things simple, I have created a simple ASP.Net Core application. It is packaged into a Docker image with two tags. One tag has Blue background and will be used to deploy to the Blue environment. The other container image with green tag will be used to deploy to the Green environment. The two docker container images are published to Dockerhub as

• nileshgule/blue-green-demo:blue
• nileshgule/blue-green-demo:green

Step 1 : Setup Blue environment

Once the container images are pushed to the container registry, we can use Kubernetes Deployment to deploy to the Kubernetes cluster. We create a blue-deployment using the image tagged as blue. The Kubernetes deployment will internally create a replicaset and related pod. In the pod deployment template we set the label as app: blue.

The deployment is exposed outside the Kubernetes cluster using a Kubernetes service of the type loadbalancer. The service uses the selector with app: blue value. 

Browse the public IP of the loadbalancer service and we will be presented with the web page with Blue background.

Step 2:  Setup Green environment

The second step of the Blue-Green deployment is to create the Green environment. This is done by creating a 2nd Kuberentes deployment using the image nileshgule/blue-green-demo:green tag. We also set the label for the deployment as app: green. The rest of the attributes in the manifest file are almost same as the blue deployment. After applying the Green deployment, the service is still serving 100% traffic to Blue environment. We can perform test on the next version or release of the application which is deployed to the green environment. If the tests are successful, we can switch the traffic to green environment.

Step 3: Route traffic to Green environment

The final step in the Blue-Green deployment is to switch the traffic to the Green environment. We can do this by editing the service manifest. We update the selector to select the pods with app: green label. Apply this change to the Kubernetes service. All the traffic is now redirected to the Green environment. 

Note that the Blue environment is still there, but the active or live traffic is served by the green environment. If there is any problem with the Green environment, we can change the selector in the service again to point back to the Blue environment quickly allowing us to revert the changes with minimal impact on the end users.

Youtube video

The steps explained in this blog post are demonstrated in the Youtube video in detail. Watch the video for a live demo and feel free to provide feedback in the video comments.

Conclusion

It is very easy to use the Blue-Green deployment strategy with Kubernetes using Service. This strategy is quite useful to reduce the downtime for stateless applications. Stateful applications are a bit more involved. This reduces the risk during application upgrades. By having a standby environment we can easily fallback to an older version with no downtime. Hope you found this useful.

Until next time, Code with Passion and Strive for Excellence.

Share: