Check missing custom readiness conditions before changing probes

Bottom line: Include the custom condition controller in a readiness investigation. Keep the condition’s publication and meaning visible before changing a container probe to explain an unready Pod.

Source fact: documented behavior

The Pod Conditions documentation is the primary reference.

A readiness gate names an extra Pod condition; if that condition is absent from Pod status, Kubernetes treats its value as False. A Pod using custom gates is ready only when its containers are ready and every named gate condition is True. If containers are ready but a custom gate is missing or false, Kubernetes reports Pod readiness as false with reason ReadinessGatesNotReady.

What the source does not establish

This article concerns the custom-condition handoff, not a universal probe configuration or an instruction to mark a workload ready manually. It supplies no controller implementation, application-health guarantee or approved delay threshold. Keep Pod phase, sandbox readiness and service acceptance as separate observations in the investigation.

Applicability questions

• Which exact condition name appears in the Pod’s readiness gates?
• What controller is responsible for publishing it?
• What event justifies a true value and what should reverse it?
• How should operators respond when the condition is never published?

DSE recommendation: make the condition handoff an owned contract

DSE recommends documenting each custom gate as an explicit contract between the workload owner and its condition controller. Name the condition, its responsible component and the evidence required before declaring it true. Include a response for an absent condition instead of treating absence as an undocumented transitional state.

During triage, capture the Pod’s declared gates, container readiness and actual condition entries together. Compare the exact names before adjusting probe timing. Ask the controller owner to explain an absent or stale entry through the approved diagnostics. Keep a legitimate application failure distinct from failure of the readiness-signaling workflow.

Define who can change the gate declaration and who can update the condition. Review removal of a gate as a behavior change requiring workload-owner approval. Do not delete the condition requirement or force a true value merely to turn a dashboard green.

Write a short handoff checklist for rollout and controller maintenance. Include the expected initial state, publication event, failure handling and restoration evidence. Keep useful application acceptance separate so an administrative condition update cannot stand in for the workload’s actual service requirement.

Verification and evidence

Proposed verification: use a disposable workload with one clearly named custom gate. Prepare three approved cases: no matching condition, a matching false condition and a matching true condition. Keep the container-health fixture unchanged across the cases so the custom-condition difference is visible.

Record the declared name, container readiness, condition value and resulting Pod readiness for each case. Add a separate controller interruption exercise if its owner approves one, without forcing production status. Retain actual status observations and controller events. Review a naming mismatch as its own failure case and require an explicit recovery decision before accepting the readiness handoff.

Official references

• Pod Conditions — Kubernetes.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.