Introduction #
Zero-downtime deployments have become indispensable in modern DevOps contexts. One of the most proven strategies for this is the so-called Blue-Green Deployment. This article describes how a Blue-Green deployment can be implemented with Kubernetes, explains the advantages and disadvantages, and walks through an example implementation using concrete YAML definitions.
How It Works #
graph LR
LB[Load Balancer] -->|Active Traffic| Blue[Blue Environment
Production v1.0.0]
LB -.->|No Traffic
Ready for Switch| Green[Green Environment
New Version v2.0.0]
Blue --> P1[Pod 1
version: blue]
Blue --> P2[Pod 2
version: blue]
Blue --> P3[Pod 3
version: blue]
Green --> P4[Pod 4
version: green]
Green --> P5[Pod 5
version: green]
Green --> P6[Pod 6
version: green]
style Blue fill:#4285f4,stroke:#333,stroke-width:2px,color:#fff
style Green fill:#34a853,stroke:#333,stroke-width:2px,color:#fff
style LB fill:#ea4335,stroke:#333,stroke-width:2px,color:#fff
The Blue-Green deployment concept is based on two parallel but independent environments: an active one (in this case “Blue”) and a prepared new version (here: “Green”). All live traffic is controlled via a Kubernetes service and routed to the currently active version. The new version is deployed in the Green environment, tested, and can be taken live after successful validation by simply switching the service selector.
Initial Setup #
In the first step, a deployment named myapp-blue is created. This environment represents the
currently productive version of your application.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
spec:
containers:
- name: myapp
image: myapp:1.0.0
ports:
- containerPort: 80
The deployment consists of three replicas of your application version 1.0.0, which are labeled with version: blue. This label is crucial as it tells the Kubernetes service later which pods should be addressed.
To deploy myapp-blue, save the file as blue-deployment.yml and apply it to the Kubernetes cluster using:
kubectl apply -f blue-deployment.yml
Access via Kubernetes Service #
To route traffic to the Blue environment, a Kubernetes service is defined. This service acts as a load balancer for all assigned pods with the corresponding label. We save this configuration as service.yml.
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
version: blue
ports:
- port: 80
targetPort: 80
Here you can see that the service selects all pods that have both the app: myapp and version: blue labels. This routes all incoming traffic to the productive Blue version.
Preparing the Green Environment #
The Green environment is deployed in parallel to the existing production environment. It contains a newer version of your application that can initially be tested internally.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: green
template:
metadata:
labels:
app: myapp
version: green
spec:
containers:
- name: myapp
image: myapp:2.0.0
ports:
- containerPort: 80
Version 2.0.0 runs in separate pods. These pods receive the version: green label,
which means they are initially not considered by the service and therefore receive no live traffic.
You can access them, for example, via port forwarding or an internally accessible service to
ensure functionality.
The configuration is saved in the file green-deployment.yml and deployed using the following command:
kubectl apply -f green-deployment.yml
Going Live with the New Version #
After successful testing of the Green environment (for example via temporary port forwarding or internal requests), the switchover is initiated. This is done by updating the selector in the service:
spec:
selector:
app: myapp
version: green
Then apply the change with the following command:
kubectl apply -f service.yml
From this point on, all live traffic is routed to the new Green version without any downtime.
Rollback in Case of Issues #
If problems occur after the Green version goes live, an immediate rollback is possible. To do this, set the service selector back to the Blue environment:
kubectl patch service myapp-service -p '{"spec":{"selector":{"app":"myapp", "version":"blue"}}}'
Since both environments run in parallel, the rollback is completed within seconds.
Advantages #
- No downtime: The switchover happens immediately and without interruption.
- Easy rollbacks: The previous version remains available and can be reactivated at any time.
- Separate testing environment: The new version can be validated in a production-like environment without external accessibility.
- Flexibly combinable: Blue-Green deployment can be further optimized with ingress rules, feature flags, or traffic splitting.
Disadvantages #
- No clear production environment: With each release, the active environment switches between Blue and Green. Either you make the effort to update the other environment as well, or you need to be aware before the release which deployment is currently productive.
- Redundant operation: You must provide (at least during the switchover) double the server capacity to operate both environments simultaneously.
Conclusion #
Blue-Green deployment with Kubernetes is a proven method for conducting releases safely, controlled, and without downtime. By separating deployment and go-live, you significantly increase the reliability and maintainability of your infrastructure. The implementation shown here can easily be integrated into existing CI/CD pipelines and forms a solid foundation for modern deployment management.
For further automation, tools like ArgoCD, Flux, or GitOps-based processes can be used. These also allow, for example, automated switching or rollback via commit in a Git repository.
If you have questions or suggestions, please feel free to contact me through the channels listed below.
