Skip to content
Learni
View all tutorials
DevOps

How to Implement Blue-Green Deployment with Kubernetes in 2026

Lire en français

Introduction

Blue-Green deployment reduces production risks by maintaining two identical environments. One (Blue) remains active while the other (Green) is updated. Instant traffic switching via the Kubernetes service ensures zero downtime. This strategy has become essential in 2026 for critical applications requiring high availability.

Prerequisites

  • Kubernetes 1.28+
  • kubectl configured
  • Advanced knowledge of YAML and services
  • Helm optional but recommended
  • Cluster with at least 3 nodes

Initial Blue Manifest

blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  labels:
    app: myapp
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:1.0.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10

This manifest deploys the stable Blue version with 3 replicas and a liveness probe. The labels enable precise routing through the service.

Updated Green Manifest

green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
  labels:
    app: myapp
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:1.1.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5

The Green deployment uses a new image. Readiness probes ensure traffic is only routed to ready pods.

Routing Service

service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

The selector initially points to Blue. Changing the version label to green performs an instant switch without recreating the service.

Switch Script

switch.sh
#!/bin/bash
set -e
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'
echo "Trafic basculé vers Green"
kubectl rollout status deployment/app-green --timeout=60s

This script updates the service selector to route traffic to Green. The rollout status verifies all pods are ready before confirming success.

Rollback Script

rollback.sh
#!/bin/bash
set -e
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"blue"}}}'
echo "Rollback effectué vers Blue"
kubectl rollout undo deployment/app-green

In case of issues, this script instantly restores Blue and rolls back the Green deployment to minimize impact.

Best Practices

  • Always keep Blue stable while updating Green
  • Implement comprehensive health checks
  • Automate rollback through CI/CD hooks
  • Monitor metrics for 15 minutes after the switch
  • Use separate namespaces to isolate environments

Common Mistakes to Avoid

  • Forgetting to update probes before switching
  • Failing to test Green in complete isolation
  • Ignoring persistent session management
  • Switching without automatic metric validation

Further Reading

Deepen these techniques with our advanced Kubernetes and zero-downtime deployment strategy courses: https://learni-group.com/formations