Table of Contents

• Introduction
• Sample App
• Blue Environment
• Flagger Canary
  • Canary Analysis
• Green Environment
• About the Author ✍🏻

Introduction

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:

1. There’s a live, production version of an app running in our cluster: the blue version
2. We deploy a new version (the green version) of this app, alongside the blue one
3. We manually run tests on the green version
4. 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.

Sample App

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:

Blue Environment

Start by deploying the following deployment & ingress into your cluster:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: parrot
  namespace: blue-green
spec:
  replicas: 1
  selector:
    matchLabels:
      app: parrot
  template:
    metadata:
      labels:
        app: parrot
    spec:
      containers:
      - name: parrot
        image: kmharish/parrot-app:v1.2
        ports:
        - containerPort: 3000

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: parrot
  namespace: blue-green
  labels:
    app: parrot
spec:
  ingressClassName: nginx
  rules:
  - host: parrot.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: parrot
            port:
              number: 80

Note that we’re using the NGINX ingress controller with Flagger.

Flagger Canary

Instead of creating the parrot service ourselves, we let Flagger manage it by creating a Flagger Canary CRD:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: parrot
  namespace: blue-green
spec:
  provider: nginx
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: parrot
  ingressRef:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    name: parrot
  service:
    port: 80
    targetPort: 3000
  analysis:
    interval: 1m
    iterations: 1
    threshold: 60 # auto-destroy green env after 1 hour
    webhooks:
    - name: confirm-promotion
      type: confirm-promotion
      url: https://webhook.site/6f0ce11c-d2d8-4375-895d-a5c1ec90a323

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.

Canary Analysis

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.

Green Environment

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 AWS Ambassador since 2020. 👨🏻‍💻

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! 🚀

AWS Blue/Green DevOps EKS Flagger Kubernetes