Monitoring Kubernetes : métriques, technologies et conseils pour réussir

Les métriques Kubernetes clés à surveiller

Métriques au niveau du cluster

Les métriques au niveau du cluster offrent une vue d'ensemble de la santé, de la stabilité et de l'utilisation des ressources du cluster Kubernetes. Elles aident les opérateurs à déterminer si le cluster dispose d'une capacité suffisante pour ses workloads et si les services essentiels fonctionnent correctement.

Principales métriques au niveau du cluster :

• Utilisation CPU totale du cluster
• Utilisation mémoire totale du cluster
• Consommation totale de stockage
• Débit réseau du cluster
• Nombre de nœuds actifs
• Nombre de pods en cours d'exécution
• Échecs de planification des pods
• Capacité des ressources du cluster par rapport à l'allocation
• Taux global de requêtes API
• Activité d'autoscaling du cluster
• Nombre de workloads en échec
• Consommation de ressources par namespace

Métriques au niveau des nœuds

Les métriques au niveau des nœuds se concentrent sur la santé et les performances des nœuds worker du cluster. Comme les nœuds fournissent les ressources de calcul des workloads, leur surveillance permet de détecter les pannes matérielles, l'épuisement des ressources ou les problèmes de système d'exploitation susceptibles d'affecter les applications.

Principales métriques au niveau des nœuds :

• Utilisation CPU du nœud
• Utilisation mémoire du nœud
• Utilisation du disque et E/S disque
• Utilisation de la bande passante réseau
• Disponibilité du système de fichiers du nœud
• Uptime du nœud
• Charge moyenne du nœud
• Nombre de pods en cours d'exécution par nœud
• Santé du runtime de conteneurs
• Température du nœud et erreurs matérielles
• Utilisation du swap
• État de disponibilité (readiness) du nœud

Métriques des pods et des conteneurs

Les métriques des pods et des conteneurs offrent une visibilité sur le comportement et la consommation de ressources des workloads Kubernetes. Comme les applications s'exécutent dans des conteneurs, ces métriques sont essentielles pour diagnostiquer les crashs, les goulots d'étranglement et les usages inefficaces de ressources.

Principales métriques des pods et des conteneurs :

• Utilisation CPU du pod
• Utilisation mémoire du pod
• Throttling CPU du conteneur
• Nombre de redémarrages du conteneur
• Statut et cycle de vie du pod
• Dépassements de limites mémoire
• Utilisation disque du conteneur
• Trafic réseau par pod
• Temps de démarrage du pod
• Événements OOMKilled
• Nombre de conteneurs actifs
• Disponibilité et readiness du pod

Métriques des workloads

Les métriques des workloads mesurent les performances et l'état opérationnel des objets Kubernetes tels que les deployments, daemonsets, statefulsets et jobs. Elles aident les équipes à vérifier que les workloads montent en charge correctement et atteignent l'état souhaité.

Principales métriques des workloads :

• Écart entre réplicas souhaités et disponibles
• Statut de déploiement (rollout)
• Santé des replica sets
• Disponibilité des statefulsets
• Taux de complétion des jobs
• Succès d'exécution des CronJobs
• Activité du horizontal pod autoscaler
• Tentatives de déploiement en échec
• Événements de scaling des workloads
• Workloads en attente
• Fréquence des rollbacks
• Requests et limits de ressources par workload

Métriques du plan de contrôle

Les métriques du plan de contrôle suivent la santé et la réactivité des composants cœur de Kubernetes, responsables de la gestion et de l'orchestration du cluster. Leur surveillance est cruciale, car une défaillance du plan de contrôle peut impacter tout le cluster.

Principales métriques du plan de contrôle :

• Latence des requêtes du serveur API
• Taux d'erreurs du serveur API
• Débit de requêtes du serveur API
• Latence du scheduler
• Longueur de la file d'attente du scheduler
• Latence des requêtes etcd
• Taille de la base de données etcd
• Statut d'élection du leader etcd
• Performances du controller manager
• Échecs d'authentification et d'autorisation
• Utilisation CPU et mémoire du plan de contrôle
• Requêtes API en échec

Métriques au niveau applicatif

Les métriques au niveau applicatif se concentrent sur les performances et le comportement des applications qui s'exécutent dans Kubernetes. Elles aident les équipes à comprendre l'expérience utilisateur, à détecter les dégradations de service et à optimiser les performances applicatives.

Principales métriques au niveau applicatif :

