Create your FREE Codefresh account and start making pipelines fast. Create Account

Fully automated blue/green deployments in Kubernetes with Codefresh

4 min read

Out of the box, Kubernetes supports some interesting deployment strategies. From those, the most useful for production deployments is the rolling update. This deployment strategy allows for zero-downtime application upgrades and also offers a gradual rollout of the new application to each pod instance.

Even though rolling updates sound great in theory, in practice, there are several drawbacks. The major one is the lack of easy rollbacks. Attempting to go to the previous version after a deployment has finished is not a straightforward process. A minor disadvantage is also the fact that not all applications are capable of having multiple versions active at the same time.

An alternative way of deployment comes in the form or blue/green (a.ka. red/black) deployments. With this strategy, a full set of both old and new instances exist at the same time. Active traffic is decided via the loadbalancer that selects one of the two sets. This means that doing a rollback is as simple as switching back the load balancer.

Blue green deployments
Blue green deployments

Unfortunately, Kubernetes does not support blue/green deployments out of the box. It is the responsibility of an external tool or automation solution to implement such deployment. Hopefully, doing blue/green deployments is not that hard. Kubernetes already comes with the basic building blocks (deployments and services) that make a blue/green deployment very easy 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.

We have already covered blue/green deployments in a previous Codefresh blog post. There, we explained a way to script a Codefresh pipeline to perform blue/green deployments. This approach works well for people that already know how kubectl works, but is not the most user-friendly way for designing a pipeline.

Blue/Green deployments with a declarative syntax

In this post, we will take blue/green deployments one step further by packaging the kubectl invocations into a pre-packaged Docker image offering a declarative way to do blue/green deployments.

The final result 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:

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


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

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

How to perform Blue/Green deployments

When you run a deployment in Codefresh the pipeline step will print information message on its actions.

Blue/Green deployment logs
Blue/Green deployment logs

The blue/green step copies your existing deployment and changes its version, creating a second one with the updated Docker image. At this point, BOTH version (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 as we have seen 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 that period is finished, 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 your cluster is back to the initial state (your users are not affected in any way).

If there are 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. I am using an Azure Kubernetes cluster, but any cluster will work as long as the labels are present in the manifest files.

Kubernetes Dashboard
Kubernetes Dashboard

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 Dockerhub.

New to Codefresh? Create Your Free Account Today!

Kostis Kapelonis

Kostis Kapelonis

Kostis is a software engineer/technical-writer dual class character. He lives and breathes automation, good testing practices and stress-free deployments with GitOps.

8 responses to “Fully automated blue/green deployments in Kubernetes with Codefresh

  1. Patrick Nelson says:

    This was an awesome tutorial, thank you for the inspiration! I appreciate you guys outlining this strategy even though it doesn’t necessarily require integration with Codefresh itself. One of my main concerns was finding a way to ensure I could prepare a cluster for a new version switch over while ensuring it can wait for database migrations. If successful, it’d then flip over to the new color (e.g. blue -> green). Reading through this it serves as a really good basis; just take the existing deploy script and with just a little modification, database migrations can be applied just after the health check (or as a sort of additional stage similar to the health check) and… voila.

    1. Kostis Kapelonis says:

      Thank you for the feedback. We generally suggest that you decouple database migrations from application release pipelines. It takes some more time and attention to follow this pattern but it works much better in the long run.

  2. lakshmi prasuna says:

    thank you so much for your tutorial. can i work on blue and green both deployments parallelly without discarding previous application.

    1. Kostis Kapelonis says:

      Yes of course. If you think that the previous application needs to be kept, you just revert to the “previous” color and everything is back as it was.

      1. How to revert back? am new to kubernetes

        1. Kostis Kapelonis says:

          With blue/green deployments the revert is automatic. The old color stays put and the new one is destroyed. That is the whole point of blue/green deployments.

  3. Michael Freidgeim says:

    “There is a waiting period… 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)”
    If during smoke tests the some issues ( not related to restarts in the pods) were found what is the process to stop the switch?

    1. Kostis Kapelonis says:


      This is a very old article and we have since adopted Argo Rollouts for canary deployments instead of trying to create our own solution. You can find our updated approach here

      Argo Rollouts is much more flexible and the pipeline described also handles failure of smoke tests.

      In summary you use the undo/abort commands native to Argo Rollouts

Leave a Reply

* All fields are required. Your email address will not be published.

See how Codefresh helps you
deploy more and fail less!