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.
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 :
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.
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.
De l’orchestration centrale jusqu’au code applicatif, chaque brique du système expose ses propres signaux et appelle une vigilance dédiée :
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é.
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.
| Composant | Rôle | Déploiement |
| Prometheus | Collecte et stockage des métriques par scraping | Operator ou Deployment |
| node-exporter | Métriques système de chaque nœud (CPU, mémoire, disque, réseau) | DaemonSet |
| kube-state-metrics | État des objets Kubernetes (déploiements, pods, réplicas) | Deployment |
| cAdvisor | Métriques des conteneurs (CPU, mémoire, fichiers) | Intégré au kubelet |
| Metrics Server | Métriques temps réel pour kubectl top et l’autoscaling (HPA) | Deployment |
| Grafana | Visualisation et tableaux de bord | Deployment |
| Alertmanager | Gestion, regroupement et routage des alertes | Operator ou Deployment |
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-namespaceCet 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.
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.
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.
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 :
Quel que soit le choix, un pipeline OpenTelemetry en amont préserve la portabilité des données.
Mettre en place une stratégie efficace repose sur quelques principes simples, à appliquer dès les premières étapes du projet :
Certains réflexes, en apparence anodins, fragilisent durablement la fiabilité du dispositif mis en place :
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.
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.
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.
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.
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.
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.