• Latence des requêtes
• Débit de requêtes
• Taux d'erreurs
• Répartition des codes de statut HTTP
• Performances des requêtes en base de données
• Sessions utilisateur actives
• Taux de hits et de miss du cache
• Temps de traitement des files d'attente
• Temps de réponse des applications
• Transactions par seconde
• Latence des dépendances de services
• Métriques métier personnalisées

---

Les défis courants du monitoring Kubernetes

Un volume de télémétrie trop important

Les environnements Kubernetes génèrent d'énormes quantités de données télémétriques provenant des conteneurs, des nœuds, des applications et des composants du plan de contrôle. Métriques, logs, traces et événements peuvent saturer les systèmes de monitoring, en particulier dans les grands clusters exécutant de nombreux workloads. Le stockage et le traitement de ces données mobilisent des ressources de calcul, de stockage et de réseau.

Un volume de données élevé complique aussi l'extraction d'informations pertinentes. Les signaux importants peuvent se noyer dans le bruit, ce qui ralentit le dépannage et accroît la complexité opérationnelle. Les organisations mettent souvent en place des politiques de rétention, de l'échantillonnage, du filtrage, de l'agrégation et des stratégies de stockage hiérarchisé pour réduire la télémétrie superflue tout en préservant les informations critiques.

La fatigue liée aux alertes

Des systèmes de monitoring mal configurés peuvent générer un excès d'alertes, dont beaucoup sont de faible priorité, répétitives ou sans intérêt. Dans les environnements Kubernetes, des événements transitoires comme les redémarrages de pods, les actions d'autoscaling ou les pics temporaires de ressources peuvent déclencher de nombreuses notifications. Avec le temps, les équipes d'exploitation finissent par ignorer les alertes, tant il devient difficile de distinguer les incidents critiques du bruit de fond.

La fatigue liée aux alertes réduit l'efficacité du monitoring et augmente le risque de passer à côté de problèmes sérieux. Pour la limiter, les équipes ont besoin de règles d'alerting bien conçues, de seuils ajustés, de regroupements d'alertes et de politiques d'escalade. Certaines plateformes de monitoring recourent à la détection d'anomalies et à la corrélation d'alertes pour réduire les notifications inutiles.

Des workloads éphémères

Les workloads Kubernetes sont dynamiques. Les pods et les conteneurs peuvent être créés, arrêtés, replanifiés ou remplacés en quelques secondes. Cette nature éphémère complique le monitoring : les sources de télémétrie changent en permanence, et les workloads de courte durée peuvent disparaître avant que les données ne soient entièrement collectées ou analysées.

Les approches de monitoring traditionnelles, conçues pour des infrastructures statiques, peinent souvent dans ces environnements. Les systèmes de monitoring doivent découvrir automatiquement les nouveaux workloads, mettre à jour leurs configurations de manière dynamique et maintenir la visibilité au fil des évolutions de l'infrastructure. Un labelling persistant, une collecte télémétrique centralisée et des intégrations natives Kubernetes contribuent à préserver la précision du monitoring.

---

Principales solutions de monitoring Kubernetes

Plateformes commerciales de monitoring et d'optimisation Kubernetes

1. PerfectScale

En savoir plus sur PerfectScale

2. Dynatrace

Dynatrace est une plateforme commerciale de monitoring et d'optimisation Kubernetes qui offre observabilité, analytique et sécurité pour les environnements Kubernetes et les applications cloud-native. Elle prend en charge des distributions Kubernetes telles qu'Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift et Rancher Kubernetes Engine. La plateforme combine métriques, logs, traces et données de sécurité dans une interface unique.

Fonctionnalités clés :

• Observabilité Kubernetes unifiée : Dynatrace collecte et corrèle métriques, logs, traces et événements des clusters Kubernetes au sein d'une même plateforme.
• Découverte automatique des ressources Kubernetes : la plateforme détecte automatiquement les nœuds, pods, workloads et microservices Kubernetes.
• Suivi en temps réel de la santé du cluster : Dynatrace offre une visibilité sur la santé du cluster, notamment la consommation de ressources et le statut des workloads.
• Monitoring et analytique de logs intégrés : les logs Kubernetes peuvent être transmis en continu vers Dynatrace pour une analyse centralisée.
• Tracing distribué pour les microservices : Dynatrace prend en charge le tracing distribué de bout en bout à travers les services et applications Kubernetes.

Source : Dynatrace

3. Datadog

Datadog est une plateforme commerciale de monitoring et d'observabilité Kubernetes qui offre une visibilité sur l'infrastructure, les applications et la sécurité Kubernetes. Elle aide les organisations à surveiller la santé et les performances des clusters Kubernetes dans les environnements cloud-native et hybrides.

Fonctionnalités clés :

