Blue/Green Deployments in Kubernetes: A Quick Guide
Blue/Green Deployments in Kubernetes: A General Process
The current version of the application is marked with a color (e.g blue)
A new deployment is performed with brand new pods and is marked with the new color (i.e. green)
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
Different types of tests (e.g. smoke tests) can be performed on the new version with no impact to existing users
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
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
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.
The end goal is that in order to deploy using blue/green you can just insert the following build step in your codefresh.yml:
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:
Name of your cluster in Codefresh dashboard
Existing K8s service
Existing k8s deployment
Docker tag for the next version of the app
How many seconds both colors should coexist. After that new version pods will be checked for restarts
K8s Namespace where deployments happen
Prerequisites for Automated Blue/Green Deployments with Codefresh
The blue/green deployments steps expect the following assumptions:
An initial service and the respective deployment should already exist in your cluster.
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
Once you meet the prerequisites above, running a blue/green deployment in CodeFresh is as simple as:
Modifying your application template, triggering a deployment in Codefresh
The Codefresh pipeline step displays the following output:
The blue/green step copies your existing deployment and changes its version, creating a second one with the updated Docker image. 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.
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).
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.
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.
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.