Blue-Green

This is Part 4 of a multi-part, self-paced quick start exercise.

---

What Will You Do

In this exercise, you will perform a basic "blue-green" deployment pattern using GitOps.

---

Background

Note that a Blue-Green (sometimes also referred to as red/black) deployment stragegy type is not natively included in the ".spec.strategy.type" of Kubernetes. However, it can be realized without having to install any specialized controllers.

We will create two Deployments with different versions on the application. Both deployments will be using a Service with the same set of labels in its selector.

• The blue represents the current application version, and green represents the new application version.
• Only one version is live at a time.
• Traffic is routed to the blue deployment while the green deployment is created and tested.
• You can either keep the blue deployment for a possible rollback or decommission it.

Advantages

• Low/No application downtime
• Suited for applications that cannot handle "Rolling Updates" but need zero downtime.
• Reduces risk if something unexpected happens with the new version (Green) because it can be rolled back to (Blue) immediately
• Can also avoid versioning issues i.e. the entire application state is changed in one deployment

Disadvantages

• Can be very expensive because double the application resources are required i.e. ensure your Kubernetes cluster is resources to handle at least double the resources.
• Ensure that you do not have namespace limits for your application that will prevent new pods from being scheduled.

Estimated Time

Estimated time burden for this part is 5 minutes.

---

Step 1: Baseline

This assumes that you have already completed at least "Part-1" and have an operational GitOps pipeline syncing artifacts from your Git repository.

• Navigate to your Git repo -> echo.yaml file and Edit
• Copy the following YAML and update the file
• Commit the changes in your Git repository

Note that we have "two deployments". The first one called "echo-blue" is active and has two replicas. The second one is called "echo-green" and has zero replicas.

apiVersion: v1
kind: Service 
metadata:
  name: echo
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 5678
    protocol: TCP
  selector:
    app: echo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-blue
spec:
  selector:
    matchLabels:
      app: echo
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2       
      maxUnavailable: 1
  replicas: 2
  template:
    metadata:
      labels:
        app: echo
        version: "1.0"
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo
        args:
        - "-text=Blue"
        ports:
        - containerPort: 5678
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-green
spec:
  selector:
    matchLabels:
      app: echo
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2       
      maxUnavailable: 1
  replicas: 0
  template:
    metadata:
      labels:
        app: echo
        version: "1.0"
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo
        args:
        - "-text=Green"
        ports:
        - containerPort: 5678

Once the GitOps pipeline has reconciled, you should see something like the following via the zero trust kubectl

kubectl get po -n echo

NAME                         READY   STATUS    RESTARTS   AGE
echo-blue-558b67ffd6-5r7xx   1/1     Running   0          17h
echo-blue-558b67ffd6-qld8r   1/1     Running   0          17h

---

Step 2: Setup

To test the switch from Blue -> Green, we will execute cURL against the configured IP of the Service every second.

• Open Terminal
• Copy the following command, enter the External-IP for your Load Balancer and execute it.

while true; do sleep 1; curl http://<External-IP from above>;done

You should see something like the following:

Blue
Blue
Blue....

At this point all traffic is being routed to the "Blue" replicas

---

Step 3: Switch to Green

• Navigate to your Git repo -> echo.yaml file and Edit
• Update replicas for "echo-blue" from "2" to "0"
• Update replicas for "echo-green" from "0" to "2"
• Commit the changes in your Git repository

---

Step 4: View Behavior

The Git commit will trigger the Gitops pipeline. It will automatically update the workload on the cluster switching the "Blue" deployment with the "Green" deployment. You should start seeing responses from the Green replicas "Green" like the following in a few minutes with zero downtime.

Blue
Blue
Blue
Blue
Blue
Green
Green

If you check the pods via the zero trust kubectl, you should see something like the following:

kubectl get po -n echo

NAME                          READY   STATUS        RESTARTS   AGE
echo-blue-558b67ffd6-5r7xx    1/1     Terminating   0          18h
echo-blue-558b67ffd6-qld8r    1/1     Terminating   0          18h
echo-green-7fbf46c447-ndg7r   1/1     Running       0          28s
echo-green-7fbf46c447-w5cx9   1/1     Running       0          28s

At this point, all traffic has been seamlessly switched and being routed to the "Green" replicas

---

Recap

In this part, you tested and experienced how a "Blue-Green" deployment pattern/strategy can be implemented easily on Kubernetes.

---