CKAD — Startup Probes

Startup Probe — Handle Slow Apps

Some applications take a long time to start — loading large datasets, running migrations, or warming caches. A startup probe gives the app extra time to start before liveness probes kick in.

apiVersion: v1
kind: Pod
metadata:
  name: slow-app
spec:
  containers:
  - name: app
    image: myapp:v1
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10
      # Total time: 30 × 10 = 300 seconds (5 minutes to start)
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5

How it works: The startup probe runs first. It allows up to 300 seconds (30 failures × 10 seconds) for the app to start. Once the startup probe succeeds once, it stops and the liveness/readiness probes take over. If the startup probe never succeeds, Kubernetes kills the container.

Combining All Three Probes

Here is a production-ready example with all three probes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp:v2
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /healthz
            port: 8080
          failureThreshold: 20
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 10
          failureThreshold: 3
          timeoutSeconds: 3
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 5
          failureThreshold: 2
          timeoutSeconds: 2
        resources:
          requests:
            cpu: 100m
            memory: 128Mi

Probe execution order:

1. Startup probe runs until the app passes its first check (up to 100 seconds)
2. Liveness probe begins — restarts the container if the app becomes unresponsive
3. Readiness probe begins — controls whether traffic is routed to this Pod

Debugging Probe Failures

When probes fail, use these commands to investigate:

# Check Pod events for probe failures
kubectl describe pod api-server | grep -A5 Events

# Common event messages:
# "Liveness probe failed: Get http://10.0.0.5:8080/healthz: connection refused"
# "Readiness probe failed: HTTP probe failed with statuscode: 503"

# Check if the endpoint works from inside the container
kubectl exec api-server -- curl -s localhost:8080/healthz

# Check container restart count
kubectl get pod api-server -o jsonpath='{.status.containerStatuses[0].restartCount}'

Debugging checklist:

• Check kubectl describe pod events for probe failure messages
• Verify the health endpoint is accessible inside the container with kubectl exec
• Check initialDelaySeconds — is the probe starting before the app is ready?
• Check timeoutSeconds — is the probe timing out due to slow responses?
• Check failureThreshold — is it too aggressive for your app?

---

Next: Hands-On Lab