Comment surveiller un cluster Kubernetes

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.

Trois niveaux, trois outils différents

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.

Niveau nœud : ce que la supervision classique couvre

Les conditions du nœud

Kubernetes expose l'état de chaque nœud sous forme de conditions. Trois méritent une alerte :

• DiskPressure : l'espace disque du nœud se raréfie. Le kubelet commence à évincer des pods et à supprimer des images.
• MemoryPressure : la mémoire disponible passe sous le seuil d'éviction.
• NotReady : le nœud ne répond plus au plan de contrôle. Ses pods seront replanifiés après un délai.

kubectl get nodes
kubectl describe node <nom> | grep -A 10 Conditions

Ces 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.

L'espace disque des nœuds

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.

Le kubelet et le runtime de conteneurs

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 containerd

Niveau cluster : ce qui demande des outils dédiés

Les pods en échec permanent

L'é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).

Requests, limits et évictions

C'est la source d'incidents la plus spécifique à Kubernetes, et la moins intuitive.

• Un pod sans requests définies peut être planifié sur un nœud qui n'a pas les ressources nécessaires.
• Un pod dont la consommation dépasse sa limit mémoire est arrêté par le noyau, puis redémarré. Indéfiniment.
• Un pod qui dépasse sa limit processeur n'est pas arrêté mais étranglé : il ralentit sans qu'aucune erreur n'apparaisse.

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.

Le plan de contrôle

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.

Quels outils pour quel niveau

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.

Avec Logiserv

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.

Supervision des nœuds

Native

Disque, mémoire, charge, services systemd et réseau, comme sur tout serveur Linux.

Indépendance

Hors du cluster

La collecte continue de fonctionner si le plan de contrôle est indisponible.

Métriques Kubernetes

Non couvertes

État des pods et objets du cluster relèvent de kube-state-metrics et Prometheus.

Pour aller plus loin

• Comment surveiller Docker — le niveau conteneur, hors orchestrateur
• Pourquoi superviser un serveur Linux — la supervision des nœuds
• Surveiller l'espace disque d'un serveur — la cause de DiskPressure
• Quelles métriques surveiller sur un serveur — le plan général
• Supervision serveur Windows et Linux : le guide — la démarche complète