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.
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 node12. Create a Namespace for the Blue‑Green Setup
kubectl create ns blue-green3. 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: 80Apply the manifest: kubectl apply -f lan.yaml Verify the pods are running:
kubectl get pods -n blue-green4. 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.yaml5. 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.yamlAccess 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.yamlAfter 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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
