kuberhealthy

A cluster can report healthy machines while a user still cannot start an application or reach a service. Kuberhealthy checks those workflows directly by running small, temporary test workloads and collecting their results. For example, a check can try to resolve a network name or create and contact a service. This makes it useful alongside resource monitoring: it asks whether an operation works, rather than only whether the components appear to be running.

Current guidance

Kuberhealthy runs short-lived check pods that report workflow results to the controller, which exposes status through its interfaces and Prometheus metrics. Current upstream documentation uses HealthCheck custom resources. Old examples using a different resource name should be treated as version-specific rather than pasted into a current installation.

Design checks around a concrete user or platform workflow, such as DNS resolution or the ability to create and reach a small service. Keep their privileges and test data narrowly scoped, and make cleanup reliable after both success and failure. A check that cannot remove its resources can gradually exhaust the capacity it is supposed to monitor.

Define timeouts, failure thresholds and an actionable response for each check. Protect any result-reporting endpoint and verify that stale results or a failed checker are distinguishable from a healthy run. An in-cluster checker also needs an external observer if total cluster unavailability must generate an alert. This review identifies current component and API boundaries; it does not establish an end-to-end availability guarantee for a particular check suite.