In production, a container might be in a
Running state according to Docker, yet completely unable to serve HTTP traffic due to a deadlock, database connection timeout, or slow boot sequence. Probes and Rolling Updates guarantee zero-downtime application deployments.TL;DR (Quick Summary)#
- Probe Types:
startupProbe: Protects slow-starting applications during initial boot. Disables liveness/readiness checks until it succeeds.readinessProbe: Determines if the container is ready to accept incoming network traffic. If it fails, K8s removes the Pod IP from Service Endpoints immediately.livenessProbe: Determines if the container process is healthy. If it fails, Kubelet kills and restarts the container!
- Rolling Update Tuning:
maxSurge(how many extra pods can be created above desired count) andmaxUnavailable(how many pods can be offline during update).
1. The Three Health Probes Visualized#
graph TD
ContainerBoot["Container Initiated"] --> SP{"startupProbe
Succeeded?"}
SP -- No (Retry) --> SP
SP -- Yes --> ActiveProbes
subgraph ActiveProbes["Active Lifecycle Monitoring"]
RP{"readinessProbe
Passing?"}
RP -- Yes --> InEndpoints["Pod IP attached to Service Endpoints
(Receives Traffic)"]
RP -- No --> OutEndpoints["Pod IP removed from Service Endpoints
(No Traffic Dropped)"]
LP{"livenessProbe
Passing?"}
LP -- Yes --> KeepAlive["Keep Container Running"]
LP -- No --> Restart["Kubelet Restarts Container!"]
end
2. Production Manifest with Health Probes#
Create deployment-probes.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: resilient-web-app
namespace: default
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # Max 1 extra pod spawned (5 total)
maxUnavailable: 0 # NEVER drop below 4 active pods during update!
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
version: "1.0.0"
spec:
containers:
- name: web
image: nginx:1.25-alpine
ports:
- containerPort: 80
# 1. Startup Probe (Protects slow boots)
startupProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 10 # Gives up to 50s for boot
# 2. Readiness Probe (Traffic Routing)
readinessProbe:
httpGet:
path: /
port: 80
periodSeconds: 5
successThreshold: 1
failureThreshold: 2
# 3. Liveness Probe (Auto-Restart Deadlocks)
livenessProbe:
httpGet:
path: /
port: 80
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3Apply manifest:
kubectl apply -f deployment-probes.yaml3. Zero-Downtime Rolling Update & Rollback#
Triggering an Image Upgrade#
Update the deployment image version to 1.26-alpine:
kubectl set image deployment/resilient-web-app web=nginx:1.26-alpine --recordMonitor rolling update progress in real-time:
kubectl rollout status deployment/resilient-web-appExpected Terminal Output:
Waiting for deployment "resilient-web-app" rollout to finish: 1 out of 4 new replicas have been updated...
Waiting for deployment "resilient-web-app" rollout to finish: 2 out of 4 new replicas have been updated...
Waiting for deployment "resilient-web-app" rollout to finish: 3 of 4 updated replicas are available...
deployment "resilient-web-app" successfully rolled outInspecting Release Revision History#
kubectl rollout history deployment/resilient-web-appREVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deployment/resilient-web-app web=nginx:1.26-alpine --record=trueInstant Emergency Rollback#
If a bad code deployment breaks in production, roll back to the previous stable revision instantly:
kubectl rollout undo deployment/resilient-web-appExpected Terminal Output:
deployment.apps/resilient-web-app rolled back4. Summary & Next Steps#
Probes prevent routing traffic to unready containers, while tuned RollingUpdate strategies eliminate deployment downtime.
In Episode 15: Production Helm Charts & Package Deployment, we will bring all series concepts together, learning how to package, template, and deploy production Kubernetes applications using Helm!