K8
Kubernetes Deployment Strategies
Rolling updates, blue-green, canary, and progressive delivery patterns
Details
Language / Topic
KubernetesCategory
Deployment
Rules
balanced
- Use rolling updates (default) with maxSurge and maxUnavailable tuned for your availability requirements
- Implement canary deployments with Argo Rollouts or Flagger for gradual traffic shifting with automatic rollback
- Always set minReadySeconds to prevent cascading failures during rapid rollouts
- Use kubectl rollout undo for immediate rollback; keep revisionHistoryLimit high enough for rollback options
- Run database migrations as a separate Job before deploying application changes
- Rolling updates: set maxSurge: 25% and maxUnavailable: 0 for zero-downtime with controlled rollout speed
- Canary deployments: use Argo Rollouts or Flagger for automated progressive delivery with metric analysis
- Set minReadySeconds (10-30s) to ensure new pods are stable before continuing the rollout
- Rollback: kubectl rollout undo deployment/name; set revisionHistoryLimit: 10 to keep rollback options
- Database migrations: run as pre-deploy Jobs with backoff limits; ensure backward compatibility with N-1 schema
- Blue-green: use Argo Rollouts with activeService/previewService for instant cutover with preview testing
- Deployment gates: require passing readiness probes, metric thresholds (error rate, latency) before proceeding
- Use GitOps (ArgoCD, Flux) for declarative deployments — git commit triggers sync, not manual kubectl apply
- Progressive delivery: start at 5% traffic, analyze metrics for 5 minutes, increment to 25%, 50%, 100%
- Set resource requests accurately — under-provisioned pods during rollout cause cascading scheduling failures
- Monitor rollout progress: kubectl rollout status, Argo Rollouts dashboard, or CI/CD pipeline status checks