Supervision Kubernetes : méthodes, métriques, outils et bonnes pratiques

Superviser Kubernetes consiste à collecter et analyser en continu les métriques, les journaux et les traces d’un cluster, à toutes ses couches : plan de contrôle, nœuds, conteneurs, charges de travail et applications.

La nature dynamique et éphémère de Kubernetes rend cette supervision particulière : les pods naissent et disparaissent en permanence, et un simple tableau de bord ne suffit pas. La pile de référence repose sur Prometheus et Grafana, complétée par les journaux et les traces pour une observabilité complète.

Ce guide technique détaille ce qu’il faut superviser, les métriques prioritaires, la pile Prometheus et Grafana et ses composants, l’observabilité par les logs et les traces, la mise à l’échelle, les solutions managées et les bonnes pratiques. 

Qu’est-ce que la supervision de Kubernetes ? 

La supervision de Kubernetes désigne la surveillance de la santé, des performances et de la disponibilité d’un cluster et des applications qu’il héberge. Elle couvre plusieurs couches imbriquées :

• le plan de contrôle qui orchestre le cluster,
• les nœuds qui fournissent les ressources,
• les conteneurs et les pods qui exécutent les charges,
• les objets Kubernetes qui décrivent l’état désiré,
• et enfin les applications elles-mêmes. 

On distingue souvent la supervision de l’observabilité. La supervision répond à la question « est-ce que ça fonctionne ? » en surveillant des indicateurs connus et en alertant sur des seuils.

L’observabilité va plus loin et permet de comprendre « pourquoi ça ne fonctionne pas » en corrélant métriques, journaux et traces. Dans un environnement aussi distribué que Kubernetes, les deux sont nécessaires, et la frontière entre elles tend à s’estomper. 

Pourquoi superviser Kubernetes est-il particulier ?

Kubernetes n’est pas un serveur statique que l’on observe une fois pour toutes. Les pods sont éphémères : ils sont créés, déplacés et détruits au gré des déploiements, des pannes et de l’autoscaling.

Une adresse, un conteneur ou un nœud surveillé aujourd’hui peut ne plus exister dans une heure. La supervision doit donc suivre des cibles mouvantes, ce qui suppose une découverte automatique des services plutôt qu’une liste figée d’hôtes. 

Cette dynamique a deux conséquences directes. D’une part, il faut relier chaque métrique à son contexte (quel pod, quel déploiement, quel namespace, quelle version) pour qu’elle soit exploitable.

D’autre part, la multiplication des étiquettes et des objets fait exploser la cardinalité des données, principal facteur de coût et de complexité d’une plateforme de supervision Kubernetes. Maîtriser cette cardinalité est un enjeu permanent.

Que superviser dans Kubernetes : les couches d’un cluster

De l’orchestration centrale jusqu’au code applicatif, chaque brique du système expose ses propres signaux et appelle une vigilance dédiée :

• Le plan de contrôle : l’API Server, etcd, le scheduler et le controller-manager : leur disponibilité conditionne tout le cluster. Latence de l’API et santé d’etcd sont critiques. 
• Les nœuds : CPU, mémoire, disque, réseau et conditions de pression (memory pressure, disk pressure) de chaque nœud, qui déterminent la capacité réelle du cluster. 
• Les conteneurs et les pods : consommation de ressources par conteneur, redémarrages, états anormaux comme CrashLoopBackOff ou les pods bloqués en Pending. 
• Les charges de travail : l’état des objets Kubernetes : réplicas disponibles d’un Deployment, phase des pods, jobs et CronJobs, écart entre l’état désiré et l’état réel. 
• Les applications : les métriques métier exposées par vos services (latence, taux d’erreur, débit), au plus près de l’expérience utilisateur. 
• Le réseau et le stockage : trafic entre services, politiques réseau, volumes persistants et leur saturation. 

Quelles métriques surveiller en priorité ? 

Plutôt que de tout mesurer, on s’appuie sur des méthodes éprouvées. Les quatre signaux d’or (golden signals) couvrent la latence, le trafic, les erreurs et la saturation. La méthode USE (utilisation, saturation, erreurs) cible les ressources comme les nœuds, tandis que la méthode RED (débit, erreurs, durée) cible les services applicatifs. Ces cadres évitent la noyade sous les métriques. 

À ces principes s’ajoutent quelques indicateurs Kubernetes incontournables, à traduire en alertes : 

# Pods qui redémarrent en boucle (CrashLoopBackOff) 

kube_pod_container_status_restarts_total > 5 

  

# Saturation mémoire imminente d'un noeud 

node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1 

  

# Pods bloqués en attente de planification 

