Liveness & Readiness Probes

Your application might be running, but is it actually healthy? Can it accept traffic? Kubernetes uses probes to continuously monitor container health and make intelligent decisions about traffic routing and restarts.

Liveness vs Readiness

Kubernetes distinguishes between two types of health:

• Liveness probe: If the liveness probe fails repeatedly, Kubernetes restarts the container. Use this to recover from deadlocks or hung processes.

• Readiness probe: If the readiness probe fails, Kubernetes removes the Pod from ready Service endpoints without restarting the container. Use this for apps that need warm-up time or temporarily can't serve requests.

Probe types

Common probe mechanisms include:

Kubernetes also supports gRPC health probes. This simulator demonstrates the HTTP, TCP, and exec configurations above.

Each probe has configuration parameters:

• initialDelaySeconds: wait before the first probe.
• periodSeconds: how often to probe.
• failureThreshold: consecutive failures before action.
• successThreshold: consecutive successes to be considered healthy.

Exploring the healthy-app

Our cluster has a healthy-app deployment with both probes configured. Check its status:

kubectl get pods

The healthy-app Pods show 1/1 in the READY column, indicating that the container is ready. This column is not a separate liveness result. Inspect the probe configuration:

kubectl describe pod <healthy-app-pod-name>

In the container section, you'll see the probe definitions:

• Liveness uses http-get http://:8080/healthz, checking every 10 seconds after an initial 5-second delay.
• Readiness uses http-get http://:8080/ready, checking every 5 seconds after an initial 3-second delay.

When readiness fails

Now look at slow-start-app:

kubectl get pods

Notice it shows 0/1 in the READY column even though the STATUS is Running. The container process is alive, but the readiness probe is failing.

Check the events:

kubectl describe pod <slow-start-app-pod-name>

You'll see Unhealthy warning events because the readiness probe returns a 503 status code. This means:

• The pod is not killed (liveness is fine or not configured)
• The pod is removed from Service endpoints (no traffic routed to it)
• Kubernetes keeps probing, and the pod will become ready once the probe passes

Deploying with probes

Let's deploy an application with both probes configured:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitored-app
  labels:
    app: monitored-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: monitored-app
  template:
    metadata:
      labels:
        app: monitored-app
    spec:
      containers:
      - name: monitored-app
        image: nginx:1.26.2
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 15
          failureThreshold: 3
          successThreshold: 1
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
          successThreshold: 1

The sandbox has this manifest stored as monitored-app.yaml. Apply and verify:

kubectl apply -f monitored-app.yaml
kubectl get pods
kubectl describe pod <monitored-app-pod-name>

Probes and rolling updates

Readiness probes help rolling updates by keeping unready Pods out of Service traffic. Availability also depends on replica count, rollout settings, capacity, and graceful shutdown. A probe can pass while an application still has bugs, so verify a real request too. The simulator simplifies rollout timing rather than reproducing every controller rule.

Best practices

• Use readiness to control traffic eligibility and liveness when restarting can resolve a failure.
• Configure a startup probe for applications that need time to initialize.
• Choose endpoints that reflect what each probe needs to check. Readiness and liveness may need different endpoints.
• Set probe delays and thresholds using observed startup and response times.
• Keep probe handlers inexpensive because they run frequently.
• Check the effect of shared dependencies. If every Pod becomes unready when the database fails, the entire application loses its ready endpoints.
• A liveness endpoint should detect a condition that restarting the process can fix.