Kuberhealthy : des checks Kubernetes qui s'écrivent comme des manifests
Un opérateur Kubernetes pour exécuter des vérifications synthétiques en tant que pods. Fonctionne très bien avec Prometheus !
En bref
- De quoi s’agit-il ?
- Kuberhealthy est un opérateur Kubernetes qui exécute des vérifications synthétiques dans des pods éphémères. Cet article détaille son fonctionnement, son installation et ses limites, avec un regard critique sur son approche par CRD.
- À qui s’adresse-t-il ?
- Kuberhealthy s'adresse aux équipes qui veulent transformer leur monitoring en code versionnable, déployé avec les mêmes outils que leurs applications. Si vous avez déjà Prometheus et des alertes simples, l'ajout d'un opérateur peut sembler lourd, mais il apporte une vraie valeur pour les scénarios multi-étapes.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un opérateur pour des checks qui simulent des utilisateurs
Kuberhealthy résout un problème précis : comment valider qu'une application fonctionne réellement, pas seulement que ses pods tournent. Les checks classiques de Prometheus, comme les probes HTTP, ne suffisent pas pour des scénarios complexes. Kuberhealthy permet d'exécuter des vérifications qui se comportent comme un utilisateur : se connecter, créer une ressource, vérifier qu'elle existe, puis nettoyer. C'est ce que le README appelle du monitoring synthétique et de la validation continue. L'outil cible les équipes qui opèrent des clusters Kubernetes et qui veulent écrire ces vérifications dans le même langage que leurs déploiements, c'est-à-dire des manifests. Le projet est écrit en Go et distribué sous licence Apache-2.0, ce qui le rend utilisable dans des contextes commerciaux sans contrainte particulière.
Le mécanisme : un CRD, un contrôleur, des pods éphémères
Le cœur de Kuberhealthy est la ressource personnalisée HealthCheck. Chaque instance de cette CRD décrit un conteneur à exécuter, une fréquence et un délai d'expiration. Le contrôleur, qui tourne dans le cluster, surveille ces ressources. Quand une vérification doit avoir lieu, il planifie un pod de courte durée. Ce pod exécute la logique de validation, puis il envoie un rapport au contrôleur via une requête POST sur l'endpoint /check. Le contrôleur agrège les résultats et les expose de trois manières : une interface web sur le port 80, une API JSON à la racine /json, et un endpoint /metrics au format Prometheus. Ce flux est visible dans le diagramme du README : le contrôleur orchestre le pod, reçoit son rapport, et le service Kuberhealthy rend tout accessible. La conception est simple, mais elle repose entièrement sur la capacité du cluster à créer des pods rapidement.
Installation en trois commandes, puis un check personnalisé
L'installation se fait via Helm, Kustomize ou ArgoCD. La méthode recommandée est Helm, avec cette commande : helm install kuberhealthy deploy/helm/kuberhealthy -n kuberhealthy --create-namespace. Pour voir l'interface, on fait un port-forward : kubectl -n kuberhealthy port-forward svc/kuberhealthy 8080:80. Ensuite, on applique un HealthCheck. L'exemple du README utilise l'image docker.io/kuberhealthy/deployment-check:v0.1.1, qui crée un déploiement de test, le fait rouler, puis le supprime. Le manifest spécifie runInterval: 10m, timeout: 5m, et les variables d'environnement comme CHECK_DEPLOYMENT_REPLICAS. On peut vérifier l'état avec kubectl get healthcheck ou kubectl get hc. Pour écrire ses propres checks, le README renvoie à CHECK_CREATION.md et à des clients par langage. L'exemple Go montre comment appeler checkclient.ReportFailure ou ReportSuccess. Le client gère automatiquement les variables KH_REPORTING_URL et KH_RUN_UUID, ainsi que les délais d'exécution.
Ce que le README ne dit pas : les limites de l'approche
Le README est clair sur le fonctionnement, mais il reste muet sur certains points. Premièrement, chaque check consomme des ressources. Le pod de deployment-check demande 25 millicores de CPU et 15 Mio de mémoire, mais la limite CPU est fixée à 1 cœur. Si vous lancez des dizaines de checks fréquents, l'impact sur le cluster peut devenir non négligeable. Deuxièmement, le port 80 du service est un point unique : si le contrôleur tombe, l'interface et le endpoint /metrics deviennent indisponibles, ce qui affecte la supervision elle-même. Troisièmement, le modèle est asynchrone : un check qui ne parvient pas à signaler son résultat est traité comme un échec après le timeout, mais cela peut masquer des problèmes de réseau entre le pod et le contrôleur. Enfin, le README ne mentionne aucune stratégie de haute disponibilité pour le contrôleur. Pour un outil de monitoring, c'est une lacune à vérifier avant une adoption en production.
Comparaison avec une approche classique : Blackbox Exporter
Une alternative naturelle est Blackbox Exporter, l'outil standard de Prometheus pour les probes HTTP, TCP, ICMP et DNS. La différence d'approche est fondamentale. Blackbox Exporter exécute des sondes depuis un processus unique, configuré par un fichier YAML statique. Il ne crée pas de pods, il ne peut pas exécuter de scripts multi-étapes, et il ne connaît pas l'état du cluster. Kuberhealthy, lui, déploie des pods avec n'importe quelle logique, ce qui permet de vérifier des workflows complets. En contrepartie, Blackbox Exporter est plus léger, plus simple à déployer et suffisant pour des vérifications de disponibilité. Si vos besoins se limitent à vérifier qu'une URL répond, Kuberhealthy est probablement surdimensionné. Si vous devez valider une transaction de bout en bout, Blackbox Exporter ne peut pas le faire, et Kuberhealthy devient pertinent. Ce choix dépend donc de la complexité des scénarios à tester.
Coût de maintenance et implications de licence
Kuberhealthy est sous licence Apache-2.0, ce qui autorise une utilisation commerciale sans obligation de divulguer vos modifications. Le projet est maintenu activement, avec des versions récentes comme v3.0.14 et v3.0.13 publiées en août 2026. Cela indique un rythme de correction régulier, mais cela implique aussi un coût de mise à niveau pour suivre les versions. Le README mentionne des clients dans plusieurs langages, ce qui signifie que si vous écrivez un check en Go, vous devrez suivre les évolutions du package github.com/kuberhealthy/kuberhealthy/v3/pkg/checkclient. La documentation renvoie à des fichiers dédiés comme CHECK_CREATION.md et CHECKS_REGISTRY.md, mais le README ne précise pas la fréquence des changements de l'API CRD. Avant de l'adopter, il faut donc vérifier la compatibilité ascendante entre les versions. Le projet n'est pas archivé, ce qui est un bon signe, mais cela ne garantit pas la pérennité des interfaces.
Conclusion éditoriale
Kuberhealthy s'adresse aux équipes qui veulent transformer leur monitoring en code versionnable, déployé avec les mêmes outils que leurs applications. Si vous avez déjà Prometheus et des alertes simples, l'ajout d'un opérateur peut sembler lourd, mais il apporte une vraie valeur pour les scénarios multi-étapes. Ne l'adoptez pas si vous cherchez un outil de métriques en temps réel ou si vos checks sont déjà couverts par des outils comme Blackbox Exporter. Avant de commencer, vérifiez que votre cluster accepte les CRD v2 et que le port 80 du service kuberhealthy est accessible. Testez d'abord avec un check simple comme deployment-check, puis mesurez la charge sur votre API Kubernetes si vous prévoyez des centaines de checks.
Notes de la communauté