Kubernetes Readiness vs Liveness vs Startup Probes

A Pod can be running while its application is unable to serve requests. That does not automatically mean restarting the container will help. When studying Kubernetes probes, begin with the response you want to a failure, then decide what evidence the health check should collect.

Compare the three decisions

Probe purpose and response to failure
Probe	Question it answers	Response after the configured failure threshold
Startup	Has this container's application finished starting?	The kubelet kills the container; its restart policy applies.
Liveness	Is this a failure for which restarting the container is appropriate?	The kubelet kills the container; its restart policy applies.
Readiness	Should this Pod receive normal traffic through a matching Service?	The container becomes not ready; this failure does not itself restart it.

A configured startup probe holds back liveness and readiness checks until it succeeds. Readiness does not gate liveness in the same way. A failed readiness check is a traffic-management signal, not a universal network block: it does not promise that every direct connection to a Pod is prevented.

Choose by failure, not by the endpoint's name

Consider three invented study cases. In the first, an application needs time to load a model before serving. In the second, its process deadlocks after operating normally. In the third, an essential dependency is temporarily unavailable, but restarting the application would not repair that dependency.

Slow initialization: consider a startup probe with a measured startup allowance.
A deadlock that a restart can recover: consider liveness, with a check that detects that condition.
Temporary inability to serve: consider readiness, and explain what must recover before traffic should return.

These are design judgments for the stated cases, not universal rules about particular applications. Before copying them, ask whether the application can genuinely recover without a restart and whether it can serve useful requests while a dependency is unavailable. Kubernetes warns that poorly designed liveness checks can cause cascading failures under load.

Read a configuration without copying it blindly

This fragment is illustrative, not a complete or executed manifest. It belongs under an individual container. It assumes your application implements the three named HTTP paths on port 8080; Kubernetes does not create those endpoints for you.

startupProbe:
  httpGet:
    path: /started
    port: 8080
  periodSeconds: 5
  failureThreshold: 24
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: /live
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

The startup settings illustrate an allowance on the order of 120 seconds: 24 checks spaced five seconds apart. Treat that as a sizing aid, not a precise deadline for observing a restart. Probe execution and termination behavior also matter. Choose values from measured startup behavior, and check the documentation for the Kubernetes version used by your lab.

For an HTTP probe, a response status from 200 through 399 is successful. A path that returns a successful response while the application is broken is therefore a poor health signal. Conversely, a wrong path or port can make a healthy application fail its check. Diagnose the check itself before increasing every threshold.

Inspect evidence before changing thresholds

Start with Pod details and events, then inspect the affected container's logs. The Kubernetes debugging guide uses these observations to distinguish scheduling, runtime and application problems. For your own authorized lab, substitute the actual namespace, Pod and container names below.

kubectl describe pod POD_NAME -n NAMESPACE
kubectl logs POD_NAME -n NAMESPACE -c CONTAINER_NAME
kubectl logs POD_NAME -n NAMESPACE -c CONTAINER_NAME --previous

The last command asks for logs from the previous instance of that container, if available. Compare the reported probe failure with the configured path, port and timing. Record the restart count and relevant events before making a change. Logs can contain sensitive data, so redact them before posting a question publicly.

Test your reasoning with a counterexample

Write down a case in which your chosen probe would be wrong. For example, if a service can still satisfy useful requests during a dependency outage, withdrawing every instance may be too aggressive. If an application never finishes initialization, extending its startup allowance forever only hides the failure. Explain what evidence distinguishes a temporary delay from a broken process.

Use the probes and Pod lifecycle guide to continue studying the mechanics. The Kubernetes troubleshooting routine helps organize observations, while the CKA study guide places this topic in a wider preparation plan. Written explanations supplement hands-on work; they do not replace it.