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.
| Strategy | Downtime | Rollback | Resources | Complexity | Use Case |
|---|---|---|---|---|---|
| Rolling Update | Zero | Automatic | 1.25x | Low | Default, stateless apps |
| Blue-Green | Zero | Instant | 2x | Medium | Critical zero-downtime |
| Canary | Zero | Partial | 1.1x | High | Production testing |
| Recreate | Yes | Manual | 1x | Low | Stateful 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 Situation | Recommended Strategy |
|---|---|
| Standard stateless application | Rolling Update |
| Critical zero downtime + resource budget | Blue-Green |
| Progressive production validation | Canary |
| Database / stateful application | Recreate |
| Major migration with A/B testing | Canary + 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.
| Mistake | Symptom | Solution |
|---|---|---|
| No readinessProbe | Traffic to unready pods | Add an HTTP/TCP probe |
| maxUnavailable=100% | Downtime during rolling | Limit to 25% max |
| No resource limits | Evicted pods | Define requests and limits |
| Image tag :latest | Unpredictable version | Use immutable tags |
| Untested rollback | Panic during incident | Test 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:
- LFS458 Kubernetes Administration: 4 days to master rolling updates, blue-green, and canary in real conditions
- LFD459 Kubernetes for Application Developers: 3 days to integrate your deployments into your CI/CD pipelines
- Kubernetes Fundamentals: 1 day to discover the basic concepts if you're starting out