Adopters & Use Cases
Relevant source files
The following files were used as context for generating this wiki page:
Kuberhealthy is a Kubernetes operator designed for synthetic monitoring and continuous process verification. It allows users to verify that applications and clusters are functioning correctly by running real-world workflows and observing the results rather than just monitoring internal component states.
Sources: README.md:3-6, deploy/helm/kuberhealthy/README.md:10-12
Core Use Cases
Kuberhealthy addresses the gap between a "green" cluster status and actual operational readiness. It focuses on identifying complex failure modes that standard health probes might miss.
Continuous Process Verification
Kuberhealthy replicates real user workflows to ensure that the core functionality of a cluster—such as provisioning pods, resolving DNS, or pulling images—remains operational over time.
- Daemonset Deployment: Verifies that a daemonset can be created, fully provisioned on all nodes, and successfully torn down. This tests the kubelet functionality of every node in the cluster.
- Service Provisioning: Ensures that services can be created and are reachable.
- Storage Verification: Confirms that pods can be configured with persistent storage across various nodes.
Sources: README.md:144-149, deploy/helm/kuberhealthy/README.md:10-13
Synthetic Application Monitoring
Users can write custom checks in any language to verify their own APIs and applications. This allows for testing business logic and external dependencies in a production environment.
- SSL Handshake: Checks the validity of SSL certificates and warns before they expire.
- API Connectivity: Verifies that application endpoints are responsive and returning expected data.
- Image Pull Reliability: Periodically checks that images can be retrieved from specific registries.
Sources: README.md:139-143, README.md:155-157
Monitoring Flow Architecture
The diagram below illustrates how Kuberhealthy orchestrates a synthetic check (e.g., a Daemonset check) to verify cluster health.
This process ensures that the underlying infrastructure is capable of performing standard operations.
Sources: README.md:118-128
Detected Production Issues
Kuberhealthy is designed to catch specific "silent" failures in Kubernetes environments.
| Issue Category | Description |
|---|---|
| Node Stuck states | Pods stuck in Terminating (CNI failure) or ContainerCreating (Disk errors). |
| Component Instability | Kubelet or Docker daemon crashes/restarts that don't trigger global alerts. |
| Network Latency | Nodes unable to provision pods quickly enough due to high IO wait. |
| System Pod Issues | Pods in kube-system restarting too frequently. |
| Resource Access | Intermittent failures accessing or creating Custom Resource Definitions (CRDs). |
Sources: deploy/helm/kuberhealthy/README.md:15-28
Adopters
The following organizations implement Kuberhealthy in production environments to maintain cluster reliability:
| Company | Industry |
|---|---|
| Adobe | Software |
| Comcast Technology Solutions | Media and Technology |
| Jenkins X | Software (CI/CD) |
| Meltwater | Media Intelligence |
| Mercedes Benz | Automotive |
| Polarpoint | Consulting |
Sources: ADOPTERS.md:5-12
Implementation Structures
Kuberhealthy uses Custom Resource Definitions (CRDs) to define checks. The KuberhealthyCheck (khcheck) structure allows for detailed pod specifications to run the synthetic tests.
Check Configuration Schema
Checks are defined with standard Kubernetes podSpec fields, allowing the checker pods to inherit necessary permissions, environment variables, and resource constraints.
# Example structural fields from the KHCheck CRD
properties:
spec:
properties:
runInterval:
type: string # Frequency of the check (e.g. 15m)
timeout:
type: string # Max time for the check to complete
podSpec:
description: Standard Kubernetes Pod description
required:
- containers
Sources: deploy/helm/kuberhealthy/crds/comcast.github.io_khchecks.yaml:55-75, deploy/helm/kuberhealthy/crds/comcast.github.io_khchecks.yaml:1537-1544
Summary
Kuberhealthy serves as a vital tool for SREs and cluster administrators by providing a "user-perspective" of Kubernetes health. By running actual workloads and reporting results via Prometheus and JSON status pages, it bridges the gap between individual component health and overall system availability. Adopters across various industries utilize it to proactively identify infrastructure decay and ensure continuous service reliability.