• Observabilité Kubernetes unifiée : Datadog collecte et corrèle métriques, logs, traces, trafic réseau et signaux de sécurité au sein d'une même plateforme.
• Prise en charge des environnements Kubernetes à grande échelle : la plateforme surveille des déploiements allant de petits clusters à des environnements de plusieurs milliers de nœuds.
• Dashboards Kubernetes prêts à l'emploi : Datadog inclut des dashboards préconstruits pour suivre la santé du cluster et des workloads.
• Découverte automatique des services : Datadog détecte les services, conteneurs et workloads s'exécutant dans les clusters Kubernetes.
• Monitoring en temps réel de l'infrastructure et des applications : la plateforme surveille les nœuds, pods, services et applications Kubernetes.

Source : Datadog

Stack de monitoring open source / Kubernetes-native

4. Kube-State-Metrics

Kube-state-metrics (KSM) est un service de monitoring Kubernetes open source qui génère des métriques à partir de l'état des objets de l'API Kubernetes. Plutôt que de surveiller directement l'utilisation des ressources ou la santé des composants, il expose des informations sur les objets Kubernetes tels que les pods, deployments, nœuds, replica sets, jobs et statefulsets.

Fonctionnalités clés :

• Suivi de l'état des objets Kubernetes : génère des métriques basées sur l'état courant des objets de l'API Kubernetes.
• Intégration directe avec l'API Kubernetes : écoute le serveur API Kubernetes et expose les données d'état du cluster.
• Export de métriques compatible Prometheus : expose les métriques via l'endpoint HTTP /metrics au format Prometheus.
• Priorité à l'état Kubernetes plutôt qu'à l'utilisation des ressources : privilégie les métriques d'état et de configuration des objets plutôt que les métriques CPU ou mémoire.
• Exposition de données Kubernetes brutes : expose les données directement depuis les objets de l'API Kubernetes.

5. Prometheus

Prometheus est une plateforme open source de monitoring et d'alerting dédiée à la collecte, au stockage, à l'interrogation et à l'analyse de métriques de séries temporelles provenant de systèmes et d'applications. Initialement développé chez SoundCloud et maintenu au sein de la Cloud Native Computing Foundation (CNCF), Prometheus est largement adopté pour le monitoring Kubernetes. Il utilise une architecture de type pull pour collecter les métriques des cibles configurées et les stocke sous forme de séries temporelles labellisées.

Fonctionnalités clés :

• Collecte de métriques en séries temporelles : collecte et stocke les métriques sous forme de séries temporelles avec horodatage et labels.
• Modèle de données multidimensionnel : identifie les métriques par leur nom et des labels clé-valeur.
• Langage de requête PromQL : fournit PromQL pour filtrer, agréger et analyser les données de séries temporelles.
• Conçu pour Kubernetes et les environnements cloud-native : s'intègre à Kubernetes et prend en charge la découverte automatique de services.
• Collecte de métriques en mode pull : utilise un modèle pull HTTP pour collecter les métriques à intervalles réguliers.

Source : Prometheus

6. Grafana

Grafana est une plateforme d'observabilité et de monitoring Kubernetes qui offre une visibilité sur l'infrastructure Kubernetes, les applications, les logs, les métriques et les traces. Via Grafana Cloud, les organisations peuvent surveiller leurs clusters Kubernetes grâce à des dashboards préconstruits, un alerting automatisé et des fonctionnalités d'observabilité full-stack. Grafana s'intègre à Prometheus, Loki, OpenCost et d'autres outils cloud-native pour aider les équipes à résoudre les incidents, optimiser l'utilisation des ressources et réduire les coûts d'infrastructure.

Fonctionnalités clés :

• Observabilité Kubernetes unifiée : offre une visibilité sur les clusters, conteneurs, workloads, logs, métriques et traces.
• Déploiement et configuration rapides pour Kubernetes : Grafana Cloud inclut des charts Helm, des dashboards préconfigurés et des règles d'alerting intégrées.
• Dashboards Kubernetes prêts à l'emploi : propose des dashboards clés en main pour suivre CPU, mémoire, réseau et santé des workloads.
• Analyse des causes racines assistée par IA : exploite des analyses basées sur l'IA pour identifier les incidents et recommander les prochaines étapes.
• Visibilité full-stack avec knowledge graph : le Grafana Cloud Knowledge Graph cartographie les relations entre clusters, nœuds, pods, conteneurs, services et applications.

Source : Grafana

Contenu associé : consultez notre guide sur les outils de monitoring Kubernetes

---

Monitoring Kubernetes : 5 conseils pour réussir

