Deployment Strategies: Blue-Green, Canary & Rolling

This reference covers practical deployment techniques for updating services in production environments, including blue-green, canary, and rolling strategies. These approaches address how to minimize downtime, reduce risk, and enable rollback when deployments fail.

When to Use Each Strategy

Deploy a New Version with Zero Downtime

Use blue-green deployments when you need to switch between two identical environments with minimal service interruption. This strategy requires maintaining two complete sets of infrastructure, each running the same application in different states (blue = current, green = new).

# Example: Switch traffic from blue to green
kubectl patch service my-app-service -p '{"spec":{"selector":{"version":"green"}}}'

Deploy Gradually with Controlled Risk

Use canary deployments when you want to release a new version to a small subset of users first, then gradually expand. This approach is ideal for high-traffic applications where immediate full rollout could be risky.

# Example: Route 10% of traffic to new version
kubectl patch virtualservice my-app-vs -p '{
  "spec": {
    "http": [
      {
        "route": [
          {"destination": {"host": "my-app", "subset": "v1"}, "weight": 90},
          {"destination": {"host": "my-app", "subset": "v2"}, "weight": 10}
        ]
      }
    ]
  }
}'

Deploy Without Stopping Services

Use rolling deployments when you can update instances one by one while keeping the service available. This is the most common approach for containerized applications, particularly in Kubernetes.

# Example: Rolling update with specific image
kubectl set image deployment/my-app my-app=nginx:1.25

Blue-Green Deployment Implementation

Prepare Two Identical Environments

Create two complete environments with separate infrastructure, each containing a full copy of application code and data.

# Example: Service selector for blue environment
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    version: blue
  ports:
    - port: 80

Switch Traffic Between Environments

Update service selectors or load balancer routing rules to direct traffic to the new environment.

# Example: Switch traffic to green environment
kubectl patch service my-app-service -p '{"spec":{"selector":{"version":"green"}}}'

Handle Rollback

If issues arise, switch traffic back to the previous environment immediately.

# Example: Rollback to blue environment
kubectl patch service my-app-service -p '{"spec":{"selector":{"version":"blue"}}}'

Key Considerations

• Both environments must share identical configuration and data stores.
• Traffic switching requires careful handling of connection draining and session persistence.
• Blue-green deployments require double the infrastructure resources.
• Rolling updates can be combined with blue-green for hybrid approaches.

Canary Deployment Implementation

Define Traffic Split Rules

Configure routing to direct a percentage of traffic to the new version while keeping most users on the stable version.

# Example: Istio VirtualService for 10% canary
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app-vs
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90
        - destination:
            host: my-app
            subset: v2
          weight: 10

Monitor and Adjust Traffic

Gradually increase traffic to the new version based on health checks, metrics, or manual intervention.

# Example: Increase canary traffic to 50%
kubectl patch virtualservice my-app-vs -p '{
  "spec": {
    "http": [
      {
        "route": [
          {"destination": {"host": "my-app", "subset": "v1"}, "weight": 50},
          {"destination": {"host": "my-app", "subset": "v2"}, "weight": 50}
        ]
      }
    ]
  }
}'

Handle Rollback

When problems occur, reduce or eliminate traffic to the new version.

# Example: Reduce canary traffic to 0%
kubectl patch virtualservice my-app-vs -p '{
  "spec": {
    "http": [
      {
        "route": [
          {"destination": {"host": "my-app", "subset": "v1"}, "weight": 100},
          {"destination": {"host": "my-app", "subset": "v2"}, "weight": 0}
        ]
      }
    ]
  }
}'

Key Considerations

• Canary deployments require a service mesh or routing layer capable of traffic splitting.
• Monitoring must track both stable and canary versions for performance differences.
• Rollbacks may require careful coordination to prevent partial rollouts.
• Canaries work best with stateless services that don't depend on specific instance behavior.

Rolling Deployment Implementation

Configure Update Strategy

Set deployment parameters to control how many instances update simultaneously.

# Example: Rolling update configuration
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
        - name: my-app
          image: nginx:1.25

Apply Updates

Deploy new images or configuration changes to trigger rolling updates.

# Example: Update deployment with new image
kubectl set image deployment/my-app my-app=nginx:1.26

Monitor Progress

Watch rollout status to ensure updates proceed correctly.

# Example: Check rollout status
kubectl rollout status deployment/my-app

Handle Failures

Roll back when issues occur, which can be automatic or manual.

# Example: Rollback to previous revision
kubectl rollout undo deployment/my-app

Key Considerations

• Rolling updates are most effective for stateless applications.
• Configure appropriate maxUnavailable and maxSurge values to balance availability and speed.
• Ensure all instances have compatible configuration during the update process.
• Rolling deployments require careful attention to health checks and readiness probes.

Failure Modes and Common Pitfalls

Blue-Green Switching Issues

Traffic switch failures occur when service endpoints are not ready or routing rules are incorrect. The most common silent failure is failing to drain connections before switching, which can cause dropped requests.

# Example: Verify endpoint readiness before switch
kubectl get endpoints my-app-service

Canary Traffic Misconfiguration

Incorrect weight distribution in virtual services causes unintended traffic patterns. A common issue is setting weights that don't sum to 100, leading to unexpected behavior.

# Example: Validate traffic split configuration
kubectl get virtualservice my-app-vs -o yaml

Rolling Update Conflicts

Rolling updates can fail when newer instances have compatibility issues with shared resources or data migrations. This often manifests as pods failing readiness checks.

# Example: Check pod status for update issues
kubectl get pods -l app=my-app

Resource Exhaustion

All strategies can cause resource contention. Blue-green deployments double resource usage, while canary deployments may require additional routing infrastructure.

# Example: Monitor resource usage during deployment
kubectl top pods -l app=my-app

Data Consistency Problems

When services use shared databases, updates may cause temporary inconsistency between versions. This is particularly problematic with schema changes.

# Example: Check database connectivity during update
kubectl exec -it pod/my-app-pod -- psql -c "SELECT version();"

Implementation Best Practices

Use Health Checks

Always configure readiness and liveness probes to ensure services are stable before accepting traffic.

# Example: Readiness probe configuration
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

Implement Rollback Procedures

Plan rollback procedures in advance and test them regularly to reduce recovery time during failures.

# Example: Create rollback script
kubectl rollout undo deployment/my-app --to-revision=1

Monitor During Deployment

Use monitoring tools to track service performance, error rates, and latency changes during updates.

# Example: Check metrics during deployment
kubectl get pods -l app=my-app -o jsonpath='{.items[*].status.containerStatuses[*].ready}'

Test in Staging First

Before deploying to production, test each strategy in a staging environment that mirrors production infrastructure.

# Example: Deploy to staging environment
kubectl apply -f staging-deployment.yaml

Common Command Variants and Confusions

Patch vs Apply

Use patch for partial updates when configuration is already defined.

# Correct: Partial update of existing service
kubectl patch service my-app-service -p '{"spec":{"selector":{"version":"green"}}}'

# Incorrect: Full replacement of service
kubectl apply -f new-service.yaml

Set Image vs Apply

Use set image for quick updates when you don't need full YAML changes.

# Correct: Quick image update
kubectl set image deployment/my-app my-app=nginx:1.25

# Incorrect: Full YAML replacement for simple image change
kubectl apply -f updated-deployment.yaml

Rollout Commands

Use rollout status to check progress, not just get pods.

# Correct: Check rollout status
kubectl rollout status deployment/my-app

# Incorrect: Just check pod status
kubectl get pods -l app=my-app

This page was rewritten on 15 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.