Mastering Kubernetes Probes: Startup, Liveness, and Readiness Explained

Why Probes Are Needed

Kubernetes relies heavily on asynchronous mechanisms and decoupled object relationships, so when Pods are added, removed, or updated during a rolling upgrade, the system cannot guarantee that Service and Ingress configurations are refreshed in time. This can cause brief service outages, which is unacceptable in production, so Kubernetes introduces three health probes: StartupProbe , LivenessProbe , and ReadinessProbe .

Pod States

Pending : The Pod is created but no node satisfies its scheduling requirements; this includes network setup or image download.

Running : All containers are created and at least one is running, starting, or restarting.

Succeeded : All containers have completed successfully and are not restarting.

Failed : All containers have exited, but at least one exited with a failure status.

Unknown : The kubelet cannot communicate with the node, so the Pod state is unknown.

Pod Restart Policies

Always : Restart the container whenever it exits.

OnFailure : Restart only if the container exits with a non‑zero status.

Never : Do not restart the container regardless of its exit state.

Probe Overview

ReadinessProbe

LivenessProbe

StartupProbe

Purpose of Probes

Each Pod consists of one or more containers, and a container may crash during runtime. Probes monitor container health and ensure that services remain available. ReadinessProbe determines when a container is ready to receive traffic, while LivenessProbe decides if a container should be restarted. StartupProbe handles cases where the application takes a long time to start, preventing premature failures of the other two probes.

Readiness vs. Liveness

When ReadinessProbe fails, the Pod’s IP:Port is removed from the Service Endpoints list.

When LivenessProbe fails, the container is killed and the Pod is restarted according to its restartPolicy.

Startup vs. Readiness/Liveness

If all three probes are defined, StartupProbe runs first; the other two remain disabled until the startup check succeeds. After that, ReadinessProbe and LivenessProbe operate for the lifetime of the container.

Correct Probe Usage

Both ReadinessProbe and LivenessProbe support three detection methods:

ExecAction : Execute a command inside the container; success is indicated by exit code 0.

HTTPGetAction : Perform an HTTP GET request; a status code between 200 and 399 is considered successful.

TCPSocketAction : Open a TCP connection; a successful connection means the container is healthy.

Probe results can be Success , Failure , or Unknown .

Probe Configuration Fields

initialDelaySeconds : Seconds to wait after container start before probing begins.

periodSeconds : Interval between probes (default 10s).

timeoutSeconds : Time to wait for a probe response (default 1s).

successThreshold : Minimum consecutive successes required (must be 1 for Liveness).

failureThreshold : Number of consecutive failures before the probe is considered failed.

Tip : initialDelaySeconds is often unnecessary for ReadinessProbe because it starts probing immediately after container launch.

Probe Examples

LivenessProbe (exec)

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      initialDelaySeconds: 10
      periodSeconds: 5
      exec:
        command:
        - cat
        - /tmp/healthy

LivenessProbe (HTTP)

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
  labels:
    test: liveness
spec:
  containers:
  - name: liveness
    image: test.com/test-http-prober:v0.0.1
    livenessProbe:
      failureThreshold: 5
      initialDelaySeconds: 20
      periodSeconds: 10
      timeoutSeconds: 5
      successThreshold: 2
      httpGet:
        scheme: HTTP
        port: 8081
        path: /ping

LivenessProbe (TCP)

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: nginx
    livenessProbe:
      initialDelaySeconds: 15
      periodSeconds: 20
      tcpSocket:
        port: 80

ReadinessProbe (exec)

apiVersion: v1
kind: Pod
metadata:
  name: readiness-exec
  labels:
    app: readiness-exec
spec:
  containers:
  - name: readiness-exec
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    readinessProbe:
      initialDelaySeconds: 10
      periodSeconds: 5
      exec:
        command:
        - cat
        - /tmp/healthy

ReadinessProbe (HTTP)

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
  labels:
    app: readiness-http
spec:
  containers:
  - name: readiness-http
    image: test.com/test-http-prober:v0.0.1
    ports:
    - name: server
      containerPort: 8080
    - name: management
      containerPort: 8081
    readinessProbe:
      initialDelaySeconds: 20
      periodSeconds: 5
      timeoutSeconds: 10
      httpGet:
        scheme: HTTP
        port: 8081
        path: /ping

ReadinessProbe (TCP)

apiVersion: v1
kind: Pod
metadata:
  name: readiness-tcp
  labels:
    app: readiness-tcp
spec:
  containers:
  - name: readiness-tcp
    image: nginx
    livenessProbe:
      initialDelaySeconds: 15
      periodSeconds: 20
      tcpSocket:
        port: 80

StartupProbe Example

apiVersion: v1
kind: Pod
metadata:
  name: startup
  labels:
    app: startup
spec:
  containers:
  - name: startup
    image: nginx
    startupProbe:
      failureThreshold: 3
      initialDelaySeconds: 5
      timeoutSeconds: 10
      periodSeconds: 5
      httpGet:
        path: /test
        port: 80

Conclusion

Understanding the underlying mechanisms of Startup, Liveness, and Readiness probes enables you to maximize pod availability, safety, and continuity; there is no single silver bullet, and each business scenario may require a tailored probe configuration.