1. Comparer les requests CPU et mémoire à l'utilisation réelle

Les requests et limits de ressources Kubernetes influencent la planification, les performances et l'efficacité de l'infrastructure. Surveiller l'écart entre les ressources demandées et l'utilisation réelle aide les équipes à vérifier si les workloads consomment ce qui leur a été alloué. Des écarts importants révèlent souvent des configurations inefficaces qui gaspillent la capacité du cluster.

Le suivi de ces métriques aide également à prévenir la contention de ressources et l'instabilité applicative. Les workloads dont les requests mémoire ou CPU sont insuffisantes peuvent subir du throttling, des évictions ou une dégradation des performances lors des pics de trafic. Un monitoring continu permet aux équipes d'ajuster les requests et limits selon le comportement des workloads.

2. Identifier les workloads surprovisionnés et sous-provisionnés

Les workloads surprovisionnés réservent plus de ressources que nécessaire, ce qui augmente les coûts d'infrastructure et réduit l'efficacité du cluster. Les workloads sous-provisionnés peuvent souffrir de throttling CPU, de pression mémoire ou de crashs applicatifs. Le monitoring de l'utilisation des ressources aide les équipes à repérer ces deux situations et à concilier performance et maîtrise des coûts.

Les tendances d'utilisation historiques permettent d'identifier des schémas de long terme. Les équipes peuvent analyser l'utilisation moyenne et les pics pour appliquer le right-sizing aux workloads et améliorer l'utilisation du cluster. Des outils d'optimisation automatisée et des moteurs de recommandation peuvent aider à détecter les allocations de ressources inefficaces.

3. Prioriser les configurations à risque et sources de gaspillage

Toutes les inefficacités de ressources n'ont pas le même impact opérationnel. Le monitoring doit prioriser les workloads dont les configurations génèrent le plus de risque ou de gaspillage : limits de ressources absentes, requests mémoire excessives ou comportement d'autoscaling instable. Ces workloads sont plus susceptibles de provoquer une instabilité des nœuds, des échecs de planification ou des dépenses d'infrastructure inutiles.

La priorisation par risque aide les équipes à concentrer leurs efforts de remédiation. Par exemple, des workloads de production à fort trafic sans limits mémoire présentent un risque opérationnel supérieur à des workloads de développement de faible priorité. La visibilité sur la qualité des configurations à travers les namespaces et les équipes améliore la gouvernance et la fiabilité du cluster.

4. Surveiller le comportement de l'autoscaling

Les mécanismes d'autoscaling de Kubernetes, tels que le horizontal pod autoscaler (HPA), le vertical pod autoscaler (VPA) et le cluster autoscaler, s'appuient sur les données de monitoring. Suivre le comportement de l'autoscaling permet de vérifier que les workloads montent en charge correctement face aux variations de trafic et que les événements de scaling se déclenchent aux seuils appropriés.

Le monitoring de l'autoscaling aide aussi à identifier des problèmes comme des réactions de scaling retardées, des oscillations ou des pénuries de ressources empêchant la montée en charge. En analysant l'activité de scaling en parallèle des métriques de performance, les équipes peuvent ajuster les paramètres des autoscalers et améliorer la réactivité des applications sous charge.

5. Valider les optimisations avec les données d'observabilité

Les changements d'optimisation de ressources doivent être validés après déploiement à l'aide des métriques, logs et traces. Réduire les allocations CPU ou mémoire sans validation peut introduire de la latence, de l'instabilité ou des pannes. Les données d'observabilité permettent de confirmer que les efforts d'optimisation ont amélioré l'efficacité sans dégrader les performances applicatives.

Une validation continue est essentielle, car le comportement des workloads évolue dans le temps. Les schémas de trafic, les mises à jour applicatives et les changements d'infrastructure peuvent modifier les besoins en ressources. Surveiller l'impact des changements de configuration permet aux équipes de procéder à des ajustements fondés sur les données et de maintenir l'équilibre entre fiabilité, performance et maîtrise des coûts.

---

Conclusion

Le monitoring Kubernetes est déterminant pour garantir la stabilité et les performances d'environnements hautement dynamiques et distribués. Une stratégie robuste consiste à collecter et corréler les données télémétriques essentielles (métriques, logs, traces et événements) afin d'obtenir une visibilité approfondie. Surmonter les défis courants, comme le volume de données, passe par l'adoption de bonnes pratiques telles que l'optimisation continue des ressources. En priorisant les métriques clés et en validant les changements grâce aux données d'observabilité, les équipes peuvent renforcer la disponibilité et améliorer la maîtrise des coûts.