Liveness, Readiness, and Startup Probes

Kubernetes provides probes to monitor the health and availability of containers. These probes help ensure that applications run reliably by detecting failures early and managing container lifecycle events. The three main probes are Liveness, Readiness, and Startup. Each serves a distinct purpose in keeping workloads healthy and responsive.

Liveness Probe

A Liveness Probe checks if a container is still running. If the probe fails, Kubernetes kills the container and restarts it according to its restart policy.

YAML Example: Liveness Probe

apiVersion: v1
kind: Pod
metadata:
  name: liveness-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

Explanation: This probe checks the /healthz endpoint every 10 seconds after an initial 5-second delay.

Readiness Probe

A Readiness Probe checks if a container is ready to serve traffic. If the probe fails, the Pod is removed from the Service’s endpoints, preventing traffic from being sent to it.

YAML Example: Readiness Probe

apiVersion: v1
kind: Pod
metadata:
  name: readiness-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

Explanation: This probe checks if the container is accepting TCP connections on port 8080.

Startup Probe

A Startup Probe is used for applications that take a long time to initialize. It prevents Kubernetes from killing the container during startup by disabling other probes until the startup probe succeeds.

YAML Example: Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    startupProbe:
      httpGet:
        path: /ready
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

Explanation: This probe allows up to 30 failed attempts (5 minutes) before considering the container unhealthy, giving it time to start properly.

Flowchart: Probe Workflow

   Container starts ---> Startup Probe checks initialization
          |
          v
   Container running ---> Liveness Probe ensures health
          |
          v
   Ready for traffic ---> Readiness Probe confirms availability
  

Real-Time Example

In a microservices-based banking application:

• Liveness Probe: Ensures the transaction service is restarted if it hangs.
• Readiness Probe: Prevents routing traffic to the payment service until it connects to the database.
• Startup Probe: Allows the reporting service extra time to load large datasets before being marked healthy.

Common Mistakes

• Using liveness probes for readiness checks, causing unnecessary restarts.
• Not configuring startup probes for slow applications, leading to premature failures.
• Setting probe intervals too aggressively, overwhelming applications.
• Ignoring probe logs when debugging health check failures.

Interview Notes

Q1: Difference between Liveness and Readiness probes?

Answer: Liveness checks if a container is alive, while Readiness checks if it is ready to serve traffic.

Q2: Why do we need Startup probes?

Answer: Startup probes prevent premature failures for applications that take longer to initialize.

Q3: What happens if a readiness probe fails?

Answer: The Pod is removed from the Service’s endpoints until the probe passes again.

Q4: Example Interview Task

apiVersion: v1
kind: Pod
metadata:
  name: probe-task
spec:
  containers:
  - name: demo-container
    image: myapp:latest
    livenessProbe:
      exec:
        command: ["cat", "/tmp/healthy"]
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
    startupProbe:
      tcpSocket:
        port: 8080
      failureThreshold: 20
      periodSeconds: 5

Explanation: This Pod uses all three probes: liveness via file check, readiness via HTTP, and startup via TCP socket.

Advanced Notes

• Probe Types: HTTP, TCP, and Exec probes provide flexibility.
• FailureThreshold: Controls how many failures are tolerated before marking a container unhealthy.
• Integration with Autoscaling: Readiness probes ensure only healthy Pods are considered for scaling.
• Best Practices: Use startup probes for slow apps, readiness probes for dependencies, and liveness probes for health checks.

Summary

Liveness, Readiness, and Startup probes are essential for Kubernetes health management. Liveness ensures containers are restarted when they fail, Readiness ensures only healthy Pods receive traffic, and Startup prevents premature failures during initialization. Proper configuration of these probes improves reliability, scalability, and resilience of applications, making them a key topic for interviews and production deployments.