Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →A Kubernetes Pod showing Running means Kubernetes has bound it to a node and started at least one of its containers. It does not mean the application inside is healthy, ready to receive traffic, or able to answer requests. Those answers come from two other signals: the Pod’s Ready condition and the probes you configure on each container. Each one triggers a different action, so a Pod can be Running and still receive no traffic, or keep restarting while its phase never changes.
What “Running” actually tells you
The Pod phase is a compact lifecycle field. The Kubernetes Pod Lifecycle documentation (v1.32 version of the docs) defines Running as a state where the Pod is bound to a node, all containers have been created, and at least one primary container is running or is starting or restarting. The same documentation states that the phase is not intended to be a comprehensive rollup of container or Pod state. See Pod Lifecycle (Kubernetes v1.32).
As an Amazon Associate I earn from qualifying purchases.
A Pod can therefore be Running while its web server is deadlocked, its database credentials are rejected, or its readiness check returns errors. The phase carries none of that information. Treat it as “the scheduler placed this Pod and something started,” not as a verdict on the workload.
Ready is the field that controls traffic
The Pod Conditions documentation (v1.36 version of the docs) gives the direct example: a Pod may be in the Running phase but not yet ready to serve traffic. See Pod Conditions (Kubernetes v1.36).
#1 Best Overall
The Ready condition can be false for several distinct reasons, and each one points to a different place to look:
- A container is not ready. With a readiness probe configured, a container stays not ready until the probe succeeds.
- An init container has not finished. Init containers must complete successfully before the Pod can become Ready. See Init Containers.
- The node is not Ready. Pod readiness is also false when the node hosting it is not Ready.
- A readiness gate is false. Custom readiness gates, if defined in the Pod spec, must be true as well.
Three probes, three different decisions
Kubernetes uses three probe types. They ask different questions and produce different responses, so a check meant for one job will misbehave if used for another.
| Probe | Question it answers | What Kubernetes does after repeated failure | Common mistake |
|---|---|---|---|
| Startup | Has the application finished starting? | Holds off liveness and readiness checks until it succeeds. If it keeps failing, the kubelet kills the container and the Pod’s restart policy applies. | Setting a window too short for real initialization, so the container is killed before it could ever start. |
| Readiness | Should this container receive traffic right now? | Pod Ready becomes false and the Pod IP is removed from matching Service EndpointSlices. The container keeps running and the probe keeps running. | Checking only that a port accepts connections, which passes while requests fail. |
| Liveness | Is the application stuck in a state that a restart would fix? | After the configured failureThreshold consecutive failures, the kubelet restarts the container. |
Making the check depend on a downstream service, so an outage elsewhere restarts healthy containers. |
Choosing what each probe should test
The probe result is only as meaningful as what it checks. A temporary dependency outage or an overloaded instance is usually a readiness concern: the instance should stop taking requests but should not be killed, because a restart does not fix the dependency and removes capacity at the worst moment. A deadlock that prevents the process from making progress is a liveness concern, since restarting can recover it. A slow but working initialization path belongs under a startup probe.
Kubernetes’ probe concept documentation warns that a poorly designed liveness check can restart containers under load, reduce serving capacity, increase failures for clients, and put more load on the Pods that remain. Keep liveness checks narrow and local to the process.
Rank #3
Whether a readiness endpoint should test the database, a cache, or only the application’s own state is an implementation decision rather than a Kubernetes requirement. The guidance that follows from the probe model is that the endpoint should reflect whether this instance can do useful work, and that a shallow listener check can pass while the application fails.
Diagnose a Running Pod that is not healthy
Work through these checks in order. Replace the placeholders with your Pod, container, namespace, and Service names.
- Read the READY column first. Run
kubectl get pod <pod-name> -n <namespace> -o wide. A value such as0/1alongside STATUSRunningconfirms the gap between phase and readiness. - Read the conditions directly. Run
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{range .status.conditions[*]}{.type}{"t"}{.status}{"t"}{.reason}{"n"}{end}'and check theReadyrow’s status and reason. - Inspect every container, including init containers. Run
kubectl describe pod <pod-name> -n <namespace>and review the Init Containers and Containers sections. Look at Ready, Restart Count, State, and Last State, including the reason and exit code of the previous termination. - Read the events. The Events section at the bottom of the describe output shows lines such as
Readiness probe failedorLiveness probe failedalong with the response that caused them. - Compare probe settings with real behavior. The describe output lists each probe’s delay, timeout, period, success threshold, and failure threshold. Check these against how long the application really takes to start and recover, not against defaults.
- If the Pod is not Ready, confirm whether it receives traffic. Run
kubectl get endpointslices -n <namespace> -l kubernetes.io/service-name=<service-name> -o wide. If the Pod’s IP is missing from the endpoints, the Service is not routing to it. - If restarts are climbing, read the logs from the last run. Run
kubectl logs <pod-name> -n <namespace> -c <container-name> --previous. The current container may have just started, so the previous instance usually contains the failure. - Test the endpoint the probe uses. Run
kubectl port-forward pod/<pod-name> 8080:<container-port> -n <namespace>and request the probe path locally, bypassing the Service. Compare the response with what the probe expects.
Which branch you are on
- Ready is false, restart count is 0. The readiness probe is the cause. The container is alive and is simply excluded from traffic. Fix the check or the dependency it reflects.
- Ready is false and restarts are increasing. A liveness or startup probe is killing the container. Inspect the previous logs and the probe’s timing before changing anything else.
- Ready is true but requests still fail. The probe is passing without testing the path that users hit. Check the Service’s target port, the application’s error logs, and whether the readiness endpoint covers the failing functionality.
- There is no readiness probe. The kubelet treats the container as ready by default, so Kubernetes is not validating application usefulness at all. Add a readiness probe that reflects what the Service needs.
Probe timing and defaults
The Kubernetes probe documentation describes the timing fields. initialDelaySeconds is the wait before the first check. periodSeconds is the interval between checks. timeoutSeconds is how long each check may take. failureThreshold is the number of consecutive failures required before the action is taken. The documented defaults are 0 seconds for the initial delay, 10 seconds for the period, 1 second for the timeout, and 3 for the failure threshold. Confirm these against the release documentation for your cluster before relying on them. See Configure Liveness, Readiness and Startup Probes.
Free tools Windows power users keep installed
One-click scans. No signup required.
A startup window is simply the failure threshold multiplied by the period. For example, a startup probe with failureThreshold: 30 and periodSeconds: 10 allows about 300 seconds for the application to start before the container is killed. That number is arithmetic from the settings, not a recommendation; choose values from measured startup time with headroom.
Best Value
For the readiness and liveness checks, the same arithmetic applies in reverse. A readiness probe with a 1-second timeout that the application sometimes exceeds under normal load will flip Ready to false during ordinary traffic peaks. Set timeouts from observed response times, not from the minimum that happens to work in a quiet test environment.
Quick Recap
Practical checklist before you trust a Pod
- The
Readycondition is true, not merely the phase. - Every init container and every app container has completed or is ready, with no unexpected restarts.
- A readiness probe exists and tests the path that serves traffic.
- A liveness probe exists only if restarting the container is a real recovery path for a stuck state.
- A startup probe covers any slow initialization so that liveness does not fire during boot.
- The Pod’s IP appears in the matching Service’s EndpointSlices.
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
