docs: document that endpoint discovery honours custom pod readinessGates

[almogtavor]

What type of PR is this?

/kind documentation

What this PR does / why we need it:

The issue asks whether the router honours custom pod readinessGates, and notes
"the router may already support this; I just couldn't find any documentation."

It does, and it already behaves exactly as requested. Every readiness decision in
the EPP goes through podutil.IsPodReady (pkg/epp/util/pod/pod.go), which reads
the pod's aggregate Ready condition. The kubelet computes Ready as
ContainersReady AND every condition listed in spec.readinessGates, so an
unsatisfied gate holds the pod out of the routing pool with no EPP configuration
required, fail-closed. The same is true of the other two readiness call sites
(pkg/epp/datastore/datastore.go, the topology extractor).

So the gap was purely that this was never written down. This PR:

1. Documents the contract in docs/discovery.md, including the detail that a
   gated pod still shows 1/1 in kubectl get pods (that column counts ready
   containers, not the Ready condition) -- which is the thing that makes this
   confusing to verify by hand.
2. Adds IsPodReady cases for a satisfied and an unsatisfied readiness gate, so
   the behaviour is pinned rather than incidental.

The unsatisfied-gate case has teeth: switching IsPodReady from corev1.PodReady
to corev1.ContainersReady fails it.

$ go test ./pkg/epp/util/pod/...      # with that regression introduced
--- FAIL: TestIsPodReady/Pod_with_an_unsatisfied_readiness_gate
FAIL

Verification (OpenShift 4.21 / k8s v1.32, live EPP against an InferencePool):

Two pods labelled for the pool, one with readinessGates: [custom.orchestrator.io/serving]:

$ oc get pod vllm-gated -o jsonpath='...'      $ oc get pod vllm-ungated -o jsonpath='...'
Ready=False                                     Ready=True
ContainersReady=True                            ContainersReady=True

The EPP admitted only the ungated pod:

{"msg":"Pod added","name":"vllm-ungated"}

Patching the gate condition to True flipped Ready=True, and the EPP picked the
pod up on the next reconcile:

{"msg":"Pod added","name":"vllm-gated"}

This also covers the use cases in the issue -- checkpoint restorers, out-of-band
warm-up agents, dynamic weight loaders -- and the llm-d/llm-d#2365
Snapshot Orchestrator integration it references.

If maintainers would rather also see this asserted end-to-end against a live pool,
I'm happy to add an integration test; I kept the PR to docs plus a unit-level pin
since the behaviour itself needs no change.

Which issue(s) this PR fixes:

Fixes #2541

Release note:

NONE

[Copilot]

Pull request overview

Documents how the EPP’s Kubernetes pod discovery determines readiness (by reading the pod’s PodReady condition) and adds unit tests that pin readiness-gate behavior via that contract.

Changes:

• Document that Kubernetes discovery admits pods only when the aggregate Ready (PodReady) condition is True, which implicitly honors spec.readinessGates.
• Add IsPodReady unit tests covering both satisfied and unsatisfied readiness-gate scenarios.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
pkg/epp/util/pod/pod_test.go	Adds unit test cases that ensure readiness-gated pods are excluded unless PodReady is True.
docs/discovery.md	Adds a Kubernetes discovery readiness section explaining how PodReady (and thus readiness gates) controls routing eligibility.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[omerap12]

overall lgtm
PTAL @vMaroon

[omerap12]

nit: not sure if those comments are needed.

[omerap12]

nit: not sure if those comments are needed.