Surveillance des ressources du cluster Kubernetes

J'ai créé Kube Eagle - un exportateur Prometheus. Cela s’est avéré être une bonne chose qui aide à mieux comprendre les ressources des clusters de petite et moyenne taille. En fin de compte, j'ai économisé des centaines de dollars parce que j'ai sélectionné les bons types de machines et configuré les limites de ressources d'application pour les charges de travail.

je vais vous parler des avantages Aigle Kube, mais je vais d’abord expliquer ce qui a causé tout ce tapage et pourquoi une surveillance de haute qualité était nécessaire.

J'ai géré plusieurs clusters de 4 à 50 nœuds. Chaque cluster contient jusqu'à 200 microservices et applications. Pour mieux utiliser le matériel existant, la plupart des déploiements ont été configurés avec des ressources RAM et CPU extensibles. De cette façon, les pods peuvent utiliser les ressources disponibles si nécessaire, tout en n'interférant pas avec les autres applications sur ce nœud. Eh bien, n'est-ce pas génial ?

Et bien que le cluster consommait relativement peu de CPU (8 %) et de RAM (40 %), nous avions constamment des problèmes de préemption des pods lorsqu'ils tentaient d'allouer plus de mémoire que ce qui était disponible sur le nœud. À l’époque, nous n’avions qu’un seul tableau de bord pour surveiller les ressources Kubernetes. Comme ça:

Tableau de bord Grafana avec métriques cAdvisor uniquement

Avec un tel panneau, ce n'est pas un problème de voir des nœuds qui consomment beaucoup de mémoire et de CPU. Le problème est de comprendre quelle en est la raison. Pour maintenir les pods en place, on pourrait bien sûr mettre en place des ressources garanties sur tous les pods (ressources demandées égales à la limite). Mais ce n’est pas l’utilisation la plus intelligente du matériel. Le cluster disposait de plusieurs centaines de gigaoctets de mémoire, tandis que certains nœuds mouraient de faim, tandis que d'autres disposaient de 4 à 10 Go en réserve.

Il s'avère que le planificateur Kubernetes répartit les charges de travail de manière inégale entre les ressources disponibles. Le planificateur Kubernetes prend en compte différentes configurations : règles d'affinité, de teintes et de tolérances, sélecteurs de nœuds pouvant limiter les nœuds disponibles. Mais dans mon cas il n'y avait rien de tel, et les pods étaient planifiés en fonction des ressources demandées sur chaque nœud.

Le nœud qui dispose du plus grand nombre de ressources libres et qui satisfait aux conditions de la demande a été sélectionné pour le pod. Nous avons constaté que les ressources demandées sur les nœuds ne correspondaient pas à l'utilisation réelle, et c'est là que Kube Eagle et ses capacités de surveillance des ressources sont venus à la rescousse.

J'ai presque tous les clusters Kubernetes surveillés uniquement avec Exportateur de nœuds и Mesures de l'état du Kube. Node Exporter fournit des statistiques sur les E/S et l'utilisation du disque, du processeur et de la RAM, tandis que Kube State Metrics affiche les métriques des objets Kubernetes telles que les requêtes et les limites des ressources du processeur et de la mémoire.

Nous devons combiner les métriques d'utilisation avec les métriques de demandes et de limites dans Grafana, puis nous obtiendrons toutes les informations sur le problème. Cela semble simple, mais les deux outils nomment les étiquettes différemment, et certaines métriques n'ont aucune étiquette de métadonnées. Kube Eagle fait tout lui-même et le panneau ressemble à ceci :

Tableau de bord Kube Eagle

Nous avons réussi à résoudre de nombreux problèmes de ressources et à économiser du matériel :

1. Certains développeurs ne savaient pas de combien de ressources les microservices avaient besoin (ou ne s'en souciaient tout simplement pas). Nous n'avions aucun moyen de trouver des demandes de ressources incorrectes - pour cela, nous devons connaître la consommation ainsi que les demandes et les limites. Ils voient désormais les métriques Prometheus, surveillent l'utilisation réelle et ajustent les demandes et les limites.
2. Les applications JVM consomment autant de RAM qu'elles peuvent en gérer. Le garbage collector ne libère de la mémoire que lorsque plus de 75 % est utilisée. Et comme la plupart des services disposent d'une mémoire extensible, celle-ci était toujours occupée par la JVM. Par conséquent, tous ces services Java consommaient beaucoup plus de RAM que prévu.
3. Certaines applications demandaient trop de mémoire et le planificateur Kubernetes ne donnait pas ces nœuds à d'autres applications, même s'ils étaient en fait plus libres que les autres nœuds. Un développeur a accidentellement ajouté un chiffre supplémentaire dans la requête et a récupéré une grande quantité de RAM : 20 Go au lieu de 2. Personne ne l'a remarqué. L'application comportait 3 répliques, donc jusqu'à 3 nœuds étaient affectés.
4. Nous avons introduit des limites de ressources, reprogrammé les pods avec les requêtes correctes et obtenu un équilibre idéal d'utilisation du matériel sur tous les nœuds. Quelques nœuds auraient pu être complètement fermés. Et puis on a vu qu'on s'était trompés de machines (orientées CPU, pas orientées mémoire). Nous avons modifié le type et supprimé plusieurs nœuds supplémentaires.

Les résultats de

Avec des ressources extensibles dans le cluster, vous utilisez le matériel disponible plus efficacement, mais le planificateur Kubernetes planifie les pods en fonction des demandes de ressources, ce qui est difficile. Pour faire d’une pierre deux coups : pour éviter les problèmes et utiliser au maximum les ressources, il faut une bonne surveillance. C'est pourquoi ce sera utile Aigle Kube (Exportateur Prometheus et tableau de bord Grafana).

Source: habr.com