Kubernetes Deployment Strategies

Kubernetes Deployment Strategies Compared

Choosing the right deployment strategy impacts downtime, risk, and rollback speed. Kubernetes supports rolling updates natively, while canary and blue-green require additional tooling. Understanding the trade-offs helps you pick the right strategy for each service.

Rolling Update (Default)

Gradually replaces old pods with new ones:

apiVersion: apps/v1
kind: Deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%        # Extra pods during update
      maxUnavailable: 25%   # Pods that can be unavailable

Pros: Zero downtime, built-in, no extra tools. Cons: Both versions run simultaneously, harder to test with real traffic before full rollout.

Blue-Green Deployment

Run two identical environments and switch traffic at once:

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

---
# Switch traffic by updating Service selector
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    version: green  # Change from 'blue' to 'green'

Pros: Instant rollback (switch selector back), full testing before traffic switch. Cons: 2x resource usage during deployment.

Canary Deployment

Route a small percentage of traffic to the new version:

# Using Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: {duration: 5m}
      - setWeight: 20
      - pause: {duration: 10m}
      - setWeight: 50
      - pause: {duration: 10m}
      - setWeight: 100
      analysis:
        templates:
        - templateName: success-rate
        startingStep: 1

Pros: Minimal blast radius, real traffic validation, automated promotion/rollback. Cons: Requires Argo Rollouts or Flagger, more complex setup.

Canary with Automated Analysis

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 60s
    successCondition: result[0] >= 0.99
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status=~"2.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

This automatically rolls back if the success rate drops below 99% during the canary phase.

Strategy Comparison

When to Use Each

• Rolling updates — Default for most services, especially internal microservices
• Blue-green — Database migrations, major version changes requiring instant rollback
• Canary — Customer-facing services where you want to validate with real traffic

Eazy SaaS Tip: We implement Argo Rollouts for our clients' critical services with automated Prometheus analysis. This catches performance regressions before they affect more than 5% of users — turning every deployment into a safe, measured rollout.