Performance Kubernetes : 10 métriques clés et guide de tuning

Qu'est-ce que la performance Kubernetes ?

TL;DR : La performance Kubernetes se définit par l'efficacité, la fiabilité et la rapidité de votre cluster. Les domaines clés incluent les temps de démarrage des pods, la réactivité du serveur d'API et la consommation de ressources. L'optimiser exige d'ajuster finement les allocations de ressources, d'éviter le throttling CPU et d'utiliser des outils comme ClusterLoader2 pour évaluer les limites du cluster sous charge.

Métriques de performance critiques :

Pour préserver la santé du cluster, vous devez suivre activement ces domaines essentiels :

• Utilisation CPU : surveillez l'utilisation CPU des pods, des conteneurs et des nœuds pour identifier la contention des ressources, le throttling et les contraintes de capacité.
• Utilisation mémoire : suivez la consommation mémoire pour détecter les fuites, prévenir la pression sur les nœuds et éviter les évictions de pods.
• Redémarrages de pods : surveillez les redémarrages fréquents de conteneurs, qui peuvent révéler des plantages applicatifs, des probes en échec ou des limites de ressources dépassées.
• Statut et disponibilité des pods : surveillez l'état et la readiness des pods afin de garantir que les workloads restent sains et capables de servir le trafic.
• Métriques de pression des nœuds : suivez le throttling CPU, la consommation mémoire totale et les I/O disque, car les goulots d'étranglement au niveau des nœuds se répercutent sur les workloads.
• I/O disque et stockage : mesurez le débit, la latence et les IOPS pour identifier les goulots d'étranglement de stockage qui affectent les performances applicatives.
• Performance du scheduler : suivez la latence de scheduling, les pods en attente et les échecs de placement pour garantir un placement efficace des workloads.
• Métriques d'autoscaling : surveillez l'activité de scaling, le nombre de réplicas et les métriques d'utilisation pour vérifier que les autoscalers répondent correctement aux variations de la demande.
• Métriques applicatives : mesurez la latence, le débit, les taux d'erreur et d'autres indicateurs de niveau de service pour comprendre la performance perçue par les utilisateurs.
• Métriques du plan de contrôle : surveillez la latence d'etcd (idéalement <10 ms) et les latences de requêtes du kube-apiserver pour prévenir les goulots d'étranglement de l'API.

Dans cet article :

• Pourquoi la performance Kubernetes est essentielle
• Problèmes de performance Kubernetes courants
• Métriques de performance Kubernetes critiques
• Comment diagnostiquer les problèmes de performance Kubernetes
• Bonnes pratiques de tuning de la performance Kubernetes

---

Pourquoi la performance Kubernetes est essentielle

La performance Kubernetes influe sur la disponibilité des applications, la scalabilité et la maîtrise des coûts. Un cluster performant absorbe des workloads variables avec un minimum de latence, tandis qu'une performance médiocre entraîne des temps de réponse dégradés, des interruptions de service et un gaspillage de ressources d'infrastructure. À mesure que les organisations s'appuient sur Kubernetes pour exécuter leurs systèmes de production, maintenir une performance solide devient indispensable pour atteindre les objectifs métier et opérationnels.

• Fiabilité applicative accrue : une allocation des ressources et un scheduling efficaces aident les applications à rester stables face à des workloads variables, réduisant le risque de pannes et de dégradation des performances.
• Meilleure expérience utilisateur : des démarrages de pods plus rapides, une latence réduite et une réactivité applicative constante améliorent l'expérience des utilisateurs finaux.
• Scaling efficace : les clusters performants réagissent rapidement aux variations de la demande, garantissant que les workloads montent en charge sans délais superflus.
• Réduction des coûts d'infrastructure : une utilisation optimisée du CPU, de la mémoire, du stockage et du réseau limite le gaspillage de ressources et aide les organisations à éviter le surprovisionnement.
• Prévention de la contention des ressources : le tuning des performances garantit que les workloads ne se disputent pas excessivement les ressources partagées, ce qui réduit les goulots d'étranglement et préserve un comportement prévisible.
• Efficacité opérationnelle renforcée : un scheduling plus rapide, une reprise accélérée après incident et un fonctionnement plus fluide du cluster allègent la charge des équipes plateforme et opérations.
• Respect des objectifs de niveau de service (SLO) : surveiller et optimiser la performance permet aux organisations de tenir leurs cibles de disponibilité, de temps de réponse et de fiabilité.
• Stabilité du cluster consolidée : identifier et résoudre les problèmes tels que la pression sur les nœuds, les redémarrages excessifs de pods ou les lenteurs du plan de contrôle contribue à maintenir un environnement Kubernetes sain et résilient.

