Kubernetes Readiness and Liveness Probes Explained

Why Probes Matter

In Kubernetes, a container can be running but not yet ready to serve traffic, or it can become unhealthy after startup. Without a mechanism to detect these states, the platform would route requests to pods that cannot respond, or keep pods in service long after they have failed. Readiness and liveness probes solve these two distinct problems by giving the kubelet a way to interrogate a container’s actual operational status.

Prerequisites

• A running Kubernetes cluster with kubectl configured to access it.
• A container image that exposes an HTTP endpoint or responds to TCP connections on a known port.
• Basic familiarity with Kubernetes manifests such as Deployments and Pods.

Readiness Probe

A readiness probe determines whether a container is ready to receive traffic. When the probe fails, Kubernetes removes the pod from all Services that target it. The pod stays alive, but no new connections reach it. This is useful during startup, when an application may need seconds to load data into memory or warm a cache before accepting requests.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: demo-app
        image: demo-app:v1
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Liveness Probe

A liveness probe determines whether a container is still running. When it fails repeatedly up to a configured threshold, Kubernetes restarts the container. This recovers from situations such as a deadlocked worker thread or a corrupted runtime configuration file. Liveness probes should not depend on startup time; their purpose is to confirm ongoing health after the container has already started.

        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3

How They Differ

The core distinction is intent. Readiness controls traffic routing; liveness controls container lifecycle. A failing readiness probe means traffic should stop, not that the container needs restarting. A failing liveness probe means the process itself is broken and a restart is warranted. Using both together on the same pod covers both scenarios without overlap.

Probe Types

Kubernetes supports three probe handlers. httpGet sends an HTTP request to a specified path and port and expects a success status code between 200 and 399. tcpSocket attempts a TCP connection and succeeds if the port is open. exec runs a command inside the container and succeeds if it exits with code zero. Each type fits different workloads; choose the one that most accurately reflects whether your application can actually serve requests.

How to Verify Behavior

Apply your manifest with kubectl apply -f deployment.yaml, then observe the pod status using kubectl get pods. To inspect probe results in detail, run kubectl describe pod demo-app. In the output, look for the Readiness and Liveness sections, which show whether each probe succeeded or failed and when. You can also check Service endpoint availability with kubectl get endpoints demo-service to confirm that pods with failing readiness probes are removed from the endpoint list.

Common Mistakes

• Using identical probes for both readiness and liveness. If the same endpoint and timing apply to both, a slow startup could trigger an unnecessary restart via the liveness probe.
• Setting initialDelaySeconds too low. If the application takes longer to initialize than the probe wait period, the probe will fail before the container is ready, causing a crash loop.
• Pointing probes at the wrong port or path. A mismatched containerPort or path means the probe always fails regardless of application health.
• Relying on liveness probes for dependency checks. A database connection failure should typically trigger a readiness failure, not a restart, because restarting will not fix an external outage.

Cleanup

After testing, remove the demo deployment to avoid unnecessary resource consumption: kubectl delete deployment demo-app. Verify deletion with kubectl get pods and confirm the workload no longer appears. If you created a Service alongside it, delete that as well with kubectl delete service demo-service.

Summary

Readiness and liveness probes are complementary mechanisms that let Kubernetes make intelligent decisions about traffic routing and container restarts. Configuring them correctly requires understanding what each probe measures and choosing appropriate timing and thresholds. Start with conservative delays and thresholds, monitor probe results with kubectl describe pod, and adjust based on observed startup and failure behavior of your application.