Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. It reduces the risk of introducing a new software version in production by gradually shifting traffic to the new version while measuring metrics and running conformance tests.
This article describes in detail how to achieve the simplest blue/green deployment of an app in Kubernetes. Here’s what we’re looking for:
There’s a live, production version of an app running in our cluster: the blue version
We deploy a new version (the green version) of this app, alongside the blue one
We manually run tests on the green version
If all tests pass, we promote the green version to be the new live/prod/blue version
This article assumes familiarity with Flagger concepts like the Canary CRD. If you’re new to Flagger, please read the Flagger introduction first.
Before we begin, let’s simulate a production (blue) environment using a sample app. We’ll use “the parrot app” from Jérôme Decoster‘s awesome blog post. This fun little app simply shows the image of a blue parrot when you hit the blue version & a green parrot when you hit the green version:
Start by deploying the following deployment & ingress into your cluster:
targetRef tells Flagger which deployment to manage.
ingressRef tells Flagger which ingress to manage.
The service block tells Flagger what parameters to use for the parrot service it generates.
Since we’re only interested in manual testing of our green environment, the only canary analysis we ask Flagger to run, is to call a webhook which tells it when it’s OK to promote green to blue.
analysis.interval = 1 minute means Flagger will call the webhook every minute.
Since we’re not creating a canary scenario wherein traffic is shifted gradually from blue to green in several iterations, we set analysis.iterations = 1 so all traffic shifts from blue to green when the webhook gives the OK.
analysis.threshold = 60 means if the webhook returns 60 consecutive failure responses, destroy the canary & don’t promote it to blue. This combined with the analysis.interval of 1 minute gives us 1 hour to run our manual tests on the canary & promote it, before it expires.
analysis.webhooks defines the webhook to call every minute to check whether it’s time to promote the canary to prod. You can create your own webhook at webhook.site. Configure it to respond with HTTP 500 till it’s time to promote the canary.
Deploy a new (green) version of the app by changing its image:
kubectl set image deploy/parrot parrot=kmharish/parrot-app:v2.2
This causes Flagger to create the green environment. You can now test the new version using the service parrot-canary. Once testing passes, reconfigure the webhook to send HTTP 200. When Flagger notices this, it will replace the blue version with the new version.
Congratulations! You’ve just deployed a new version of your app using the blue/green deployment strategy!
About the Author ✍🏻
Harish KM is a Principal DevOps Engineer at QloudX & a top-ranked APN Ambassador. 👨🏻💻
With over a decade of industry experience as everything from a full-stack engineer to a cloud architect, Harish has built many world-class solutions for clients around the world! 👷🏻♂️
With over 20 certifications in cloud (AWS, Azure, GCP), containers (Kubernetes, Docker) & DevOps (Terraform, Ansible, Jenkins), Harish is an expert in a multitude of technologies. 📚
These days, his focus is on the fascinating world of DevOps & how it can transform the way we do things! 🚀
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.