🩺 Understanding Liveness and Readiness Probes in Kubernetes — Complete Guide

In Kubernetes, your applications don’t just run. They’re continuously watched, checked, and healed by the system itself.

This self-monitoring capability is powered by Liveness and Readiness Probes — vital for keeping containers healthy and available.

Think of them like a nurse and a receptionist at a clinic:

• One checks if you’re alive (Liveness)
• The other decides if you’re ready to see patients (Readiness)

Let’s break it down from the ground up — with examples and real-world use cases.

🚦 What Are Probes in Kubernetes?

A probe is a Kubernetes mechanism to check the health or status of a container. Kubernetes uses these checks to decide whether to:

• Restart a container
• Wait before routing traffic
• Keep a pod in service

K8s uses three types of probes:

🧬 Liveness Probe – “Is the container alive?”

Purpose:

If the liveness probe fails, Kubernetes will restart the container. This helps recover from crashes or deadlocks where the container looks fine (running), but is internally frozen.

Real-World Analogy:

A nurse walks into the room and checks if the patient has a pulse. If not — call emergency services (restart the pod).

Example (YAML):

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3

Configuration Explained:

• httpGet: Hits the /healthz endpoint
• initialDelaySeconds: Wait 10s before starting checks
• periodSeconds: Check every 5s
• failureThreshold: 3 consecutive failures trigger a restart

🟢 Readiness Probe – “Is the container ready to receive traffic?”

Purpose:

If the readiness probe fails, Kubernetes removes the pod from the service endpoint list — without restarting it.

This helps during:

• App initialization
• Temporary downtime (e.g., DB not ready)

Real-World Analogy:

The receptionist checks if the doctor is ready to see patients. If not, they hold the queue — not call the ambulance.

Example (YAML):

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

🔧 Probe Types

Example – exec:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 10

🧠 Advanced Use Cases & Best Practices

1. Separate Liveness and Readiness

Don’t use the same endpoint for both. Why?

• Liveness failure causes a restart
• Readiness failure just removes from load balancer

👉 Example:

• /healthz → deep checks (DB connection, cache)
• /ready → shallow checks (service responsive?)

2. Avoid Premature Restarts

Use appropriate initial delay and failure thresholds, especially for:

• Slow boot apps
• Apps with warm-up routines

Bad config = too many restarts = crashing apps

3. Use Startup Probes for Monoliths

For apps that take a long time to start, use startupProbe to delay liveness checks until fully started.

startupProbe:
  httpGet:
    path: /start
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

4. Don’t Abuse Exec Probes

Running shell commands inside containers:

• Consumes CPU
• Can fail if shell tools are missing
• Use httpGet for web apps, tcpSocket for basic checks

5. Testing Your Probes

Simulate failures with:

• Kill the health endpoint temporarily
• Monitor restarts via kubectl describe pod and logs
• Use kubectl get endpoints to verify readiness

🔍 Monitoring & Observability

Track probe failures via:

• kubectl describe pod
• Events in logging tools
• Prometheus metrics via exporters (e.g., kube-state-metrics)

🏁 Final Summary: Choosing the Right Probe

🚀 Final Thoughts

Probes are one of the most powerful — yet often misunderstood — features in Kubernetes.

Used correctly, they:

• Save your pods from unnecessary restarts
• Protect your users from broken apps
• Boost uptime and resilience

In the world of Kubernetes, probes are the heartbeat of healthy apps.

Mohammad Gufran Jahangir