Kubernetes provides several deployment strategies to ensure zero-downtime updates and safe rollouts of new application versions. Understanding these strategies is crucial for maintaining reliable production systems.

Deployment strategy overview

Kubernetes deployment strategies determine how new versions of your application replace old ones. The choice depends on:

  • Risk tolerance: How critical is zero downtime?
  • Traffic patterns: Can you route traffic to multiple versions?
  • Rollback speed: How quickly can you revert if issues occur?
  • Resource constraints: Can you run multiple versions simultaneously?

Rolling update (default)

The default Kubernetes deployment strategy gradually replaces old pods with new ones.

How it works

  1. Creates new pods with the new version
  2. Terminates old pods as new ones become ready
  3. Maintains service availability throughout the process

Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # Can have 2 extra pods during update
      maxUnavailable: 1  # Max 1 pod unavailable at a time
  template:
    spec:
      containers:
      - name: app
        image: myapp:v2

Advantages

  • Zero downtime (when configured correctly)
  • Resource efficient (no need for double capacity)
  • Built into Kubernetes (no additional tools needed)

Disadvantages

  • Brief period with mixed versions
  • Rollback takes time (must wait for pods to terminate)
  • Potential for cascading failures if new version has issues

Blue-green deployment

Run two identical production environments: blue (current) and green (new version). Switch traffic instantly between them.

Implementation

# Blue deployment (current version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:v1

---
# Green deployment (new version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:v2

---
# Service selector (switch between blue/green)
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue  # Change to 'green' to switch
  ports:
  - port: 80
    targetPort: 8080

Switching traffic

# Switch to green
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'

# Rollback to blue
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"blue"}}}'

Advantages

  • Instant rollback (just switch service selector)
  • No mixed versions during transition
  • Easy to test new version before switching

Disadvantages

  • Requires double resources during deployment
  • Database migrations can be complex
  • More complex setup and management

Canary deployment

Gradually roll out new version to a small percentage of users, then increase if successful.

Implementation with Istio

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 9
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: app
        image: myapp:v1

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
spec:
  replicas: 1  # 10% of traffic
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: app
        image: myapp:v2

---
# Istio VirtualService for traffic splitting
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - match:
    - headers:
        canary:
          exact: "true"
    route:
    - destination:
        host: myapp
        subset: v2
      weight: 100
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

Native Kubernetes canary

# Canary deployment (10% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        track: canary
    spec:
      containers:
      - name: app
        image: myapp:v2

---
# Service with both stable and canary
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 80

Advantages

  • Low risk (only small percentage of users affected)
  • Real-world testing with production traffic
  • Gradual rollout reduces blast radius

Disadvantages

  • Requires traffic splitting mechanism (Istio, service mesh, or ingress controller)
  • More complex monitoring (need to track both versions)
  • Longer deployment process

A/B testing deployment

Similar to canary but based on user characteristics rather than percentage.

Implementation

# Use Istio or similar for header-based routing
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - match:
    - headers:
        user-segment:
          exact: "beta"
    route:
    - destination:
        host: myapp
        subset: v2
  - route:
    - destination:
        host: myapp
        subset: v1

Choosing the right strategy

Use rolling update when:

  • Application is stateless or handles version mixing well
  • Resource constraints are a concern
  • Simple rollback is acceptable

Use blue-green when:

  • Zero downtime is critical
  • Instant rollback is required
  • You have sufficient resources
  • Database migrations are straightforward

Use canary when:

  • You want to test with real production traffic
  • Risk mitigation is important
  • You have monitoring and alerting in place
  • Gradual rollout is preferred

Best practices

1. Health checks

Always configure proper health checks:

spec:
  containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

2. Resource limits

Set resource requests and limits:

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

3. Pod disruption budgets

Protect against voluntary disruptions:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: myapp

4. Monitoring and alerting

Monitor key metrics during deployments:

  • Error rates
  • Response times
  • Resource usage
  • Custom business metrics

5. Automated rollback

Set up automated rollback on failure:

spec:
  progressDeadlineSeconds: 600  # Rollback if not progressing
  revisionHistoryLimit: 10      # Keep old revisions for rollback

Conclusion

Choosing the right Kubernetes deployment strategy depends on your application’s requirements, risk tolerance, and infrastructure capabilities. Start with rolling updates for simplicity, then move to blue-green or canary deployments as your needs become more sophisticated.

Remember: Test your deployment strategy in staging first, and always have a rollback plan ready.