Stage 5 · Platform
Deployment Strategies
Rolling Updates
Tuning Kubernetes maxSurge, maxUnavailable, readiness probes, and PodDisruptionBudgets for safe rollouts.
Rolling Update Concept
Rolling updates gradually replace old pods with new pods. Kubernetes terminates old pods and creates new pods in a controlled manner, ensuring that the desired number of pods is always available. This is the default deployment strategy in Kubernetes.
Rolling updates are simple and resource-efficient — you do not need double the infrastructure. However, both old and new versions run simultaneously during the update, which requires backward-compatible changes.
Strategy Parameters
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:v2.0.0
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3maxSurge: 2 allows up to 2 extra pods during the update (6 + 2 = 8 total). maxUnavailable: 1 ensures at least 5 pods are always running. The readiness probe prevents traffic from reaching pods that are not ready.
| Parameter | Conservative | Aggressive |
|---|---|---|
| maxSurge | 25% (1 pod for 4 replicas) | 100% (all replicas) |
| maxUnavailable | 0 (no downtime) | 25% (faster rollout) |
| Recommended | maxSurge: 1, maxUnavailable: 0 | maxSurge: 100%, maxUnavailable: 0 |
Readiness Probes
containers:
- name: myapp
# HTTP check
readinessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Health-Check
value: "readiness"
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
successThreshold: 1
# TCP check
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
# Command check
readinessProbe:
exec:
command:
- /bin/sh
- -c
- "curl -f http://localhost:8080/health || exit 1"
initialDelaySeconds: 15
periodSeconds: 10Readiness probes determine whether a pod can receive traffic. A pod fails the readiness probe until the probe succeeds. This ensures that new pods are fully initialized before receiving traffic. HTTP checks are preferred for web services.
PodDisruptionBudgets
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: myapp-pdb
spec:
minAvailable: 4
selector:
matchLabels:
app: myapp
---
# Or use maxUnavailable
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: myapp-pdb-max
spec:
maxUnavailable: 2
selector:
matchLabels:
app: myappPDBs protect against voluntary disruptions during rolling updates. minAvailable: 4 ensures at least 4 pods are always running. maxUnavailable: 2 limits the number of pods that can be down simultaneously. PDBs apply to both rolling updates and node drains.
Progress Deadlines
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
annotations:
deployment.kubernetes.io/revision: "5"
spec:
replicas: 6
progressDeadlineSeconds: 600
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0progressDeadlineSeconds tells Kubernetes how long to wait for the deployment to make progress before reporting failure. If the deployment does not progress within this time, the rollout is considered stuck. The default is 600 seconds (10 minutes).
Rolling Update Pitfalls
- Crash loops — if the new version crashes, Kubernetes keeps retrying. Set a maxSurge of 0 to prevent creating broken pods.
- Slow shutdown — if the old pods take too long to terminate, the rollout stalls. Use preStop hooks with short timeouts.
- Missing readiness probes — without probes, traffic hits pods before they are ready. Always configure readiness probes.
- Resource exhaustion — if new pods need more resources than available, the rollout stalls. Ensure cluster has capacity.
maxUnavailable: 0 ensures no existing pods are terminated until new pods are ready. This prevents downtime during rolling updates. The tradeoff is that you need maxSurge > 0, which temporarily increases resource usage.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.