Un cluster sans supervision est un cluster dont on apprend les problèmes par les utilisateurs. Le trio Prometheus, Grafana et Helm constitue la réponse standard : le premier collecte, le deuxième affiche, le troisième installe l'ensemble sans y passer la journée.
Helm : le paquet, pas la magie
Helm est le gestionnaire de paquets de Kubernetes. Un chart est un ensemble de manifestes paramétrables ; un fichier de values fournit les paramètres ; l'installation produit une release, que l'on peut mettre à jour ou désinstaller d'un bloc.
L'intérêt est simple à mesurer : installer une pile de supervision complète à la main représente plusieurs milliers de lignes de YAML — déploiements, services, règles d'accès, définitions de ressources personnalisées, tableaux de bord. Avec Helm, c'est un chart et une trentaine de lignes de valeurs.
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install kube-prom prometheus-community/kube-prometheus-stack \ -n observability -f values.yaml
Deux conseils d'usage : versionner son fichier de valeurs — c'est lui, et non les objets déployés, qui décrit votre installation ; et épingler la version du chart, pour qu'une mise à jour reste une décision et non une surprise.
Prometheus : collecter des métriques
Prometheus est une base de données de séries temporelles doublée d'un collecteur. Son modèle est celui du scraping : ce n'est pas l'application qui envoie ses mesures, c'est Prometheus qui vient les lire, à intervalle régulier, sur un point d'entrée HTTP exposé par chaque composant.
Ce choix a une conséquence pratique : ajouter une source de métriques ne demande aucune configuration côté application — il suffit qu'elle expose ses mesures et qu'un objet de découverte la désigne.
Le chart kube-prometheus-stack installe d'un coup :
- Prometheus et son opérateur ;
- node-exporter sur chaque nœud — processeur, mémoire, disques, réseau de la machine ;
- kube-state-metrics — l'état de tous les objets Kubernetes : pods redémarrés, déploiements incomplets, volumes en attente ;
- et les règles d'alerte associées.
Les requêtes s'écrivent en PromQL. Deux exemples suffisent à comprendre la logique : rate(container_cpu_usage_seconds_total[5m]) donne la consommation processeur moyenne sur cinq minutes, kube_pod_container_status_restarts_total compte les redémarrages — la métrique qui révèle une application en boucle avant que quiconque ne s'en plaigne.
Grafana : rendre les données lisibles
Consommation par nœud et par espace de noms : de quoi dimensionner les applications au lieu de les deviner.
Grafana interroge Prometheus et présente les résultats. Le chart installe déjà des tableaux de bord couvrant l'essentiel : ressources par nœud, par espace de noms et par pod, santé du plan de contrôle, état des volumes. Dans la plupart des cas, il n'y a rien à construire — juste à regarder.
Au-delà de la supervision d'incident, ces tableaux servent surtout à dimensionner : voir la consommation réelle d'une application permet de fixer ses demandes de ressources autrement qu'au jugé.
Deux décisions de configuration qui comptent
- Persister sur un stockage répliqué. Sans volume persistant, la perte d'un pod efface l'historique des métriques et les tableaux de bord personnalisés. Une supervision amnésique ne sert à rien — c'est précisément quand on cherche à comprendre un incident qu'on a besoin d'hier.
- N'exposer que Grafana. Prometheus reste en accès interne : sa base de métriques n'a aucune raison d'être joignable, et son interface n'offre aucune authentification. Grafana, elle, en a une — et doit être exposée par un Ingress, avec un mot de passe administrateur changé dès l'installation.
Un troisième réglage mérite attention : la rétention. Sept jours suffisent à diagnostiquer un incident ; conserver six mois de métriques à la seconde ne fait que remplir des disques. Pour du long terme, on agrège ou on exporte vers un stockage prévu pour cela.
Alertes : la suite logique
Le chart embarque Alertmanager, désactivé dans le lab. En production, c'est lui qui transforme la supervision en dispositif utile : notification par courriel, messagerie ou astreinte lorsqu'une règle se déclenche. La règle d'or, là aussi : peu d'alertes, mais toutes actionnables. Une alerte qu'on apprend à ignorer est pire que pas d'alerte du tout.
Voir la mise en pratique
Cette brique est installée et configurée pas à pas dans mon wiki, section Datacenter / Cluster K3S — la documentation de référence, avec les commandes et leurs sorties :
- 10. Installation de la stack de supervision Prometheus / Grafana
- 9. Commandes d'exploitation et d'administration
Et côté blog, l'étape correspondante du lab : Monter un lab Kubernetes chez soi (7) : déployer une application et superviser.
Les autres briques du lab
- Kubernetes et K3S
- etcd, la mémoire du cluster
- L'Ingress
- Traefik
- MetalLB
- Longhorn
- Prometheus, Grafana et Helm — vous y êtes