Cloud Native 8 min read

How to Implement Blue‑Green Deployments on Kubernetes Without Downtime

This guide explains the blue‑green deployment concept, outlines its pros and cons, and provides a step‑by‑step Kubernetes tutorial—including image loading, namespace creation, deployment manifests, service configuration, and traffic switching—to achieve zero‑downtime releases.

Full-Stack DevOps & Kubernetes
Full-Stack DevOps & Kubernetes
Full-Stack DevOps & Kubernetes
How to Implement Blue‑Green Deployments on Kubernetes Without Downtime

What Is Blue‑Green Deployment?

Blue‑green deployment uses two parallel environments: the "green" environment serves live traffic, while the "blue" environment runs the new version for testing. Once the blue environment passes verification, traffic is switched from green to blue, allowing a seamless upgrade without affecting users.

The blue environment is isolated from external users, enabling pre‑release testing and quick rollback by simply redirecting traffic back to the green environment.

Advantages and Disadvantages

Advantages

No downtime during updates, reducing risk.

Easy rollback by changing routing or DNS.

Disadvantages

Higher cost because two full environments are required.

Potential for simultaneous failures if the new version introduces critical bugs.

Requires careful isolation; on shared machines (Docker/VM) the environments can interfere.

Misconfiguration of load balancers, reverse proxies, or DNS can prevent traffic switching.

Implementing Blue‑Green Deployment on Kubernetes

Below is a practical lab that demonstrates the process.

1. Load Docker Images onto Cluster Nodes

docker load -i myapp-lan.tar.gz   # on node2
docker load -i myapp-lv.tar.gz    # on node1

2. Create a Namespace for the Blue‑Green Setup

kubectl create ns blue-green

3. Define the Blue (New) Deployment (lan.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  namespace: blue-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

Apply the manifest: kubectl apply -f lan.yaml Verify the pods are running:

kubectl get pods -n blue-green

4. Define the Green (Current) Deployment (lv.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
  namespace: blue-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
kubectl apply -f lv.yaml

5. Create a Service that Initially Targets the Green Deployment

apiVersion: v1
kind: Service
metadata:
  name: myapp-lan
  namespace: blue-green
  labels:
    app: myapp
    version: v2
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    name: http
  selector:
    app: myapp
    version: v2
kubectl apply -f service_lanlv.yaml

Access the service at http://<k8s‑master‑IP>:30062 to confirm the green version is serving traffic.

6. Switch the Service to the Blue Deployment

Update the service selector to point to the blue version (v1):

apiVersion: v1
kind: Service
metadata:
  name: myapp-lan
  namespace: blue-green
  labels:
    app: myapp
    version: v1
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    name: http
  selector:
    app: myapp
    version: v1
kubectl apply -f service_lanlv.yaml

After applying, the same URL now routes to the blue deployment. Monitor the new pods; if issues arise, revert the selector back to version v2.

When the blue environment is confirmed stable, the original green environment can be decommissioned, freeing resources for the next release cycle.

cloud-nativeDockerKubernetesDevOpsblue-green deploymentService Switching
Full-Stack DevOps & Kubernetes
Written by

Full-Stack DevOps & Kubernetes

Focused on sharing DevOps, Kubernetes, Linux, Docker, Istio, microservices, Spring Cloud, Python, Go, databases, Nginx, Tomcat, cloud computing, and related technologies.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.