kube_pod_status_phase{phase="Pending"} > 0 

On surveille aussi l’écart entre les demandes et limites de ressources (requests et limits) et la consommation réelle, qui révèle le sous-dimensionnement comme le gaspillage, ainsi que la disponibilité des réplicas par rapport à l’état désiré.

Comment superviser Kubernetes avec Prometheus et Grafana ?

La supervision native de Kubernetes repose sur Prometheus, le standard de fait pour les métriques cloud-native (projet diplômé de la CNCF). Son principe est de collecter (scraper) périodiquement les métriques exposées par des cibles sur des endpoints HTTP, généralement /metrics. Autour de lui gravitent plusieurs composants spécialisés. 

Un point d’attention fréquent : Metrics Server n’est pas un outil de supervision historique. Il fournit des métriques instantanées qui alimentent la commande kubectl top et les décisions d’autoscaling, mais il ne conserve pas l’historique, à la différence de Prometheus.

Déployer et maintenir tous ces composants un par un serait fastidieux ; la communauté fournit donc un paquet Helm tout-en-un, kube-prometheus-stack, qui installe Prometheus, Grafana, Alertmanager, node-exporter, kube-state-metrics et l’opérateur Prometheus en une seule commande.

helm repo add prometheus-community \ 

  https://prometheus-community.github.io/helm-charts 

helm repo update 

helm install monitoring \ 

  prometheus-community/kube-prometheus-stack \ 

  --namespace monitoring --create-namespace

Cet opérateur introduit des ressources personnalisées comme ServiceMonitor et PrometheusRule, qui permettent de déclarer la configuration de collecte et les règles d’alerte de façon déclarative, dans le même esprit que le reste de Kubernetes.

Grafana, enfin, exploite ces métriques dans les tableaux de bord, dont de nombreux modèles publics prêts à importer pour Kubernetes.

Métriques, logs, traces : les 3 piliers de l’observabilité Kubernetes

Les métriques disent qu’un problème existe, rarement pourquoi. Pour une observabilité complète, on ajoute les deux autres piliers.

Les journaux (logs) apportent le détail des événements, collectés à l’échelle du cluster par des outils comme Loki, agrégateur de logs conçu pour s’intégrer à Grafana.

Les traces suivent le parcours d’une requête entre les microservices, avec Tempo ou Jaeger, indispensables pour diagnostiquer une latence dans une architecture distribuée. 

Le standard ouvert OpenTelemetry s’impose pour instrumenter les applications une seule fois et envoyer métriques, journaux et traces vers la plateforme de son choix, en limitant la dépendance à un fournisseur.

Une approche plus récente, fondée sur eBPF, permet de collecter de la télémétrie au niveau du noyau Linux sans modifier le code des applications ; des outils comme Pixie, Cilium Hubble ou Coroot en tirent parti pour une visibilité immédiate sur le trafic et les performances.

La clé reste la corrélation : relier une métrique, une trace et les journaux associés par des métadonnées communes transforme des signaux épars en diagnostic. 

Comment superviser Kubernetes à grande échelle ?

Prometheus est excellent pour la collecte, mais son stockage local n’est pas conçu pour la longue durée ni la haute disponibilité. À l’échelle de plusieurs clusters ou pour conserver l’historique sur des mois, on lui adjoint des solutions de stockage distribué comme Thanos, Cortex ou Mimir, qui apportent rétention longue, redondance et vue multi-cluster centralisée. 

C’est aussi à cette échelle que la cardinalité devient critique. Chaque étiquette, chaque pod, chaque service et chaque métrique personnalisée multiplie le volume de séries temporelles, avec un impact direct sur les coûts et les performances.

La discipline consiste à choisir des étiquettes pertinentes, à éviter les valeurs illimitées dans les métriques, et à s’appuyer sur des ensembles de kube-state-metrics raisonnés plutôt que de tout collecter. 

Supervision Kubernetes : solutions managées ou commerciales ?

Opérer soi-même la pile open source offre un contrôle total, mais représente une charge réelle (déploiement, mise à l’échelle, mises à jour, stockage). Beaucoup d’organisations optent pour des services managés.

Les fournisseurs cloud proposent des offres intégrées à leur Kubernetes managé : Azure Monitor pour conteneurs et Azure Managed Prometheus pour AKS, CloudWatch Container Insights et Amazon Managed Service for Prometheus côté AWS, ou la suite Google Cloud Operations sur GKE. 

Côté éditeurs, des plateformes comme Datadog, Dynatrace, New Relic (avec Pixie) ou Sysdig couvrent métriques, journaux, traces et événements dans une interface unifiée, avec analyse de cause racine assistée.

