Recommended Free Tools
A green readiness probe means Kubernetes received the success signal your configured check defines. It does not guarantee that every user request, dependency, ingress route, or load-balancer path is working. During a rolling update, that difference can make a Pod appear ready while users still encounter failures—not because Kubernetes has independently verified and misreported application health, but because the probe may test less than readers expect.
What a readiness probe actually tells Kubernetes
“The kubelet uses readiness probes to know when a container is ready to start accepting traffic,” says the Kubernetes probe documentation. Readiness is a traffic-eligibility signal based on the condition you configured, not a general audit of the application.
As an Amazon Associate I earn from qualifying purchases.
When a readiness probe fails, the Pod’s Ready condition becomes false. The EndpointSlice controller removes the Pod IP from EndpointSlices for matching Services, which ordinarily prevents Service traffic from being directed to that Pod. A successful probe can likewise leave a Pod eligible for traffic even if the check does not exercise a failing user-facing route or dependency.
The distinction between probe types matters:
- HTTP: requests the configured path and port. A small, dedicated health endpoint is generally preferable to one that returns a large payload.
- TCP: attempts to establish a connection to the configured port. The connection originates from the node, not from inside the Pod; the probe’s
hostfield is not a way to resolve a Service name. - Exec: runs a command inside the container and reports whether it succeeds.
These checks answer different questions. A port accepting connections does not prove an application route can serve a request; an endpoint returning success does not prove every downstream operation works. That is a probe-design mismatch, not evidence that Kubernetes tests every request and gets the result wrong.
#1 Best Overall
Why a green Pod can still fail during a rolling update
The probe is narrower than the real request
Suppose an HTTP probe checks /health, and that endpoint returns success while a route used by customers is broken. Or the application responds to the probe but cannot reach a dependency needed for a particular operation. The Pod can pass the configured check while those user requests fail. Whether to include a dependency in readiness depends on whether its failure should make this instance ineligible for traffic; the probe should remain meaningful and bounded.
Readiness and Deployment availability use different clocks
A Pod can become Ready and eligible for Service traffic before it has remained Ready for the Deployment’s configured minReadySeconds. That setting is a Deployment availability-accounting rule: it delays counting a newly created Pod as available until it has stayed Ready for the minimum period. It is not a Service traffic warm-up delay.
During an update, the Deployment gradually scales old and new ReplicaSets. maxUnavailable and maxSurge constrain rollout progress; minReadySeconds affects when a Pod counts as available. These settings should be read together in the context of the rollout, rather than treated as a guarantee that new Pods receive no traffic until they have warmed up.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsTerminating endpoints have separate semantics
When a Pod is deleted, EndpointSlice ready becomes false for ordinary traffic. EndpointSlices also expose serving and terminating conditions so consumers can distinguish whether a terminating endpoint is still serving. How those signals affect traffic draining depends on the cluster’s networking stack and its endpoint consumers; do not assume every ingress controller or cloud load balancer handles them identically. See the versioned Kubernetes EndpointSlices documentation.
Rank #3
Graceful shutdown must account for this transition: the application may need time to stop accepting new work and finish in-flight requests, while the networking components propagate endpoint changes. A probe’s green result alone does not establish that every component has completed that handoff.
How to diagnose a rollout where the probe passes but requests fail
- Inspect the probe handler and its exact target. Check the configured handler, path or command, port, and timeout. Determine whether it checks only a listening port, a process response, or a bounded application condition relevant to serving traffic.
- Test the failing user path independently. Reproduce the request through the route users take, and test the dependencies required for that operation. Compare those results with the probe’s much narrower check.
- Check whether initialization needs a startup probe. Kubernetes delays liveness and readiness probes until the startup probe succeeds. This can protect a slow-starting service from steady-state checks running too early.
- Review probe timing as a group. The current Kubernetes documentation lists defaults of 10 seconds for
periodSeconds, 1 second fortimeoutSeconds, 3 failures forfailureThreshold, and 1 success forsuccessThreshold. Minimum values are generally 1. Readiness probes may run more often thanperiodSecondswhile a container is not Ready, so these defaults do not define an exact traffic cutover or endpoint-propagation time. - Compare Pod, endpoint, and rollout state. Inspect Pod conditions and container states, then the matching Service’s EndpointSlices and their
ready,serving, andterminatingconditions. Compare those observations with Deployment rollout status and available replicas. - Review rollout constraints and termination behavior. Check
maxUnavailable,maxSurge, andminReadySecondsalongside the number of old and new replicas. Terminating Pods can temporarily keep resource use above the nominal replica-plus-surge count until their grace period expires. - Keep liveness focused on recovery from a stuck process. A failed readiness check does not restart the container: the kubelet keeps it running and continues probing. Startup or liveness failures can trigger a restart after the relevant failure threshold. Kubernetes warns that poorly designed liveness checks can cause cascading failures under load, so avoid making liveness depend on every downstream service.
Choosing a check that matches the decision
There is no universal probe configuration. Choose based on what the signal is meant to decide:
| Approach | What it establishes | Trade-off |
|---|---|---|
| Lightweight process or port check | The process is present or the port accepts a connection. | Fast and narrow; it can pass even when an application route or required dependency is unavailable. |
| Bounded application-readiness check | A meaningful application condition for accepting traffic is satisfied. | Better aligned with the readiness decision, but it must be bounded and designed so transient downstream trouble does not produce unnecessary or cascading disruption. |
Use readiness to control traffic eligibility, liveness to detect a container that should be restarted, and startup probes to cover slow initialization. Then treat Deployment availability and endpoint draining as related but distinct rollout concerns.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteKubernetes documentation is versioned and some pages are rolling documentation. Match the probe configuration guidance, Deployment behavior, and EndpointSlice semantics to the Kubernetes version running in your cluster.
Quick Recap
Best Value
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.
