Mastering Kubernetes Liveness, Readiness, and Startup Probes: A Hands‑On Guide

How to Configure Pod Liveness, Readiness, and Startup Probes

When using Kubernetes, pods may repeatedly crash and restart; probes let the kubelet detect whether a container is alive, ready to receive traffic, or has finished starting. This guide walks through configuring each type of probe.

Define liveness command

The following

exec

liveness probe creates a temporary file, checks its existence, and forces a restart when the file disappears.

<code>apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    args:
    - /bin/sh
    - -c
    - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
    image: gcr.io/google_containers/busybox
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
</code>

During the first 30 seconds the file exists, so the probe succeeds; after that it fails, causing the kubelet to restart the container.

Define a liveness HTTP request

An HTTP GET probe can be used to check a health endpoint. The example below runs a container that returns

200

for the first 10 seconds and then returns

500

, triggering a restart.

<code>http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error:%v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})
</code>

After creating the pod with

kubectl create -f http-liveness.yaml

, the liveness probe fails after 10 seconds and the container is restarted.

Define TCP liveness probe

A TCP socket probe attempts to open a connection to a specified port. The following pod uses both readiness and liveness TCP probes on port 8080.

<code>apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: gcr.io/google_containers/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
</code>

The readiness probe marks the pod as ready after the first successful connection, while the liveness probe restarts the container if the TCP check fails.

Define readiness probe

Readiness probes work like liveness probes but only affect service routing. An

exec

readiness probe can reuse the same command as the liveness probe:

<code>readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5
</code>

Both probes can run in parallel to ensure traffic is sent only to containers that are ready.

Define startup probe

Introduced in Kubernetes 1.16, a startup probe delays other probes until the container has finished initializing. Example:

<code>startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10
</code>

This gives the container up to five minutes (30 × 10 s) to become healthy before liveness or readiness probes are evaluated.

Configure Probe Parameters

initialDelaySeconds – wait time before the first probe.

periodSeconds – frequency of probe execution (default 10 s, min 1 s).

timeoutSeconds – probe timeout (default 1 s).

successThreshold – consecutive successes required (liveness must be 1).

failureThreshold – consecutive failures required (default 3).

HTTP probes also support

host

,

scheme

,

path

,

httpHeaders

, and

port

settings.

What We Should Do

Define a readiness probe for HTTP services to control when a pod receives traffic.

Use a startup probe for slow‑starting applications to prevent premature liveness failures.

For multi‑port services, ensure readiness probes cover all relevant ports.

Use

httpGet

with a health endpoint (e.g.,

/health

) for readiness checks.

What We Should Not Do

Avoid probing external dependencies (databases, caches) as it can cause cascading failures.

Only add liveness probes when you understand their purpose; unnecessary probes can increase downtime.

Do not use identical specifications for liveness and readiness probes; they should have different thresholds.

Prefer non‑exec probes when possible, as exec probes may leave zombie processes.

Summary

Use readiness probes to decide when a web pod should receive traffic.

Misusing readiness/liveness probes can reduce availability and cause cascade failures.

Apply startup probes for applications with long initialization times.

References:

https://jimmysong.io/kubernetes-handbook/guide/configure-liveness-readiness-probes.html

https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html#id6