Cheatsheet5 min read

Kubernetes Deployment Strategies: Complete Comparison Table

SFEIR Institute

Key Takeaways

  • 'Rolling Update: progressive update with zero downtime, automatic rollback'
  • Blue-Green: two complete environments, instant switch, consumes 2x the resources
  • Canary: gradual deployment, testing on subset, early problem detection
TL;DR: Kubernetes deployment strategies (Rolling Update, Blue-Green, Canary, Recreate) determine how you update your applications in production. This comparison table helps you choose the right strategy based on your risk tolerance, available resources, and availability requirements.

These skills are at the core of the LFS458 Kubernetes Administration training.

Kubernetes Deployment Strategies Comparison Table

With 82% of container users running Kubernetes in production, mastering your deployment strategies is essential. Consult this table before every production deployment.

StrategyDowntimeRollbackResourcesComplexityUse Case
Rolling UpdateZeroAutomatic1.25xLowDefault, stateless apps
Blue-GreenZeroInstant2xMediumCritical zero-downtime
CanaryZeroPartial1.1xHighProduction testing
RecreateYesManual1xLowStateful apps, DB
Key takeaway: If you're starting out, use Rolling Update by default. It's Kubernetes' native strategy, built into every Deployment.

How to Configure Rolling Update (Default Strategy)

Rolling Update is the Kubernetes deployment strategy you use implicitly. Kubernetes replaces your pods progressively.

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1        # Extra pods during update
maxUnavailable: 1  # Max unavailable pods
template:
spec:
containers:
- name: app
image: my-app:v2
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 3

Check your rolling update progress:

# Monitor deployment in real-time
kubectl rollout status deployment/my-app

# Version history
kubectl rollout history deployment/my-app

# Immediate rollback if problem
kubectl rollout undo deployment/my-app

For complete kubectl commands, consult the kubectl cheat sheet.

How to Implement Blue-Green Deployment

Blue-Green Deployment offers instant rollback. You maintain two identical environments and switch traffic via the Service.

# Service pointing to active environment
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
selector:
app: my-app
version: blue  # Switch to 'green' to swap
ports:
- port: 80
targetPort: 8080
# Deploy new version (green)
kubectl apply -f deployment-green.yaml

# Verify green is working
kubectl get pods -l version=green

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

# Instant rollback if needed
kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'
Key takeaway: Blue-Green doubles your required resources. Reserve this strategy for critical applications where you cannot afford any interruption.

How to Configure Canary Deployment

Canary lets you test in production on a percentage of your traffic. Integrate this approach into your CI/CD pipeline.

# Canary deployment (10% of traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-canary
spec:
replicas: 1  # 1 canary pod for 9 stable pods = 10%
template:
metadata:
labels:
app: my-app
track: canary
spec:
containers:
- name: app
image: my-app:v2-candidate
# Monitor canary metrics
kubectl logs -l track=canary -f

# Increase progressively (scale canary, scale down stable)
kubectl scale deployment my-app-canary --replicas=3
kubectl scale deployment my-app-stable --replicas=7

# Promote canary to stable
kubectl set image deployment/my-app-stable app=my-app:v2-candidate
kubectl delete deployment my-app-canary

Your deployment strategies constitute the primitives of Kubernetes orchestration.

When to Use Recreate?

Recreate deletes all pods before creating new ones. Use this strategy only for stateful applications or databases.

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-database
spec:
strategy:
type: Recreate  # Complete shutdown before restart
template:
spec:
containers:
- name: postgres
image: postgres:15
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
Key takeaway: Recreate implies downtime. Prefer this strategy for applications that don't support multiple simultaneous versions.

Choosing Your Kubernetes Deployment Strategy

IT teams spend 34 working days per year solving Kubernetes problems. Choose the right strategy to reduce this time.

Your SituationRecommended Strategy
Standard stateless applicationRolling Update
Critical zero downtime + resource budgetBlue-Green
Progressive production validationCanary
Database / stateful applicationRecreate
Major migration with A/B testingCanary + Feature Flags

Quick Decision Tree

Does your app support multiple simultaneous versions?
|-- NO --> Recreate
|-- YES --> Do you have 2x the resources?
|-- YES --> Blue-Green (instant rollback)
|-- NO --> Do you want to test on % of users?
|-- YES --> Canary
|-- NO --> Rolling Update

Common Mistakes to Avoid

These pitfalls frequently affect teams configuring their deployments. Check these points before deploying.

MistakeSymptomSolution
No readinessProbeTraffic to unready podsAdd an HTTP/TCP probe
maxUnavailable=100%Downtime during rollingLimit to 25% max
No resource limitsEvicted podsDefine requests and limits
Image tag :latestUnpredictable versionUse immutable tags
Untested rollbackPanic during incidentTest kubectl rollout undo
# Check your probes before deployment
kubectl get deployment my-app -o jsonpath='{.spec.template.spec.containers[0].readinessProbe}'

# Validate resources
kubectl describe deployment my-app | grep -A4 "Limits:\|Requests:"

To diagnose your deployments, consult the Kubernetes Monitoring and Troubleshooting guide.

Integration with GitOps

GitOps automates your deployment strategies. Configure ArgoCD or Flux to apply your manifests automatically.

# ArgoCD Application example with Canary
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 5m}
- setWeight: 50
- pause: {duration: 10m}
- setWeight: 100

To combine deployment strategies with autoscaling, size your HPAs based on post-deployment traffic spikes.

Key takeaway: With 80% of organizations running 20+ clusters in production, automate your deployments via GitOps rather than manually managing each cluster.

Get Started with Practice

The Kubernetes Training: Complete Guide accompanies you from system administrator fundamentals to advanced deployment strategies.

Get trained in Kubernetes deployment strategies: