Schedule a FREE onboarding and start making pipelines fast.

The simplest guide to using Blue/Green deployment in Kubernetes

Kubernetes Tutorial | April 27, 2018

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.

The Tutorial

High level flow

  1. Start with already deployed containers (Deployment) and service.
  2. Deploy new deployment
  3. Issue a health check
  4. If health check passes, update load balancer and remove old deployment
  5. If health check fails, stop and send Slack alert

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.

The last step will be updating the service YAML with this new id.

Prerequisites

  • Kubernetes Cluster
  • The Demochat Github repo
  • An existing deployment and service YAML (examples can be found in the repo under deploy/bluegreen
  • A Free Codefresh Account (For hosting the images and automating this process)
  • Slack (Optional)

For this demo we’ll use a demo application called “Demochat”. You’ll want to replace some of these values with the ones that match your application.

First, I’ll show the Codefresh YAML and step through what it’s doing. This is a great way to understand how to do Blue/green deployment yourself regardless of what tools you use.

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.

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.

Set context

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

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.

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.

But let’s be safe and make sure everything is running properly.

This command will make the pipeline wait until the deployment was successful. If the deployment isn’t successful, it will timeout and stop the pipeline from moving forward.

Update service

Now that the deployment has rolled out successfully, we can update it to use our newly built image.

Similar to how we took the existing configuration for a deployment, this will take the existing service and modify it to use our new deployment.

Note: This step could also take advantage of a Kubernetes readiness/liveness probe.

Your service has now been updated! We’re all done.

Delete old Deployment

Oh wait, we want to delete the old deployment so it doesn’t waste compute time and memory. We have one final step.

Slack Notifications (Optional)

This one’s easy, just goto integrations under account settings to enable Slack.

All done!

New to Codefresh? Get started with Codefresh by creating your free account today!

About Dan Garfield

Dan is a full-stack web developer and VP of the Marketing at Codefresh. Dan is a *nix native and all around technology enthusiast.

Reader Interactions

Enjoy this article? Don't forget to share.

Comments

Your email address will not be published. Required fields are marked *

Follow me on Twitter