Mastering Kubernetes Container Probes: Startup, Liveness, and Readiness Explained

Introduction

Container probes are a mechanism where kubelet periodically checks containers to obtain their status. There are three types: Startup Probe, Liveness Probe, and Readiness Probe.

Probe Functions

Startup Probe

StartupProbe detects whether the application inside the container has successfully started and completed initialization tasks. Its main purposes are: Delay other probes: During early startup, the startup probe runs before liveness and readiness probes. kubelet will not execute the latter until the startup probe succeeds, preventing premature restarts or traffic. Prevent frequent restarts: Without a startup probe, liveness or readiness probes might trigger restarts before the app is fully ready, causing unnecessary service interruptions.

Liveness Probe

Liveness Probe checks whether the main process or service inside the container is still running and responding to health checks. Automatic recovery: When the liveness probe fails, kubelet treats the main process as unhealthy and may restart the container according to the pod's restart policy, enabling self‑healing.

Readiness Probe

Readiness Probe determines whether the container is ready to serve traffic. Traffic routing control: When successful, kubelet marks the container as ready and the Service adds its IP to the backend pool. Avoid invalid requests: If it fails, the container is removed from the Service pool, preventing user requests from reaching an unready pod. Smooth transition: Enables rolling updates where new pods receive traffic only after passing the readiness check.

Probe Types

Probes can be implemented using three methods: HTTP GET request: Kubernetes sends an HTTP GET to the container; a 200‑399 response is considered success. TCP Socket check: Kubernetes attempts a TCP connection to the specified port; a successful connection means the probe passes. exec command: Executes a command inside the container; exit code 0 indicates success.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: huawei

livenessProbe:
  tcpSocket:
    port: 8080

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health

All three probe types support the same configuration parameters.

Probe Configuration Parameters

Kubernetes probes share common parameters: initialDelaySeconds: Seconds to wait after container start before probes begin. If a startup probe is defined, liveness and readiness delays are calculated after it succeeds. periodSeconds: Interval between probe executions (default 10 s, min 1 s). timeoutSeconds: Timeout for each probe (default 1 s, min 1 s). successThreshold: Minimum consecutive successes required to consider the probe successful (default 1; must be 1 for liveness and startup). failureThreshold: Number of consecutive failures after which the probe is considered failed, leading to container restart or marking as not ready. terminationGracePeriodSeconds: (K8s 1.25+) Grace period before forcibly terminating a failing container (default inherits pod value, min 1). Not needed for readiness probes.

Configuration Example

livenessProbe:
  # choose httpGet, tcpSocket or exec
  httpGet:
    path: /health
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: huawei
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3
  terminationGracePeriodSeconds: 30

readinessProbe: # similar configuration
startupProbe:   # similar configuration

Configuration Recommendations

If the application has a slow start, configure a startup probe or set a larger initialDelaySeconds for the liveness probe to avoid premature restarts. For applications with unpredictable start times, use a startup probe.

Lower initialDelaySeconds and periodSeconds for the startup probe to detect health faster; increase failureThreshold so the container is not restarted before it is fully started.

Because liveness probe failures trigger container restarts, set its failureThreshold higher than that of the readiness probe so that traffic is cut off before a restart if the app has issues.