#kubernetes#docker#devops#deployment#best practices
Zero-downtime deployments with Kubernetes rolling updates
ยท12 min read
Welcome to devops.blog! This is your first post. Replace this content with your own and start sharing your knowledge.
The problem with naive deployments
When you run kubectl set image deployment/my-app app=my-app:v2, Kubernetes starts
replacing your pods immediately. Without the right configuration, this means:
- Requests hitting pods that are starting up but not yet ready
- Old pods being killed before new ones pass health checks
- No automatic rollback if the new version is broken
The right way: readiness probes
Tell Kubernetes exactly when a pod is ready to accept traffic:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # how many extra pods during rollout
maxUnavailable: 0 # never kill a pod before a new one is ready
template:
spec:
containers:
- name: app
image: my-app:v2
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
failureThreshold: 3Monitoring the rollout
# Watch the rollout in real-time
kubectl rollout status deployment/my-app --timeout=5m
# Check rollout history
kubectl rollout history deployment/my-app
# Instant rollback if something's wrong
kubectl rollout undo deployment/my-appPodDisruptionBudgets for extra safety
Prevent too many pods from being unavailable simultaneously:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-app-pdb
spec:
minAvailable: 2 # always keep at least 2 pods running
selector:
matchLabels:
app: my-appConclusion
Zero-downtime deployments aren't magic โ they require telling Kubernetes:
- When pods are ready โ via
readinessProbe - How to roll โ via
RollingUpdatestrategy withmaxUnavailable: 0 - How to stay available โ via
PodDisruptionBudget
Set these up once per deployment and you'll never have a maintenance window again.
Stay in the loop
New posts, tools & scripts โ no spam, unsubscribe anytime.