---

Problèmes de performance Kubernetes courants

1. Requests et limits de ressources mal configurés

Des requests et limits de ressources mal définis sont une cause fréquente de problèmes de performance dans les environnements Kubernetes. Si les requests sont trop élevés, le scheduler peut laisser des nœuds sous-utilisés, entraînant un gaspillage de ressources et des coûts d'infrastructure accrus. À l'inverse, des requests trop faibles peuvent pousser les applications à se disputer le CPU et la mémoire, augmentant la probabilité de throttling et d'erreurs out-of-memory (OOM). Ce déséquilibre affecte la stabilité des workloads et l'efficience du cluster.

Les limits de ressources influencent également la performance. Lorsqu'elles sont trop agressives, les pods peuvent être arrêtés ou throttlés, perturbant la disponibilité du service. Sans limits, des processus incontrôlés peuvent consommer toutes les ressources disponibles d'un nœud, au détriment des workloads voisins.

Comment y remédier : Trouver le bon équilibre exige une analyse continue des schémas d'utilisation et un ajustement des requests et limits à mesure que les workloads évoluent.

2. Throttling CPU

Le throttling CPU survient lorsqu'un conteneur tente d'utiliser plus de CPU que la limite qui lui est allouée, ce qui conduit Kubernetes à restreindre sa consommation. Il peut en résulter des temps de réponse allongés, un débit applicatif dégradé et une performance imprévisible. Le throttling est particulièrement problématique pour les workloads sensibles à la latence, où de brefs ralentissements peuvent affecter l'expérience utilisateur ou la fiabilité du service. Un throttling CPU fréquent découle souvent de limits CPU trop basses par rapport aux besoins du workload.

Comment y remédier : Surveiller l'utilisation CPU et les métriques de throttling permet d'identifier les conteneurs concernés. La résolution passe généralement par le right-sizing des requests et limits CPU et par des politiques d'autoscaling qui tolèrent les workloads en rafale sans introduire de throttling inutile.

3. Pression mémoire et évictions de pods

La pression mémoire survient lorsqu'un nœud manque de mémoire disponible, forçant le scheduler Kubernetes à évincer des pods pour libérer des ressources. Cela peut perturber la disponibilité des applications, surtout si des services critiques sont arrêtés ou si les pods évincés mettent longtemps à redémarrer. La pression mémoire est souvent causée par une surallocation, une utilisation mémoire applicative inefficace ou l'absence de limits mémoire sur certains workloads. Les évictions de pods liées à la pression mémoire peuvent déclencher des défaillances en cascade si d'autres nœuds sont eux aussi proches de la saturation ou si les pods évincés ne peuvent pas être replanifiés ailleurs.

Comment y remédier : Une surveillance continue de l'utilisation mémoire des nœuds, des requests et limits mémoire adaptés et une optimisation de la consommation mémoire des applications aident à prévenir les évictions fréquentes et à préserver la stabilité du cluster.

4. Autoscaling sous-optimal

L'autoscaling est une fonctionnalité centrale de Kubernetes, mais une configuration défaillante peut entraîner un sous-provisionnement ou un surprovisionnement des ressources. Si les seuils de scaling sont trop conservateurs, les workloads risquent de ne pas monter en charge assez vite lors des pics de demande, créant des goulots d'étranglement. Un scaling trop agressif peut provoquer un churn de pods inutile, de la contention de ressources et des coûts d'infrastructure accrus.

