J'ai créé Kube Eagle — un exportateur Prometheus. C'est un outil génial qui aide à mieux comprendre les ressources des petits et moyens clusters. En fin de compte, j'ai économisé plusieurs centaines de dollars en choisissant les bons types de machines et en ajustant les limites des ressources des applications en fonction des charges de travail.
Je vais parler des avantages , mais d'abord, je vais expliquer ce qui a causé des problèmes et pourquoi un bon monitoring était nécessaire.
J'ai géré plusieurs clusters de 4 à 50 nœuds. Dans chaque cluster, il y avait jusqu'à 200 microservices et applications. Pour utiliser efficacement le matériel disponible, la plupart des déploiements étaient configurés avec de la RAM et des ressources CPU burstables. Ainsi, les pods pouvaient utiliser des ressources disponibles si nécessaire, sans gêner les autres applications sur ce nœud. N'est-ce pas génial ?
Et bien que le cluster consommait relativement peu de CPU (8 %) et de RAM (40 %), nous rencontrions constamment des problèmes d'éviction des pods lorsqu'ils tentaient de demander plus de mémoire que ce qui était disponible sur le nœud. À ce moment-là, nous avions uniquement un tableau de bord pour surveiller les ressources Kubernetes. Voici à quoi cela ressemblait :
Tableau de bord Grafana avec des métriques cAdvisor
Avec ce tableau de bord, il n'est pas difficile de voir les nœuds qui consomment beaucoup de mémoire et de CPU. Le problème est de comprendre pourquoi. Pour que les pods restent en place, on aurait bien sûr pu configurer des ressources garanties sur tous les pods (les ressources demandées égales aux limites). Mais ce n'est pas la meilleure utilisation du matériel. Le cluster avait plusieurs centaines de gigas de mémoire, tandis que certains nœuds était en pénurie, avec seulement 4 à 10 Go de libre.
Il s'avère que le planificateur Kubernetes répartissait les charges de travail de manière inégale en fonction des ressources disponibles. Le planificateur Kubernetes prend en compte différentes configurations : règles d'affinité, taints et tolerations, sélecteurs de nœuds, qui peuvent limiter les nœuds disponibles. Mais dans mon cas, rien de tout cela n'existait, et les pods étaient planifiés en fonction des ressources demandées sur chaque nœud.
Pour chaque pod, un nœud était choisi en fonction des ressources libres et de la satisfaction des conditions de la demande. Cela a conduit à ce que les ressources demandées sur les nœuds ne correspondent pas à l'utilisation réelle, et c'est là que Kube Eagle et ses capacités de monitoring des ressources sont intervenus.
J'ai presque tous les clusters Kubernetes suivis seulement avec et . Node Exporter fournit des statistiques sur les entrées-sorties et l'utilisation du disque, du CPU et de la mémoire vive, tandis que Kube State Metrics affiche les métriques des objets Kubernetes, comme les demandes et les limites des ressources CPU et mémoire.
Nous devons combiner les métriques d'utilisation avec celles des demandes et des limites dans Grafana, et alors nous obtiendrons toutes les informations sur le problème. Cela semble simple, mais en réalité, dans ces deux outils, les étiquettes sont nommées différemment, et certaines métriques n'ont même pas d'étiquettes de métadonnées. Kube Eagle gère tout cela automatiquement et le tableau de bord ressemble à ceci :
Nous avons réussi à résoudre de nombreux problèmes de ressources et à économiser de l'équipement :
- Certains développeurs ne savaient pas combien de ressources les microservices nécessitaient (ou ne s'en souciaient tout simplement pas). Nous n'avions pas de moyen de détecter les demandes incorrectes en ressources - il faut connaître la consommation ainsi que les demandes et les limites. Maintenant, ils voient les métriques Prometheus, surveillent l'utilisation réelle et ajustent les demandes et les limites.
- Les applications JVM prennent autant de mémoire vive qu'elles peuvent. Le ramasse-miettes ne libère de la mémoire que si plus de 75 % est utilisé. Et comme la plupart des services utilisent de la mémoire burstable, le JVM l'occupait toujours. Par conséquent, tous ces services Java consommaient beaucoup plus de mémoire vive que prévu.
- Certaines applications demandaient trop de mémoire, et le planificateur Kubernetes ne donnait pas ces nœuds à d'autres applications, bien qu'en réalité, ils étaient moins occupés que d'autres nœuds. Un développeur a accidentellement ajouté un chiffre en trop à la demande et a pris une grande partie de la mémoire vive : 20 Go au lieu de 2. Personne ne l'a remarqué. L'application avait 3 répliques, donc 3 nœuds ont été impactés.
- Nous avons mis en place des restrictions sur les ressources, réorganisé les pods avec des demandes appropriées et obtenu un équilibre parfait dans l'utilisation du matériel sur tous les nœuds. Quelques nœuds pouvaient même être éteints. Puis nous avons découvert que nous avions des machines inappropriées (orientées CPU plutôt que mémoire). Nous avons changé de type et supprimé encore quelques nœuds.
Résultats
Avec des ressources burstable dans le cluster, vous utilisez plus efficacement le matériel disponible, mais le planificateur Kubernetes planifie les pods en fonction des demandes de ressources, ce qui peut poser des problèmes. Pour obtenir deux avantages : éviter les problèmes et utiliser les ressources au maximum, un bon monitoring est nécessaire. C'est pour cela qu'il sera utile. (exportateur Prometheus et tableau de bord Grafana).
Source : habr.com
