Ich habe Kube Eagle erstellt – einen Prometheus-Exporter. Es stellte sich als hervorragendes Tool heraus, das hilft, die Ressourcen kleiner und mittlerer Cluster besser zu verstehen. Letztendlich habe ich mehrere Hundert Euro gespart, da ich die richtigen Maschinentypen auswählte und die Ressourcenbeschränkungen der Anwendungen an die Arbeitslasten anpasste.
Ich werde über die Vorteile von berichten, aber zuerst erkläre ich, was das Problem ist und warum wir qualitativ hochwertige Überwachung benötigten.
Ich verwaltete mehrere Cluster mit 4–50 Knoten. In jedem Cluster befanden sich bis zu 200 Mikrodienste und Anwendungen. Um die vorhandene Hardware effizienter zu nutzen, waren die meisten Deployments mit burstable RAM und CPU-Ressourcen konfiguriert. So können Pods die verfügbaren Ressourcen nutzen, wenn es nötig ist, und stören dabei nicht andere Anwendungen auf diesem Knoten. Ist das nicht großartig?
Und obwohl der Cluster relativ wenig CPU (8 %) und Arbeitsspeicher (40 %) verbrauchte, hatten wir ständig Probleme mit der Verdrängung von Pods, wenn diese versuchten, mehr Speicher anzufordern, als auf dem Knoten verfügbar war. Zu diesem Zeitpunkt hatten wir nur ein Dashboard zur Überwachung der Kubernetes-Ressourcen. So sah es aus:
Grafana-Dashboard nur mit cAdvisor-Metriken
Mit einem solchen Dashboard ist es kein Problem, Knoten zu sehen, die viel Speicher und CPU verbrauchen. Das Problem besteht darin, herauszufinden, warum das so ist. Um die Pods stabil zu halten, könnte man natürlich garantierte Ressourcen für alle Pods einrichten (angeforderte Ressourcen entsprechen dem Limit). Aber das ist nicht die intelligenteste Nutzung der Hardware. Im Cluster standen mehrere Hundert Gigabyte Speicher zur Verfügung, dennoch litten einige Knoten unter Ressourcenmangel, während andere noch 4 bis 10 GB übrig hatten.
Es stellte sich heraus, dass der Kubernetes-Planer die Arbeitslasten ungleichmäßig auf die verfügbaren Ressourcen verteilte. Der Kubernetes-Planer berücksichtigt verschiedene Konfigurationen: Affinitätsregeln, Taints und Tolerierungen sowie Knotenselektoren, die die verfügbaren Knoten einschränken können. In meinem Fall gab es jedoch nichts dergleichen, und die Pods wurden basierend auf den angeforderten Ressourcen auf jedem Knoten geplant.
Für den Pod wurde ein Knoten ausgewählt, der die meisten freien Ressourcen hatte und die Anforderungen erfüllte. Wir stellten fest, dass die angeforderten Ressourcen auf den Knoten nicht mit der tatsächlichen Nutzung übereinstimmten, und hier kam Kube Eagle mit seinen Ressourcenüberwachungsmöglichkeiten ins Spiel.
Ich habe fast alle Kubernetes-Cluster nur mit und . Node Exporter liefert Statistiken zu Ein- und Ausgabe sowie zur Nutzung von Disk, CPU und RAM, während Kube State Metrics Kennzahlen von Kubernetes-Objekten wie CPU- und RAM-Anforderungs- und Limits anzeigt.
Wir müssen die Nutzungsmetrik mit den Anforderungs- und Limitmetrik in Grafana kombinieren, um alle Informationen über das Problem zu erhalten. Das klingt einfach, aber in diesen beiden Tools werden die Labels unterschiedlich benannt, und einige Metriken haben überhaupt keine Metadatenlabels. Kube Eagle erledigt alles automatisch, und das Dashboard sieht so aus:
Wir konnten viele Ressourcenprobleme lösen und Hardware einsparen:
- Einige Entwickler wussten nicht, wie viele Ressourcen Microservices benötigen (oder haben sich einfach nicht darum gekümmert). Wir hatten keine Möglichkeit, falsche Ressourcenanforderungen zu identifizieren – dafür mussten wir den Verbrauch sowie die Anforderungen und Limits kennen. Jetzt sehen sie die Prometheus-Metriken, überwachen die tatsächliche Nutzung und passen die Anforderungen und Limits an.
- JVM-Anwendungen verwenden so viel Arbeitsspeicher, wie sie benötigen. Der Garbage Collector gibt Speicher nur dann frei, wenn mehr als 75 % belegt sind. Da der Speicher bei den meisten Diensten burstable ist, wurde er immer vom JVM belegt. Daher haben all diese Java-Dienste deutlich mehr Arbeitsspeicher verbraucht als erwartet.
- Einige Anwendungen haben zu viel Speicher angefordert, und der Kubernetes-Planer hat diesen Knoten anderen Anwendungen nicht zugewiesen, obwohl sie faktisch weniger ausgelastet waren als andere Knoten. Ein Entwickler hatte versehentlich eine zusätzliche Ziffer in der Anfrage hinzugefügt und einen großen Teil des Arbeitsspeichers belegt: 20 GB statt 2. Niemand hat es bemerkt. Die Anwendung hatte 3 Replikate, sodass gleich 3 Knoten betroffen waren.
- Wir haben Ressourcenbeschränkungen eingeführt, die Pods mit den richtigen Anfragen neu geplant und somit eine optimale Balance bei der Hardwareauslastung über alle Knoten erzielt. Einige Knoten hätten sogar stillgelegt werden können. Dann stellten wir fest, dass wir die falschen Maschinen hatten (auf CPU und nicht auf Speicher optimiert). Wir haben den Typ gewechselt und noch mehrere Knoten entfernt.
Ergebnisse
Mit burstbaren Ressourcen im Cluster nutzen Sie die vorhandene Hardware effizienter, doch der Kubernetes-Planer stagniert bei den Anfragen zu den Ressourcen, was problematisch sein kann. Um sowohl Probleme zu vermeiden als auch die Ressourcen optimal zu nutzen, benötigen Sie eine gute Überwachung. Hierfür ist (Prometheus-Exporter und Grafana-Dashboard) nützlich.
Quelle: habr.com
