CKAD — Readiness Probes

Readiness Probe — Control Traffic

A readiness probe determines if a Pod should receive traffic. When it fails, the Pod’s IP is removed from its Service’s endpoints. When it passes again, the Pod is added back. The container is not restarted.

HTTP Readiness Probe

apiVersion: v1
kind: Pod
metadata:
  name: web-readiness
  labels:
    app: web
spec:
  containers:
  - name: web
    image: nginx:1.27
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 2

kubectl apply -f web-readiness.yaml

# If /ready returns 404, the Pod is not "Ready"
kubectl get pod web-readiness
# READY: 0/1 — readiness probe is failing

# The Pod is running but NOT receiving traffic
kubectl describe pod web-readiness | grep -A5 Conditions
# Ready: False

Real-World Example: App with Database Dependency

A common pattern — separate endpoints for liveness and readiness:

apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
spec:
  containers:
  - name: api
    image: myapp:v1
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    livenessProbe:
      httpGet:
        path: /health/alive
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

Your /health/ready endpoint checks if the database connection is established. Your /health/alive endpoint checks if the process is responsive. This way:

• If the database goes down → readiness fails → traffic stops → but the Pod keeps running
• If the app deadlocks → liveness fails → container restarts

Key difference: Readiness probe failures remove the Pod from Service endpoints. Liveness probe failures restart the container. Use different health endpoints for each.

---

Next: Startup Probes