Le choix dépend de l’arbitrage habituel :

• l’open source maximise le contrôle et la maîtrise des coûts au prix de l’effort d’exploitation,
• le managé et le commercial réduisent cette charge contre un coût de licence qui croît avec le volume de télémétrie.

Quel que soit le choix, un pipeline OpenTelemetry en amont préserve la portabilité des données.

Les bonnes pratiques de supervision Kubernetes 

Mettre en place une stratégie efficace repose sur quelques principes simples, à appliquer dès les premières étapes du projet :

• Commencer par les signaux d’or : latence, trafic, erreurs et saturation avant la multiplication des métriques secondaires.
• Automatiser la découverte des cibles : profiter de l’opérateur Prometheus et des ServiceMonitor pour suivre des pods éphémères sans configuration manuelle.
• Maîtriser la cardinalité : choisir des étiquettes utiles, bannir les valeurs illimitées et surveiller la croissance des séries temporelles.
• Corréler les trois piliers : relier métriques, journaux et traces par des métadonnées communes pour un diagnostic rapide.
• Définir des alertes actionnables : alerter sur des symptômes utilisateurs et des conditions critiques, pas sur chaque variation, pour éviter la fatigue d’alerte.
• Planifier la rétention et la haute disponibilité : prévoir Thomas, Mimir ou un service managé dès que l’historique et la résilience comptent.
• Superviser le plan de contrôle : ne pas se limiter aux applications, la santé de l’API Server et d’etcd conditionne tout le cluster.

Quels sont les pièges à éviter ?

Certains réflexes, en apparence anodins, fragilisent durablement la fiabilité du dispositif mis en place :

• Confondre Metrics Server et supervision : Metrics Server alimente l’autoscalling et kubectl top, mais ne conserve pas l’historique ; il ne remplace pas Prometheus.
• Ignorer la cardinalité : mal gérée, elle fait exploser les coûts et dégrade les performances de la plateforme de supervision.
• Collecter sans corréler : empiler métriques, journaux et traces sans métadonnées communes produit des silos coûteux plutôt qu’une observabilité.
• Sous-estimer l’effort de l’open source : gratuit en licence ne veut pas dire gratuit (exploitation, stockage et haute disponibilité ont un coût en temps).
• Négliger le plan de contrôle : surveiller les seules applications laisse aveugle sur des pannes qui prennent racine dans l’API Server ou etcd.
• Noyer les équipes sous les alertes : trop d’alertes non actionnables tuent la réactivité, mieux vaut peu d’alertes pertinentes.

FAQ : supervision Kubernetes 

Quels outils pour superviser un cluster Kubernetes ? 

La pile open source de référence associe Prometheus (collecte des métriques), Grafana (tableaux de bord) et Alertmanager (alertes), complétée par les exporters node-exporter et kuber-state-metrics.

Le paquet Helm kube-prometheus-stack installe l’ensemble en une commande. Pour les journaux et les traces, on ajoute Loki et Tempo ou Jaeger.

Quelle différence entre Metrics Server et Prometheus ? 

Metrics Server fournit des métriques instantanées qui alimentent kubectl top et l’autoscaling horizontal (HPA), mais ne conserve pas d’historique. Prometheus collecte, stocke et historise les métriques pour la supervision, l’analyse et l’alerte. Les deux sont complémentaires.

Quelles métriques surveiller en priorité ? 

Les quatre signaux d’or (latence, trafic, erreurs, saturation), complétés par des indicateurs Kubernetes clés : redémarrages de pods (CrashLoopBackOff), pods bloqués en Pending, pression mémoire ou disque des nœuds, et écart entre l’état désiré et l’état réel des déploiements.

Faut-il aussi collecter les journaux et les traces ? 

Oui pour une observabilité complète. Les métriques signalent un problème, les journaux en donnent en détail, et les traces suivent une requête entre microservices. OpenTelemetry permet d’instrumenter une fois et d’envoyer ces signaux vers la plateforme de son choix.

Open source ou solution managée ? 

L’open source (Prometheus, Grafana) maximise le contrôle et la maîtrise des coûts mais demande de l’exploitation. Les services managés (Azure Managed Prometheus, AWS, Google Cloud) et les plateformes commerciales (Datadog, Dynatrace) réduisent cette charge à un coût plus élevé qui croît avec le volume. 

Comment gérer la montée en charge de la supervision ? 

Prometheus n’est pas conçu pour la rétention longue ni la haute disponibilité. On lui adjoint Thanos, Cortex ou Mimir pour conserver l’historique, assurer la redondance et offrir une vue multi-cluster, tout en maîtrisant la cardinalité des métriques.