kind_served

Function kind_served 

Source
pub async fn kind_served<R>(api: &Api<R>) -> bool
where R: Clone + DeserializeOwned + Debug + Resource,
Expand description

Returns whether the cluster serves a given resource kind.

Gateway API is not installed by default in Kubernetes, and — critically — its route kinds do NOT arrive together. Gateway API ships in two channels: HTTPRoute has been Standard since v1.0, TLSRoute only became Standard in v1.5 and TCPRoute in v1.6. A standard-channel install older than those has HTTPRoute and neither of the others, so probing one kind and inferring the rest re-creates the very error loop this check exists to prevent.

A [Controller] started against a kind whose CRD is absent does not fail loudly: it retries forever, logging an error per attempt for an API that will never appear. Probing once at startup turns that into a single informational line.

§Arguments

  • api - Cluster-wide handle for the kind to probe.

§Returns

true when the kind is served, false only when the API server answers 404. Any other error is reported as true, so a transient problem during startup cannot silently disable watching for the lifetime of the process — loud-but-working is the safer failure here.

The probe runs ONCE, at startup. Installing the CRDs later requires a Scout restart before the corresponding controller begins watching.