Kuberhealthy: Synthetische Checks als kurzlebige Pods in Kubernetes
Ein Kubernetes-Operator zum Ausführen synthetischer Prüfungen als Pods. Funktioniert hervorragend mit Prometheus!
Auf einen Blick
- Was ist das?
- Kuberhealthy ist ein Operator, der synthetische Checks als Pods ausführt und Ergebnisse an Prometheus, eine Status-UI und eine JSON-API meldet.
- Für wen ist es gedacht?
- Kuberhealthy verwandelt synthetisches Monitoring in Kubernetes-Manifeste. Checks sind kurzlebige Pods, die an den Controller berichten, und Ergebnisse werden als Prometheus-Metriken und eine JSON-API bereitgestellt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
So funktioniert Kuberhealthy 1
Abschnitt 1, Absatz 1: Kuberhealthy ist ein Kubernetes-Operator für synthetisches Monitoring und kontinuierliche Validierung. Es plant, verfolgt, überwacht und verwaltet Kubernetes-Pods für Checks. Das Repository definiert eine HealthCheck-Custom-Resource; jede HealthCheck weist den Controller an, einen kurzlebigen Checker-Pod nach einem Zeitplan zu starten. Der Pod führt Ihre Validierungslogik aus und meldet an Kuberhealthy zurück. Ergebnisse sind dann über die integrierte Status-UI, eine JSON-API und einen Prometheus-Metriken-Endpunkt verfügbar. Prüfpunkt 1 für kuberhealthy-kuberhealthy-deep-analysis: Die konkrete Ausgabe von dem Startbefehl ist zu dokumentieren.
Checks als Code 2
Abschnitt 2, Absatz 1: Die README beschreibt Checks als Kubernetes-Manifeste, sodass Sie sie zusammen mit Ihrer Anwendung ausliefern können. Ein Check kann einen mehrstufigen Workflow ausführen, z. B. einen Benutzer simulieren, der sich anmeldet, einen Datensatz erstellt, ihn verifiziert und aufräumt. Da jeder Check ein Container ist, können Sie ihn in jeder Sprache schreiben, die in einen Container passt; die README nennt Go, Python, Rust und bash als Beispiele. Dadurch wird die Überwachungslogik Teil Ihrer Deployment-Pipeline und nicht ein separates System. Prüfpunkt 2 für kuberhealthy-kuberhealthy-deep-analysis: Die konkrete Ausgabe von der Konfiguration ist zu dokumentieren.
Kuberhealthy installieren 3
Abschnitt 3, Absatz 1: Laut README erfolgt die Installation durch Anwenden von Helm-, Kustomize- oder ArgoCD-Manifesten. Für Helm lautet der Befehl `helm install kuberhealthy deploy/helm/kuberhealthy -n kuberhealthy --create-namespace`. Für Kustomize: `kubectl apply -k github.com/kuberhealthy/kuberhealthy/deploy/kustomize/base?ref=main`. Für ArgoCD: `kubectl apply -f deploy/argocd/kuberhealthy.yaml`. Nach der Installation können Sie den Dienst mit `kubectl -n kuberhealthy port-forward svc/kuberhealthy 8080:80` portweiterleiten und `http://localhost:8080` öffnen, um die Status-UI zu sehen. Prüfpunkt 3 für kuberhealthy-kuberhealthy-deep-analysis: Die konkrete Ausgabe von dem Startbefehl ist zu dokumentieren.
Die HealthCheck-Custom-Resource 4
Abschnitt 4, Absatz 1: Eine HealthCheck ist das Kernobjekt, das Kuberhealthy verwaltet. Ihr spec enthält ein runInterval, ein timeout und ein podSpec. Das Beispiel in der README verwendet den integrierten Deployment-Check, der ein Test-Deployment erstellt, ausrollt und wieder abbaut. Das Manifest setzt das Image auf `docker.io/kuberhealthy/deployment-check:v0.1.1`, übergibt Umgebungsvariablen wie `CHECK_DEPLOYMENT_REPLICAS` und `CHECK_DEPLOYMENT_ROLLING_UPDATE` und legt Ressourcenanforderungen und -limits fest. Sie können Checks mit `kubectl get healthcheck` oder `kubectl get hc` abfragen. Prüfpunkt 4 für kuberhealthy-kuberhealthy-deep-analysis: Die konkrete Ausgabe von der Konfiguration ist zu dokumentieren.
Check-Status lesen 5
Abschnitt 5, Absatz 1: Kuberhealthy stellt den Check-Status in zwei maschinenlesbaren Formen bereit. Der `/metrics`-Endpunkt ist für Prometheus und enthält Labels wie `check`, `namespace` und `status`. Die README zeigt `kuberhealthy_check{check="api-smoke-test",namespace="kuberhealthy",status="1"} 1` und `kuberhealthy_check_duration_seconds{check="api-smoke-test",namespace="kuberhealthy"} 0.23`. Der `/json`-Endpunkt gibt ein JSON-Objekt mit einem `ok`-Feld und einer `checks`-Map zurück, die `lastRun` und `runDuration` enthält. Die integrierte Status-UI zeigt diese Ergebnisse ebenfalls an. Prüfpunkt 5 für kuberhealthy-kuberhealthy-deep-analysis: Die konkrete Ausgabe von dem Startbefehl ist zu dokumentieren.
Eigene Checks schreiben 6
Abschnitt 6, Absatz 1: Um einen Check zu schreiben, verweist die README auf `docs/CHECK_CREATION.md` und ein HealthCheck-Registry unter `docs/CHECKS_REGISTRY.md`. Sie listet Client-Bibliotheken für Go, Python, TypeScript, JavaScript, Rust, Ruby, Java und Bash auf. Das Go-Beispiel verwendet `github.com/kuberhealthy/kuberhealthy/v3/pkg/checkclient`, um Erfolg oder Misserfolg zu melden. Der Client verarbeitet automatisch die Umgebungsvariablen `KH_REPORTING_URL` und `KH_RUN_UUID` sowie die Durchsetzung von Fristen. Prüfpunkt 6 für kuberhealthy-kuberhealthy-deep-analysis: Die konkrete Ausgabe von der Konfiguration ist zu dokumentieren.
Kuberhealthy und synthetische Clusterprüfungen
Kuberhealthy ist ein Kubernetes-Operator für synthetische Health Checks. Das Projekt führt Prüfroutinen als Kubernetes-Ressourcen aus und stellt deren Ergebnis für Monitoring und Alarmierung bereit. Das ist vor allem dann passend, wenn ein Team nicht nur die Erreichbarkeit eines Control-Plane-Endpunkts, sondern konkrete Abläufe wie DNS, Pods oder externe Abhängigkeiten regelmäßig testen möchte. Die Aussage eines Checks hängt jedoch immer von dessen Definition, Intervall und Berechtigungen ab. Kuberhealthy ersetzt daher weder Metriken der Anwendung noch eine Prüfung der zugrunde liegenden Infrastruktur.
Check-Ressourcen und Observability
Der erste Versuch sollte die im README beschriebenen Beispiel-Checks in einem isolierten Namespace installieren. Danach sind die erzeugten Custom Resources, Pod-Logs und der vom Projekt bereitgestellte Status zu vergleichen. Für die Betriebsentscheidung ist wichtig, ob ein absichtlich fehlschlagender Check zuverlässig als Fehler erscheint und ob das gewählte Monitoring diesen Zustand übernimmt. Ebenso muss geprüft werden, welche ServiceAccounts die Checks verwenden und welche Ziele sie erreichen dürfen. Das README beschreibt den Mechanismus des Projekts, aber keine allgemeine Alarmierungsqualität für jede Prometheus-, Alertmanager- oder Kubernetes-Version.
Redaktionelles Fazit
Kuberhealthy verwandelt synthetisches Monitoring in Kubernetes-Manifeste. Checks sind kurzlebige Pods, die an den Controller berichten, und Ergebnisse werden als Prometheus-Metriken und eine JSON-API bereitgestellt. Das Repository ist unter Apache-2.0 lizenziert, und die README verweist auf ein Check-Registry und einen Leitfaden zum Erstellen eigener Checks.
Community-Notizen