Liveness Probe vs Readiness Probe

Detailed Breakdown

Liveness Probe

A liveness probe tells Kubernetes whether the container is still running properly. If it fails, the kubelet kills the container and the restart policy determines what happens next.

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
    - name: app
      image: my-app:1.0.0
      ports:
        - containerPort: 8080
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
        timeoutSeconds: 3
        failureThreshold: 3
        successThreshold: 1

This configuration:

• Waits 15 seconds after the container starts before the first check
• Checks /healthz every 10 seconds
• Considers the probe failed if no response within 3 seconds
• Restarts the container after 3 consecutive failures

The /healthz endpoint should check for conditions that only a restart can fix:

@app.get("/healthz")
def healthz():
    # Check for deadlock, thread pool exhaustion, etc.
    if thread_pool.is_deadlocked():
        return Response(status_code=500)
    return Response(status_code=200)

Readiness Probe

A readiness probe tells Kubernetes whether the container is ready to receive traffic. If it fails, the Pod's IP is removed from all Service endpoints.

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
    - name: app
      image: my-app:1.0.0
      ports:
        - containerPort: 8080
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 5
        timeoutSeconds: 2
        failureThreshold: 3
        successThreshold: 1

The /ready endpoint should check whether the application can actually handle requests:

@app.get("/ready")
def ready():
    # Check dependencies and initialization
    if not cache.is_loaded():
        return Response(status_code=503)
    if not db.is_connected():
        return Response(status_code=503)
    return Response(status_code=200)

The Critical Difference in Action

Consider a Java application that takes 60 seconds to load its cache:

Without probes: Kubernetes adds the Pod to Service endpoints immediately. Clients hit the Pod before the cache is loaded, getting errors or slow responses.

With readiness probe only: The Pod is not added to Service endpoints until the cache is loaded. Clients are shielded from the startup period.

With liveness probe only (dangerous!): If initialDelaySeconds is too short, the liveness probe fires before the cache loads, considers the app unhealthy, and restarts it — creating a restart loop.

With both probes (correct): The readiness probe holds traffic until the app is ready. The liveness probe monitors for deadlocks during normal operation.

Startup Probe — The Third Probe

For slow-starting applications, a startup probe prevents the liveness probe from killing the container during startup:

spec:
  containers:
    - name: app
      image: my-app:1.0.0
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        periodSeconds: 5
        failureThreshold: 30  # 30 * 5 = 150 seconds to start
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        periodSeconds: 10
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        periodSeconds: 5
        failureThreshold: 3

The startup probe runs first. The liveness and readiness probes are disabled until the startup probe succeeds. This gives the application up to 150 seconds to start (30 checks x 5 seconds) without risk of the liveness probe restarting it.

Probe Types

All three probes support the same check mechanisms:

# HTTP GET — most common for web applications
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
      - name: X-Health-Check
        value: kubernetes

# TCP Socket — for services that don't serve HTTP
livenessProbe:
  tcpSocket:
    port: 5432

# Exec Command — runs a command inside the container
livenessProbe:
  exec:
    command:
      - cat
      - /tmp/healthy

# gRPC — for gRPC services (Kubernetes 1.27+)
livenessProbe:
  grpc:
    port: 50051
    service: my.health.v1.Health

Common Anti-Patterns

Anti-pattern 1: Liveness probe checks external dependencies

# BAD — if the database is down, all Pods restart
# Restarting won't fix the database
livenessProbe:
  httpGet:
    path: /healthz  # This endpoint checks database connectivity
    port: 8080

Liveness probes should only check the container's internal health. If the database is down, restarting the app will not help — use a readiness probe to stop traffic instead.

Anti-pattern 2: Same endpoint for liveness and readiness

# RISKY — if /health checks dependencies, a dependency outage
# causes both probes to fail, restarting all Pods
livenessProbe:
  httpGet:
    path: /health
    port: 8080
readinessProbe:
  httpGet:
    path: /health
    port: 8080

Use separate endpoints: /healthz for liveness (internal health only) and /ready for readiness (includes dependency checks).

Anti-pattern 3: Too aggressive liveness probe

# BAD — restarts after just 2 seconds of unresponsiveness
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 1
  failureThreshold: 2
  timeoutSeconds: 1

A brief GC pause or CPU spike triggers a restart. Set conservative thresholds — a few seconds of unresponsiveness is usually not worth a restart.

Best Practices

1. Always configure readiness probes — they protect against sending traffic to unready Pods during deployments and scaling events
2. Be conservative with liveness probes — false positives cause unnecessary restarts that can cascade into outages
3. Use startup probes for slow starters — Java applications, ML model loading, or large cache warm-up
4. Separate liveness and readiness endpoints — liveness checks internal health, readiness checks dependencies
5. Set appropriate thresholds — failureThreshold: 3 with periodSeconds: 10 gives 30 seconds before action, which is usually appropriate