Kubernetes - Implementing Blue-Green Deployments

---

---

In this chapter, we’ll explore one of the safest ways to roll out application updates: Blue-Green Deployments. This deployment strategy helps us release new versions of applications with zero downtime and a quick rollback option. We'll walk through the concept, architecture, and finally implement it on a Kubernetes cluster, step-by-step.

What is a Blue-Green Deployment?

A Blue-Green Deployment is a technique where we maintain two environments (Blue and Green) for the same application:

• The Blue environment is the currently live version.
• The Green environment is the new version that we’re testing and preparing to release.

Once the Green version is fully ready and tested, traffic is switched from Blue to Green. If something goes wrong, we simply roll back traffic to the Blue environment.

This strategy provides:

• Zero downtime deployments
• Quick rollback in case of failure
• Easy A/B testing possibilities

Blue-Green Deployments in Kubernetes

In Kubernetes, we can implement Blue-Green deployments by:

• Running two separate Deployments (Blue and Green)
• Using a single Kubernetes Service to direct traffic
• Switching the Service selector between Blue and Green as needed

Let’s implement it practically with a sample app.

Prerequisites

Make sure you have the following installed:

• A Kubernetes cluster (e.g., Minikube, KIND, or any cloud provider)
• kubectl CLI
• Basic Docker knowledge (for building container images)

In this chapter, we’ll use a simple web app with two versions:

• tutorialspoint/webapp:v1 → Blue version
• tutorialspoint/webapp:v2 → Green version

Step-by-Step Blue-Green Deployment

Let's now understand in detail how the Blue-Green deployment works in Kubernetes.

Step 1: Deploy the Blue version

Create a file called webapp-blue.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      version: blue
  template:
    metadata:
      labels:
        version: blue
    spec:
      containers:
      - name: webapp
        image: tutorialspoint/webapp:v1
        ports:
        - containerPort: 80

Apply,

$ kubectl apply -f webapp-blue.yaml

Output

deployment.apps/webapp-blue created

Now create a Service that routes to this Blue deployment:

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    version: blue
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

Save it as webapp-service.yaml and apply:

$ kubectl apply -f webapp-service.yaml

Output

service/webapp-service created

Check access:

$ kubectl get svc webapp-service

Output

NAME             TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
webapp-service   NodePort   10.106.154.70   <none>        80:30470/TCP   30s

Step 2: Deploy the Green version (new release)

Let’s deploy the new version, v2:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-green
spec:
  replicas: 2
  selector:
    matchLabels:
      version: green
  template:
    metadata:
      labels:
        version: green
    spec:
      containers:
      - name: webapp
        image: tutorialspoint/webapp:v2
        ports:
        - containerPort: 80

Save as webapp-green.yaml and apply:

$ kubectl apply -f webapp-green.yaml

Output

deployment.apps/webapp-green created

At this stage:

• webapp-blue is live.
• webapp-green is deployed and running, but not receiving traffic yet.

Step 3: Test the Green version

We can test the Green version without switching traffic by port-forwarding to a Green pod:

$ kubectl get pods -l version=green

Output

NAME                            READY   STATUS    RESTARTS   AGE
webapp-green-7cc49bf84b-cmkp8   1/1     Running   0          38s
webapp-green-7cc49bf84b-f4hdd   1/1     Running   0          38s

$ kubectl port-forward webapp-green-7cc49bf84b-cmkp8 8080:3000

Output

Forwarding from 127.0.0.1:8080 -> 3000
Forwarding from [::1]:8080 -> 3000
Handling connection for 8080

Visit http://localhost:8080 to see if it works as expected.

Step 4: Switch traffic from Blue to Green

To switch traffic to the Green version, simply update the Service to point to the Green pods.

Edit webapp-service.yaml and change:

selector:
  version: blue

To,

selector:
  version: green

Apply the updated file:

$ kubectl apply -f webapp-service.yaml

Output

service/webapp configured

That’s it! Now the Service is routing traffic to the Green deployment. We’ve successfully performed a Blue-Green deployment.

Rolling Back

If something goes wrong, you can easily roll back by switching the selector back to Blue:

selector:
  version: blue

Then apply again:

$ kubectl apply -f webapp-service.yaml

Output

service/webapp configured

Automate with kubectl patch

To switch from Blue to Green via the command line (without editing YAML), you can use:

$ kubectl patch service webapp-service -p '{"spec":{"selector":{"version":"green"}}}'

Output

service/webapp-service patched

To roll back:

$ kubectl patch service webapp-service -p '{"spec":{"selector":{"version":"blue"}}}'

Output

service/webapp-service patched

Verifying the Setup

Check which pods are running:

$ kubectl get pods -l version=blue

Output

NAME                           READY   STATUS    RESTARTS   AGE
webapp-blue-6d9f769cd6-2558w   1/1     Running   0          13m
webapp-blue-6d9f769cd6-z4zff   1/1     Running   0          13m

Check the active endpoints for the Service:

$ kubectl get endpoints webapp-service

Output

NAME             ENDPOINTS                     AGE
webapp-service   10.244.1.7:80,10.244.1.8:80   13m

Conclusion

Blue-Green deployments are a powerful way to release updates safely. With Kubernetes, implementing this pattern is straightforward using multiple deployments and switching Service selectors. It gives us confidence to release frequently without fearing downtime or irreversible issues.