Probes

Kubernetes decides whether a container is healthy and ready by running probes against it. There are three — readiness, liveness, and startup — and each gates something different. Configured well, they make deployments safe and self-healing; configured badly, they turn a healthy app into a restart loop.

Probes are deceptively simple and a frequent source of self-inflicted outages. The key is understanding precisely what each one controls, because the failure modes differ sharply.

Readiness: Gating Traffic

A readiness probe answers "can this Pod serve requests right now?" While it fails, the Pod is removed from its Service's endpoints, so no traffic is sent to it — but the Pod is not restarted. This is what makes rolling updates safe: a new Pod receives traffic only once it reports ready. Readiness is also the right tool for a Pod that is temporarily busy or waiting on a dependency — it sheds traffic without being killed.

spec:
  containers:
    - name: app
      image: my-app:1.0
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        periodSeconds: 5
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        periodSeconds: 10
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        failureThreshold: 30      # allow up to ~5 min to start
        periodSeconds: 10

Liveness: Gating Restarts

A liveness probe answers "is this container still working, or wedged?" When it fails past its threshold, the kubelet restarts the container. This recovers from deadlocks and stuck processes a crash wouldn't catch. The danger: if the liveness probe checks something it shouldn't — a slow dependency, or the same heavy logic as readiness — a transient blip restarts a perfectly healthy container, and under load every replica restarts at once. Liveness should test only that the process itself is alive.

Startup: Protecting Slow Boots

A startup probe exists for apps that take a long time to initialize. While it is running, the liveness and readiness probes are suspended, so a slow boot is not mistaken for a wedged process and killed mid-startup. Once the startup probe succeeds, the other two take over. Without it, you would have to loosen the liveness probe's timing for everyone just to accommodate startup — the startup probe lets you keep liveness tight for the running state.

Probe Types and Tuning

Probes can be HTTP GET, TCP socket, exec (run a command), or gRPC. Each has thresholds: initialDelaySeconds, periodSeconds, failureThreshold, and timeouts. Exec probes are the most expensive — they fork a process each time — so prefer HTTP or gRPC where possible. The cardinal rule is to keep liveness and readiness distinct: readiness can depend on dependencies, liveness must not.