Blue-Green Deployments

Switching production traffic between blue and green Kubernetes Services or load balancer target groups.

6 min readCI/CD & GitOpsPlatform

Blue-Green Concept

Blue-green deployment maintains two identical production environments. The blue environment serves live traffic. The green environment is idle. When you deploy, you release to green, verify it works, then switch traffic from blue to green. Green becomes the new live environment.

The key advantage is instant rollback. If something goes wrong, switch traffic back to blue. There is no need to rebuild or redeploy — the previous version is still running. This makes blue-green deployments one of the safest deployment strategies.

Kubernetes Blue-Green

Kubernetes blue-green with Services


# Blue deployment (current)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
  labels:
    app: myapp
    track: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      track: blue
  template:
    metadata:
      labels:
        app: myapp
        track: blue
    spec:
      containers:
        - name: myapp
          image: myapp:v1.0.0
          ports:
            - containerPort: 8080

---
# Service pointing to blue
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    track: blue
  ports:
    - port: 80
      targetPort: 8080

---
# Green deployment (new)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
  labels:
    app: myapp
    track: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      track: green
  template:
    metadata:
      labels:
        app: myapp
        track: green
    spec:
      containers:
        - name: myapp
          image: myapp:v2.0.0
          ports:
            - containerPort: 8080

The Service selector determines which deployment receives traffic. To switch from blue to green, update the Service selector from track: blue to track: green. Both deployments run simultaneously, but only one receives traffic.

Automated blue-green switch


apiVersion: v1
kind: ConfigMap
metadata:
  name: switch-deployment
data:
  switch.sh: |
    #!/bin/bash
    kubectl patch service myapp -p '{"spec":{"selector":{"track":"green"}}}'
    echo "Switched traffic to green"
    kubectl rollout status deployment/myapp-green
    echo "Green deployment is ready"
    echo "Blue deployment (v1) is still running for rollback"

The switch is a single kubectl patch command. It updates the Service selector atomically. Traffic flows to green immediately. The blue deployment remains running for instant rollback.

AWS ALB Blue-Green

AWS ALB target group switch


jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE }}
          aws-region: us-east-1

      - name: Deploy to green target group
        run: |
          aws elbv2 modify-rule \
            --rule-arn ${{ secrets.LB_RULE_ARN }} \
            --actions '[{
              "Type": "forward",
              "ForwardConfig": {
                "TargetGroups": [{
                  "TargetGroupArn": "${{ secrets.GREEN_TG_ARN }}",
                  "Weight": 100
                }]
              }
            }]'

      - name: Health check
        run: |
          for i in {1..30}; do
            STATUS=$(aws elbv2 describe-target-health \
              --target-group-arn ${{ secrets.GREEN_TG_ARN }} \
              --query 'TargetHealthDescriptions[0].TargetHealth.State' \
              --output text)
            if [ "$STATUS" = "healthy" ]; then
              echo "Green target group is healthy"
              exit 0
            fi
            sleep 10
          done
          echo "Health check failed"
          exit 1

The ALB rule is updated to forward traffic to the green target group. The health check loop verifies the new targets are healthy before confirming the deployment. If health checks fail, the rule can be reverted to the blue target group.

Instant Rollback

The primary benefit of blue-green is rollback speed. To rollback, simply switch the Service selector or ALB rule back to the previous environment. This takes seconds, not minutes. There is no rebuild, no redeploy, no container startup — just a traffic switch.

Database Migration Challenges

Database compatibility is critical

Blue-green deployments assume both environments use the same database. Schema changes must be backward-compatible — the old code (blue) and new code (green) must both work with the current schema. Use expand-and-contract migrations to achieve this.

Tradeoffs

Resource cost — you run double the infrastructure during the switch. This is temporary but significant.
Database compatibility — schema changes must be backward-compatible, limiting migration options.
Stateful services — databases, caches, and message queues cannot be easily duplicated.
Traffic switch — the switch is atomic but may cause brief connection drops for in-flight requests.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 5 · Platform

Deployment Strategies