Superviser Kubernetes : santé des nœuds, pods en CrashLoopBackOff, pression disque et mémoire, requests et limits, état du plan de contrôle. Ce que la supervision système ne couvre pas.
Kubernetes change la nature de la supervision. Un pod qui plante redémarre automatiquement ; un nœud qui tombe voit ses charges de travail replanifiées ailleurs. Beaucoup d'incidents qui provoqueraient une panne sur une architecture classique sont absorbés par l'orchestrateur.
Cela ne supprime pas le besoin de supervision : cela le déplace. Un pod qui redémarre vingt fois par heure « fonctionne » du point de vue de l'orchestrateur, alors que le service est dégradé en permanence.
| Niveau | Ce qu'on mesure | Outil typique |
|---|---|---|
| Nœuds | Disque, mémoire, charge, kubelet | Supervision système classique |
| Cluster | Pods, déploiements, plan de contrôle | Prometheus, kube-state-metrics |
| Application | Latence, erreurs, files d'attente | Instrumentation applicative |
Les autres services
Superviser un hôte Docker et ses conteneurs : espace disque et images orphelines, redémarrages en boucle, limites mémoire et OOM, sondes de santé et métriques par conteneur.
Ce que la supervision d'un serveur Linux détecte avant l'incident : saturation disque, fuite mémoire, processus zombie, échec de sauvegarde, certificat expiré. Avec les commandes de diagnostic.
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Une confusion fréquente consiste à croire que Kubernetes rend inutile la supervision système. C'est l'inverse : les nœuds restent des serveurs Linux, avec les mêmes modes de défaillance.
Kubernetes expose l'état de chaque nœud sous forme de conditions. Trois méritent une alerte :
kubectl get nodes
kubectl describe node <nom> | grep -A 10 ConditionsCes conditions sont des conséquences. Un agent installé sur le nœud détecte la cause — le remplissage du disque — plusieurs heures avant que Kubernetes ne signale DiskPressure et ne commence à évincer des pods.
C'est l'argument principal en faveur d'une supervision système des nœuds, en complément des outils Kubernetes : elle prévient au lieu de constater.
Même incident que sur un hôte Docker, avec les mêmes causes : images accumulées, journaux de conteneurs, volumes éphémères. Le kubelet effectue un nettoyage automatique quand la pression devient forte, mais ce nettoyage est déjà une situation dégradée — il supprime des images qu'il faudra retélécharger.
Deux services système dont l'arrêt rend le nœud inutilisable. Ils se surveillent comme n'importe quel service systemd.
systemctl is-active kubelet
systemctl is-active containerdL'état CrashLoopBackOff signale un conteneur qui plante immédiatement après son démarrage, en boucle. Kubernetes espace progressivement les tentatives, ce qui masque le problème : le pod n'est pas signalé comme en erreur, il est « en attente de redémarrage ».
kubectl get pods --all-namespaces --field-selector=status.phase!=Running
kubectl get pods --all-namespaces --sort-by='.status.containerStatuses[0].restartCount'Le nombre de redémarrages est la métrique clé. Un pod avec 340 redémarrages est en échec permanent, même s'il apparaît Running à l'instant où vous regardez.
Autres états à surveiller : ImagePullBackOff (image introuvable ou droits manquants) et Pending prolongé (aucun nœud ne peut accueillir le pod, souvent faute de ressources).
C'est la source d'incidents la plus spécifique à Kubernetes, et la moins intuitive.
Ce dernier cas est particulièrement pénible à diagnostiquer : l'application est lente, aucun composant n'est en erreur, et les tableaux de bord système du nœud sont au vert.
Surveillez le rapport entre consommation réelle et limites définies, ainsi que le nombre d'évictions.
Sur un cluster auto-géré, la santé du serveur d'API, du planificateur, du gestionnaire de contrôleurs et surtout d'etcd conditionne tout le reste. Une latence d'écriture élevée sur etcd dégrade l'ensemble du cluster de façon diffuse.
Sur un cluster managé, cette partie est prise en charge par le fournisseur.
Prometheus est le standard de fait pour le niveau cluster. Combiné à kube-state-metrics, qui expose l'état des objets Kubernetes, et à node-exporter pour les métriques des nœuds, il couvre l'essentiel. C'est l'écosystème le plus documenté, mais aussi un composant supplémentaire à héberger et maintenir — souvent dans le cluster qu'il surveille, ce qui pose un problème évident quand celui-ci est en difficulté.
Une supervision système classique sur les nœuds reste pertinente en complément : elle est indépendante du cluster, donc elle continue de fonctionner et de vous alerter quand le cluster va mal. C'est la différence entre constater après coup et être prévenu.
Héberger toute sa supervision dans le cluster qu'elle surveille est un piège classique. Quand le cluster tombe, la supervision tombe avec lui — et personne n'est prévenu. Au minimum, la supervision des nœuds devrait être externe.
Les nœuds d'un cluster Kubernetes sont supervisés comme des serveurs Linux : disque avec découverte automatique des volumes, mémoire, charge, services systemd — dont kubelet et containerd — et réseau.
Cette supervision est indépendante du cluster : elle continue de fonctionner et d'alerter si le plan de contrôle est en difficulté, ce qui en fait un complément utile d'un Prometheus interne plutôt qu'un concurrent.
Les métriques Kubernetes elles-mêmes — état des pods, déploiements, requests et limits — ne sont pas couvertes par les templates fournis.
Disque, mémoire, charge, services systemd et réseau, comme sur tout serveur Linux.
La collecte continue de fonctionner si le plan de contrôle est indisponible.
État des pods et objets du cluster relèvent de kube-state-metrics et Prometheus.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.