Un autoscaling sous-optimal découle souvent de métriques imprécises ou insuffisantes pour piloter les décisions de scaling. Se limiter au CPU ou à la mémoire ne reflète pas toujours la demande réelle du workload, notamment pour les applications sensibles aux I/O ou à la latence.

Comment y remédier : Ajuster les réglages de l'autoscaler et utiliser des métriques personnalisées reflétant la performance applicative sont indispensables pour un scaling efficace et un comportement cohérent des workloads.

5. Probes en cascade

Kubernetes utilise des probes de readiness et de liveness pour déterminer la santé des pods, mais des probes mal conçues peuvent générer des problèmes de performance. Des probes trop fréquentes peuvent submerger l'application de requêtes, augmentant la latence et la consommation de ressources. Dans certains cas, des échecs de probes déclenchent des redémarrages inutiles, entraînant une instabilité du service et des temps de reprise allongés.

Les échecs de probes peuvent aggraver la situation lors d'événements de stress du cluster, comme des pannes de nœuds ou des mises à jour progressives. Si plusieurs pods échouent simultanément à leurs contrôles de santé, cela peut provoquer des redémarrages massifs et dégrader la performance du cluster.

Comment y remédier : Un tuning minutieux des intervalles, des timeouts et des seuils de probes est nécessaire pour éviter ces effets et garantir que les probes remplissent leur rôle.

6. Goulots d'étranglement du stockage

La performance du stockage est un goulot d'étranglement fréquent dans les clusters Kubernetes, en particulier pour les workloads stateful. Des volumes persistants lents, une latence disque élevée ou des IOPS limitées peuvent entraîner des ralentissements applicatifs, des temps de démarrage de pods allongés et, dans le pire des cas, des pertes de données. Ces goulots d'étranglement proviennent souvent de backends de stockage sous-provisionnés ou de schémas d'accès aux données inefficaces.

Comment y remédier : Surveiller les métriques d'I/O de stockage et sélectionner des classes de stockage adaptées est indispensable pour prévenir les goulots d'étranglement. Les workloads à fort débit ou à faible latence doivent s'appuyer sur des solutions de stockage adaptées à leurs besoins. Passer en revue la performance du stockage, ajuster les schémas d'accès applicatifs et faire évoluer les ressources de stockage avec la demande contribuent à maintenir la réactivité du cluster et l'intégrité des données.

---

Métriques de performance Kubernetes critiques

Utilisation CPU

L'utilisation CPU est une métrique de performance Kubernetes essentielle, car elle indique la puissance de calcul consommée par les workloads et les nœuds. Une utilisation CPU élevée peut révéler une charge importante, tandis qu'une utilisation durablement faible suggère un surprovisionnement et une allocation de ressources inefficace. En suivant les tendances d'utilisation CPU dans le temps, les équipes peuvent redimensionner les workloads, améliorer l'efficacité du scheduling et configurer des politiques d'autoscaling qui répondent à la demande.

Pourquoi les métriques CPU sont importantes :

• Surveiller l'utilisation CPU au niveau des pods, des conteneurs et des nœuds aide les équipes à déterminer si les workloads disposent d'une capacité de calcul suffisante pour fonctionner de manière fiable.
• Les métriques CPU sont également essentielles pour identifier le throttling et ajuster les requests et limits de ressources.
• Si les conteneurs atteignent fréquemment leurs limits CPU, les temps de réponse applicatifs peuvent augmenter et le débit diminuer.

Utilisation mémoire

L'utilisation mémoire mesure la quantité de RAM consommée par les conteneurs, les pods et les nœuds au sein d'un cluster Kubernetes. La mémoire étant une ressource non compressible, une consommation excessive peut entraîner de l'instabilité, notamment des erreurs out-of-memory et des évictions de pods.

Pourquoi les métriques d'utilisation mémoire sont importantes :

