Blue-Green Deployment
In Kubernetes, Blue-Green Deployment allows deploying new application versions without downtime by switching traffic between two environments (Blue and Green), utilizing native features like Services, Ingress, and rolling updates, but still requires careful orchestration.
How Blue-Green Deployment Works in Kubernetes
Blue Environment:
- The Blue environment is the current version of the application, with running Pods (containers) behind a Kubernetes Service, routing all user traffic to this environment.
Green Environment:
- When a new version of the application is ready, a Green environment is created with new Pods running the updated version, but traffic is not initially routed to it.
Service Switching:
- Kubernetes Services or Ingress objects route traffic to the correct set of Pods, and after verifying the Green environment, traffic is switched from the Blue environment to the Green environment by updating the Service definition.
Steps for Blue-Green Deployment in Kubernetes
Deploy the "Blue" Environment
Let’s assume you already have an application running (version 1.0) in a Blue environment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: v1
template:
metadata:
labels:
app: my-app
version: v1
spec:
containers:
- name: my-app-container
image: my-app:1.0
And the Kubernetes Service is routing traffic to it:
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
version: v1
ports:
- port: 80
targetPort: 8080
Create the "Green" Environment
Deploy a new version of the application (version 2.0) in a separate Deployment, but with the same app label:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
spec:
replicas: 3
selector:
matchLabels:
app: my-app
version: v2
template:
metadata:
labels:
app: my-app
version: v2
spec:
containers:
- name: my-app-container
image: my-app:2.0
This creates a set of Pods running the new version of the application, but the Service still routes traffic to the Blue environment (version 1.0).
Test the Green Environment
At this point, you can verify and test the Green environment (version 2.0) by either:
Exposing the Green environment via a temporary Service or Ingress and checking it manually.
Running internal tests or integration checks.
Switch Traffic to the Green Environment
Once you're confident the new version is stable, modify the Service to point to the Green environment by changing the selector
:
yamlCopy codeapiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
version: v2
ports:
- port: 80
targetPort: 8080
This switches traffic from version 1.0 (Blue) to version 2.0 (Green). Kubernetes ensures that traffic is routed to the new Pods in the Green environment.
Decommission the Blue Environment
After ensuring that everything works fine in the Green environment, you can scale down or remove the Blue environment (version 1.0)
kubectl delete deployment app-blue
Alternatively, you can keep the Blue environment for easy rollback.
Benefits of Blue-Green Deployment in Kubernetes
Zero downtime: Traffic is seamlessly switched between the two environments with no downtime.
Rollback capability: If something goes wrong with the Green environment, you can quickly switch traffic back to the Blue environment.
Isolation: The Blue and Green environments are completely isolated, reducing the risk of interference during the deployment process.
Rollback
If any issues arise after switching to the Green environment (version 2.0), you can quickly roll back by updating the Service to point back to the Blue environment:
kubectl edit service my-app-service
Change the selector
back to
selector:
app: my-app
version: v
This restores traffic to the previous version (version 1.0).
Advanced Use Case: Blue-Green with Ingress or Canary Deployments
You can also use Ingress to handle traffic routing by applying weighted routing between the Blue and Green environments. This allows you to gradually send a portion of traffic to the Green environment before fully switching.
Canary Deployments are often considered a variation of Blue-Green, where you incrementally roll out the new version to a small portion of users.
Blue-Green deployment in Kubernetes provides a seamless way to upgrade applications without downtime, ensuring a reliable path to roll back in case of issues, and Kubernetes makes this process easier by using Deployments and Services to manage and route traffic between different versions of your application.