Ik heb Kube Eagle gemaakt - een Prometheus-exporteur. Het bleek een geweldige tool te zijn die helpt om better inzicht te krijgen in de middelen van kleine en middelgrote clusters. Uiteindelijk heb ik honderden dollars bespaard omdat ik de juiste typen machines selecteerde en de resourcebeperkingen van applicaties aanpaste aan de werklasten.
Ik zal de voordelen uitleggen , maar eerst leg ik uit waarom er problemen ontstonden en waarom een goede monitoring nodig was.
Ik beheerde verschillende clusters van 4-50 nodes. In elk cluster zaten tot 200 microservices en applicaties. Om de beschikbare hardware beter te benutten, waren de meeste deployments ingesteld met burstable RAM en CPU-resources. Zo kunnen pods beschikbare middelen gebruiken wanneer nodig zonder andere applicaties op die node te storen. Is dat niet geweldig?
En hoewel de cluster relatief weinig CPU (8%) en RAM (40%) verbruikte, hadden we regelmatig problemen met het uitplaatsen van pods wanneer ze meer geheugen probeerden te reserveren dan er op de node beschikbaar was. We hadden toen maar Ć©Ć©n dashboard voor de monitoring van Kubernetes-resources. Zo eentje:
Grafana-dashboard alleen met metrics van cAdvisor
Met zo'n dashboard is het geen probleem om nodes te zien die veel geheugen en CPU verbruiken. Het probleem is om te begrijpen waarom. Om ervoor te zorgen dat de pods op hun plek bleven, kon ik natuurlijk gegarandeerde resources op alle pods instellen (de aangevraagde resources gelijk aan de limiet). Maar dat is niet de slimste manier om de hardware te gebruiken. In de cluster waren er honderden gigabytes aan geheugen, terwijl sommige nodes hongerig waren en andere nog 4-10 GB over hadden.
Het lijkt erop dat de Kubernetes-scheduler de werklasten niet gelijkmatig over de beschikbare resources verdeelde. De Kubernetes-scheduler houdt rekening met verschillende configuraties: affinity-regels, taints en tolerations, node-selectors die de beschikbare nodes kunnen beperken. Maar in mijn geval was er niets van dat, en werden de pods gepland afhankelijk van de aangevraagde resources op elke node.
Voor een pod werd een node geselecteerd die de meeste vrije resources had en aan de eisen van de aanvraag voldeed. Het resultaat was dat de aangevraagde resources op de nodes niet overeenkwamen met het daadwerkelijke gebruik, en hier kwam Kube Eagle en zijn monitoringmogelijkheden van pas.
Bijna al mijn Kubernetes-clusters werden alleen gevolgd met en . Node Exporter geeft statistieken over input-output en het gebruik van schijf, CPU en RAM, terwijl Kube State Metrics de statistieken van Kubernetes-objecten toont, zoals aanvragen en limieten voor CPU- en geheugengebruik.
We moeten het gebruiksmetrics combineren met de aanvraag- en limietenmetrics in Grafana, en dan krijgen we alle informatie over het probleem. Het klinkt eenvoudig, maar in deze twee tools worden labels op verschillende manieren genoemd, en sommige metrics hebben helemaal geen metadata-labels. Kube Eagle doet alles automatisch en het dashboard ziet er zo uit:
We hebben veel problemen met middelen opgelost en hardware bespaard:
- Sommige ontwikkelaars wisten niet hoeveel middelen microservices nodig hadden (of maakten zich er gewoon geen zorgen over). We hadden geen manier om onjuiste resource-aanvragen te detecteren - daarvoor moet je het verbruik plus aanvragen en limieten kennen. Nu kunnen ze de Prometheus-metrics bekijken, de werkelijke gebruiksvoering monitoren en hun aanvragen en limieten aanpassen.
- JVM-applicaties gebruiken zoveel RAM als ze kunnen. De garbage collector vrijmaakt geheugen alleen als meer dan 75% in gebruik is. Aangezien de meeste diensten burstable geheugen hebben, werd het altijd ingenomen door de JVM. Daarom verbruikten al deze Java-diensten veel meer RAM dan verwacht.
- Sommige applicaties vroegen te veel geheugen aan, en de Kubernetes-scheduler gaf deze nodes niet vrij aan andere applicaties, ook al waren ze feitelijk vrijer dan de andere nodes. Een ontwikkelaar voegde per ongeluk een extra cijfer toe aan de aanvraag en nam een groot deel van het RAM in beslag: 20 GB in plaats van 2. Niemand merkte het. De applicatie had 3 replicas, dus 3 nodes waren aangedaan.
- We hebben beperkingen op middelen ingesteld, de pods opnieuw gepland met de juiste aanvragen en kregen een perfecte balans in het gebruik van hardware op alle nodes. Een paar nodes konden zelfs worden afgesloten. En toen zagen we dat we de verkeerde machines had (gericht op CPU, niet op geheugen). We wijzigden het type en verwijderden nog een paar nodes.
Conclusies
Met burstable middelen in de cluster gebruik je de beschikbare hardware efficiƫnter, maar de Kubernetes-scheduler plant de pods op basis van de resource-aanvragen, wat risico's met zich meebrengt. Om twee vliegen in ƩƩn klap te slaan: zowel problemen te vermijden als middelen optimaal te gebruiken, is goed monitoren noodzakelijk. Dat is waar dit van pas komt. (exporteur van Prometheus en het Grafana-dashboard).
Bron: habr.com