• Surveiller l'utilisation mémoire aide à identifier les workloads sujets à des fuites mémoire, consommant plus que prévu ou fonctionnant trop près de leurs limits configurées.
• Le suivi de l'utilisation mémoire est critique pour définir des requests et limits justes. Si les requests mémoire sont trop faibles, les pods peuvent être placés sur des nœuds incapables de les soutenir en période de pic.
• Si les limits sont trop restrictives, les applications peuvent être arrêtées de manière inattendue.

Redémarrages de pods

Les redémarrages de pods indiquent la fréquence à laquelle les conteneurs des pods redémarrent, ce qui peut signaler des problèmes applicatifs ou d'infrastructure. Des redémarrages fréquents peuvent résulter de plantages applicatifs, de contrôles de santé en échec, de limits mémoire dépassées, d'erreurs de configuration ou de défaillances de dépendances. Un nombre élevé de redémarrages peut réduire la disponibilité et révéler des problèmes de fiabilité du workload.

Pourquoi les redémarrages de pods sont importants :

• Surveiller les redémarrages de pods aide les équipes à détecter les applications instables avant qu'elles ne provoquent des interruptions de service.
• Les schémas de redémarrage doivent être analysés conjointement avec les logs, l'utilisation des ressources et les résultats des probes pour déterminer la cause racine.
• Réduire les redémarrages superflus améliore la fiabilité applicative, raccourcit les temps de reprise et favorise une performance Kubernetes prévisible.

Statut et disponibilité des pods

Les métriques de statut et de disponibilité des pods indiquent si les workloads s'exécutent comme prévu et si le nombre souhaité de pods est disponible pour servir le trafic. Les états importants incluent Running, Pending, Failed, CrashLoopBackOff et ImagePullBackOff. Des pods bloqués dans un état autre que Running peuvent révéler des problèmes de scheduling ou d'image, une pénurie de ressources ou des erreurs de configuration.

Pourquoi les métriques de pods sont importantes :

• Les métriques de disponibilité sont essentielles pour les workloads de production, car elles reflètent la capacité des applications à répondre à la demande des utilisateurs.
• Surveiller les pods prêts et disponibles aide les équipes à détecter les dégradations de service, les déploiements en échec et les problèmes de capacité.
• Maintenir une forte disponibilité des pods garantit que les applications restent réactives lors des montées en charge, des déploiements et des pannes de nœuds.

Métriques de pression des nœuds

Les métriques de pression des nœuds indiquent si un nœud Kubernetes subit un stress de ressources. Les conditions de pression courantes incluent la pression mémoire, la pression disque et la pression PID. Lorsqu'un nœud entre en état de pression, Kubernetes peut évincer des pods ou empêcher le placement de nouveaux pods sur ce nœud, ce qui peut affecter la disponibilité des applications et la stabilité du cluster.

Pourquoi les métriques de nœuds sont importantes :

• Surveiller la pression des nœuds aide les équipes à identifier les goulots d'étranglement d'infrastructure avant qu'ils ne créent des perturbations.
• Ces métriques doivent être analysées conjointement avec les données de CPU, de mémoire, de disque et de densité de pods pour comprendre pourquoi un nœud est sous tension.
• Traiter la pression des nœuds via la planification de capacité, la redistribution des workloads et le tuning des ressources contribue à maintenir un cluster stable.

I/O disque et stockage

Les métriques d'I/O disque et de stockage mesurent l'efficacité avec laquelle les workloads Kubernetes lisent et écrivent sur les systèmes de stockage. Elles incluent le débit disque, les IOPS, la latence et l'utilisation des volumes. Une performance de stockage médiocre peut ralentir les temps de réponse applicatifs, retarder le démarrage des pods et affecter les workloads stateful tels que les bases de données, les files de messages et les systèmes analytiques.

Pourquoi les métriques d'I/O sont importantes :

• Surveiller les I/O de stockage est indispensable pour détecter les goulots d'étranglement dans les volumes persistants, les classes de stockage et l'infrastructure sous-jacente.
• Une latence élevée ou des IOPS saturées peuvent indiquer qu'un workload a besoin d'un stockage plus rapide, de schémas d'accès aux données optimisés ou de capacité supplémentaire.
• Une performance de stockage solide garantit la réactivité des applications et le fonctionnement fiable des services stateful.

