Fix a Broken Readiness Probe and Add Liveness and Startup Probes

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster.

Startup, readiness and liveness: one gate, one traffic switch, one restart trigger

The three probes answer different questions, and the kubelet reacts to each one differently. A failed startup or liveness probe gets the container killed and restarted under the Pod's restart policy. A failed readiness probe kills nothing; it only takes the Pod out of its Services' endpoints. Picking the wrong probe type turns a brief hiccup into a restart loop, which is why the exam expects you to know which is which.

container starts ──→ startupProbe (others paused until it passes, budget = failureThreshold × periodSeconds)
                       ├─→ readinessProbe  fail → removed from EndpointSlice, no restart
                       └─→ livenessProbe   fail → kubelet kills and restarts the container

1. Deploy a Pod whose readiness you control by hand

The example uses an unprivileged nginx build that listens on 8080, names that port web, and uses all three handler types: httpGet for startup, exec for readiness and tcpSocket for liveness. Readiness passes only while the file /tmp/ready exists. Save this as cka-probes-gate.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gatekeeper
  namespace: prepium-tutorial
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gatekeeper
  template:
    metadata:
      labels:
        app: gatekeeper
    spec:
      containers:
      - name: site
        image: nginxinc/nginx-unprivileged:1.27-alpine
        ports:
        - name: web
          containerPort: 8080
        startupProbe:            # gate: nothing else runs until this passes
          httpGet:
            path: /
            port: web
          periodSeconds: 3
          failureThreshold: 20   # 20 x 3s = up to 60s to start
        readinessProbe:          # traffic switch, never restarts anything
          exec:
            command: ["cat", "/tmp/ready"]
          periodSeconds: 4
        livenessProbe:           # restart trigger
          tcpSocket:
            port: web
          periodSeconds: 15
---
apiVersion: v1
kind: Service
metadata:
  name: gatekeeper
  namespace: prepium-tutorial
spec:
  selector:
    app: gatekeeper
  ports:
  - port: 9000
    targetPort: web

kubectl create namespace prepium-tutorial
kubectl apply -f cka-probes-gate.yaml
kubectl -n prepium-tutorial get pods -l app=gatekeeper
kubectl -n prepium-tutorial get endpointslices -l kubernetes.io/service-name=gatekeeper -o yaml | grep -A3 conditions

The Pod reaches Running but READY stays 0/1, and its endpoint shows ready: false. Nothing is broken: the startup gate passed, so readiness is now running and failing as designed. The named port works for the HTTP and TCP probes and for the Service's targetPort, so changing the number later means editing one line.

2. Flip the traffic switch

kubectl -n prepium-tutorial exec deploy/gatekeeper -- touch /tmp/ready
kubectl -n prepium-tutorial get pods -l app=gatekeeper -w     # Ctrl+C once READY is 1/1
kubectl -n prepium-tutorial exec deploy/gatekeeper -- rm /tmp/ready
kubectl -n prepium-tutorial get pods -l app=gatekeeper
kubectl -n prepium-tutorial exec deploy/gatekeeper -- touch /tmp/ready

Within one readiness period the Pod becomes ready and the endpoint turns ready: true; remove the file and it drops out again; the last command restores it. Watch the RESTARTS column: it stays at 0 throughout. That is readiness doing its job, pausing traffic without touching the process.

3. Break liveness and compare

kubectl -n prepium-tutorial patch deployment gatekeeper --type=json \
  -p='[{"op":"replace","path":"/spec/template/spec/containers/0/livenessProbe/tcpSocket/port","value":8081}]'
kubectl -n prepium-tutorial get pods -l app=gatekeeper -w

The new Pod starts, passes its startup probe, then fails three TCP checks 15 seconds apart (the default failureThreshold is 3) and is restarted; the RESTARTS count keeps rising and kubectl describe pod lists failed liveness probe events. Meanwhile the old Pod keeps serving: with one replica the default rolling update rounds maxUnavailable down to 0, and the new Pod (with no /tmp/ready) never becomes ready to replace it. Undo it with kubectl -n prepium-tutorial rollout undo deployment/gatekeeper.

4. Size the startup budget deliberately

The startup probe's worst-case allowance is failureThreshold × periodSeconds: here 20 × 3 seconds, so the app has up to a minute to answer before the kubelet kills it. A short period with a high threshold notices a fast start quickly while still tolerating a slow one. Liveness and readiness are held back until startup succeeds, so you do not need a long initialDelaySeconds on them.

Common mistakes

• Using liveness to check a dependency such as a database. When the dependency blips, every replica restarts at once; readiness would only pause traffic.
• A startup budget shorter than the real start time. The container is killed before it ever finishes booting and the Pod cycles through restarts.
• Setting successThreshold above 1 on a liveness or startup probe. The documentation requires 1 for both.
• Reading the phase instead of readiness. Running with READY 0/1 means no Service traffic reaches the Pod.

Cleanup: kubectl delete namespace prepium-tutorial. References: Configure liveness, readiness and startup probes, Pod lifecycle: container probes. Next, try a readiness probe on the wrong path or rollout recovery.