---

🩺 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:

Probe Type	Purpose
Liveness	Checks if the container is still running and should be restarted
Readiness	Checks if the app is ready to serve traffic
Startup (Optional)	Checks if the app has finished starting (used with slow boot apps)

---

🧬 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

Type	How it works
httpGet	Sends HTTP GET to a path
tcpSocket	Checks if TCP port is open
exec	Runs a shell command (e.g., curl, ps aux)

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

Scenario	Use
App might hang or deadlock	Liveness Probe
App takes time to initialize	Readiness + Startup Probe
App temporarily loses DB connection	Readiness Probe only
App returns 200 OK but has internal issues	Use deep readiness checks
Stateless microservice	Liveness + Readiness (default combo)

---

🚀 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.

---