Performance du scheduler

La performance du scheduler mesure la rapidité et l'efficacité avec lesquelles le scheduler Kubernetes affecte les pods aux nœuds. Les indicateurs clés incluent la latence de scheduling des pods, le nombre de pods en attente et les échecs de placement. Un scheduling lent peut retarder le démarrage des applications, réduire la réactivité du scaling et créer des problèmes de disponibilité lors des pics de trafic ou des phases de reprise.

Pourquoi les métriques du scheduler sont importantes :

• Surveiller la performance du scheduler aide à identifier des problèmes comme une capacité de cluster insuffisante, des règles d'affinité trop restrictives, des taints et tolerations, ou des requests de ressources impossibles à satisfaire.
• Un scheduling efficace garantit un placement rapide des workloads sur les nœuds appropriés et une utilisation optimale des ressources du cluster.
• C'est particulièrement important dans les environnements vastes ou dynamiques où les pods sont fréquemment créés, mis à jour ou replanifiés.

Métriques d'autoscaling

Les métriques d'autoscaling montrent avec quelle efficacité Kubernetes ajuste la capacité des workloads et du cluster en fonction de la demande. Elles peuvent inclure l'activité du horizontal pod autoscaler, le nombre de réplicas actuel par rapport au nombre souhaité, l'utilisation CPU ou mémoire, des métriques applicatives personnalisées et le comportement du cluster autoscaler. Un autoscaling correct permet aux applications d'absorber les pics de demande sans intervention manuelle.

Pourquoi les métriques d'autoscaling sont importantes :

• Surveiller ces métriques aide les équipes à déterminer si les politiques de scaling sont trop lentes, trop agressives ou fondées sur des signaux incomplets.
• Si l'autoscaling ne réagit pas assez vite, les utilisateurs peuvent subir de la latence ou des erreurs. S'il réagit de manière trop agressive, les coûts et le churn de pods peuvent augmenter.
• Un autoscaling bien réglé garantit une performance fiable et une utilisation efficiente des ressources.

Métriques applicatives

Les métriques applicatives offrent une visibilité spécifique aux workloads sur la performance des services, du point de vue métier et utilisateur. Elles peuvent inclure la latence des requêtes, les taux d'erreur, le débit, la profondeur des files d'attente, le volume de transactions et des indicateurs de santé propres à chaque service. Alors que les métriques d'infrastructure montrent comment les ressources Kubernetes sont utilisées, les métriques applicatives révèlent si l'application répond aux attentes de performance.

Pourquoi les métriques applicatives sont importantes :

• Surveiller ces métriques relie la performance Kubernetes à l'expérience utilisateur et aux objectifs de niveau de service. Par exemple, l'utilisation CPU et mémoire peut sembler normale alors que la latence des requêtes ou les taux d'erreur augmentent.
• En combinant métriques applicatives et métriques d'infrastructure Kubernetes, les équipes diagnostiquent les problèmes avec plus de précision et priorisent les optimisations qui améliorent la qualité de service.

Métriques du plan de contrôle

Les métriques du plan de contrôle mesurent la santé et la réactivité des composants Kubernetes chargés de gérer le cluster : serveur d'API, scheduler, controller manager et etcd. Les métriques importantes incluent la latence du serveur d'API, les taux de requêtes, la performance d'etcd, la profondeur des files des controllers et les taux d'erreur du plan de contrôle.

Pourquoi les métriques du plan de contrôle sont importantes :

• Un plan de contrôle peu performant peut affecter l'ensemble du cluster, provoquant des retards de scheduling, de scaling, de déploiement et de reprise après incident.
• Surveiller les métriques du plan de contrôle aide les équipes à détecter des problèmes comme la saturation de l'API, des écritures etcd lentes ou des backlogs de controllers.
• Maintenir un plan de contrôle sain garantit que Kubernetes réagit rapidement aux évolutions des workloads et que le cluster fonctionne de manière fiable.

---