DevOps & Kubernetes (50 Qs)•Part 3: Production K8s Scaling, Reliability & SRE (26 - 35)
Zero-Downtime Rolling Updates: maxSurge, maxUnavailable, readiness gates, and preStop socket draining.
Architecture of a True Zero-Downtime Deployment
A rolling update replaces old Pods (v1) with new Pods (v2) incrementally. To ensure zero dropped packets or 502 Bad Gateway errors, four configurations must be aligned.
vbnet
Deploying v2 with maxSurge: 25%, maxUnavailable: 0:
Step 1: Current state (4 v1 Pods running, 100% capacity).
Step 2: Surge 1 v2 Pod (5 total Pods). v2 boots and passes Readiness Probe.
Step 3: Add v2 to Service Endpoints.
Step 4: Send SIGTERM to 1 v1 Pod (executes preStop: sleep 10).
Step 5: Repeat until all 4 Pods are upgraded to v2. Capacity never drops below 100%.
Production Zero-Downtime Deployment Manifest
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-service
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # Provision 1 extra pod before killing an old one
maxUnavailable: 0 # NEVER allow capacity to drop below 4 replicas
template:
spec:
terminationGracePeriodSeconds: 45
containers:
- name: app
image: registry.example.com/checkout:v2.0.0
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 10"] # Wait for iptables rules to update
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
failureThreshold: 2
The 3 Root Causes of Rolling Update Downtime
- Setting
maxUnavailable: 25%on small replica counts: If you only have 2 replicas, capacity drops by 50% during the rollout. - Missing Readiness Probe: Kubernetes assumes the pod is ready the second the container starts, sending user traffic into an uninitialized app.
- Missing
preStop: sleep 10: The old pod dies before Kube-proxy removes its IP from iptables, causing in-flight requests to receive connection refused errors.