Ich habe Kube Eagle erstellt – einen Prometheus-Exporter. Es stellte sich als eine coole Sache heraus, die dabei hilft, die Ressourcen kleiner und mittlerer Cluster besser zu verstehen. Am Ende habe ich Hunderte von Dollar gespart, weil ich die richtigen Maschinentypen ausgewählt und Anwendungsressourcengrenzen für Arbeitslasten konfiguriert habe.
Ich erzähle Ihnen von den Vorteilen , aber zuerst erkläre ich, was die Aufregung verursacht hat und warum eine qualitativ hochwertige Überwachung erforderlich war.
Ich habe mehrere Cluster mit 4–50 Knoten verwaltet. Jeder Cluster enthält bis zu 200 Microservices und Anwendungen. Um die vorhandene Hardware besser zu nutzen, wurden die meisten Bereitstellungen mit Burst-RAM- und CPU-Ressourcen konfiguriert. Auf diese Weise können Pods bei Bedarf verfügbare Ressourcen beanspruchen und beeinträchtigen gleichzeitig nicht andere Anwendungen auf diesem Knoten. Nun, ist es nicht großartig?
Und obwohl der Cluster relativ wenig CPU (8 %) und RAM (40 %) verbrauchte, hatten wir ständig Probleme mit Pods, die vorbelegt wurden, wenn sie versuchten, mehr Speicher zuzuweisen, als auf dem Knoten verfügbar war. Damals hatten wir nur ein Dashboard zur Überwachung von Kubernetes-Ressourcen. So was:
Grafana-Dashboard nur mit cAdvisor-Metriken
Mit einem solchen Panel ist es kein Problem, Knoten zu erkennen, die viel Speicher und CPU verbrauchen. Das Problem besteht darin, herauszufinden, was der Grund ist. Um die Pods an Ort und Stelle zu halten, könnte man natürlich auf allen Pods garantierte Ressourcen einrichten (angefragte Ressourcen entsprechen dem Limit). Dies ist jedoch nicht der intelligenteste Einsatz von Hardware. Der Cluster verfügte über mehrere hundert Gigabyte Speicher, während einige Knoten hungerten, während andere noch 4–10 GB in Reserve hatten.
Es stellte sich heraus, dass der Kubernetes-Scheduler die Arbeitslasten ungleichmäßig auf die verfügbaren Ressourcen verteilte. Der Kubernetes-Scheduler berücksichtigt verschiedene Konfigurationen: Affinitäts-, Taints- und Toleranzregeln, Knotenselektoren, die die verfügbaren Knoten einschränken können. Aber in meinem Fall gab es nichts dergleichen und die Pods wurden abhängig von den angeforderten Ressourcen auf jedem Knoten geplant.
Für den Pod wurde der Knoten ausgewählt, der über die meisten freien Ressourcen verfügt und die Anforderungsbedingungen erfüllt. Wir haben festgestellt, dass die angeforderten Ressourcen auf den Knoten nicht mit der tatsächlichen Nutzung übereinstimmten, und hier kamen Kube Eagle und seine Ressourcenüberwachungsfunktionen zur Rettung.
Ich habe fast alle Kubernetes-Cluster nur mit überwacht и . Node Exporter bietet Statistiken zur E/A- und Festplatten-, CPU- und RAM-Nutzung, während Kube State Metrics Kubernetes-Objektmetriken wie Anfragen sowie CPU- und Speicherressourcengrenzen anzeigt.
Wir müssen die Nutzungsmetriken mit den Anforderungs- und Limitmetriken in Grafana kombinieren und erhalten dann alle Informationen über das Problem. Das klingt einfach, aber die beiden Tools benennen die Labels tatsächlich unterschiedlich und einige Metriken haben überhaupt keine Metadatenlabels. Kube Eagle macht alles selbst und das Panel sieht so aus:
Es ist uns gelungen, viele Probleme mit Ressourcen zu lösen und Geräte einzusparen:
- Einige Entwickler wussten nicht, wie viele Ressourcen Microservices benötigten (oder machten sich einfach nicht die Mühe). Es gab für uns keine Möglichkeit, falsche Ressourcenanfragen zu finden – dafür müssen wir den Verbrauch sowie Anfragen und Limits kennen. Jetzt sehen sie Prometheus-Metriken, überwachen die tatsächliche Nutzung und passen Anforderungen und Limits an.
- JVM-Anwendungen benötigen so viel RAM, wie sie verarbeiten können. Der Garbage Collector gibt Speicher erst dann frei, wenn mehr als 75 % genutzt werden. Und da die meisten Dienste über Burst-Speicher verfügen, war dieser immer von der JVM belegt. Daher verbrauchten alle diese Java-Dienste viel mehr RAM als erwartet.
- Einige Anwendungen forderten zu viel Speicher und der Kubernetes-Scheduler gab diese Knoten nicht an andere Anwendungen weiter, obwohl sie tatsächlich freier waren als andere Knoten. Ein Entwickler fügte der Anfrage versehentlich eine zusätzliche Ziffer hinzu und schnappte sich einen großen Teil des RAM: 20 GB statt 2. Niemand bemerkte es. Die Anwendung verfügte über drei Replikate, sodass bis zu drei Knoten betroffen waren.
- Wir haben Ressourcenlimits eingeführt, Pods mit den richtigen Anforderungen neu geplant und eine ideale Balance der Hardwarenutzung über alle Knoten hinweg erreicht. Ein paar Knoten hätten ganz geschlossen werden können. Und dann sahen wir, dass wir die falschen Maschinen hatten (CPU-orientiert, nicht speicherorientiert). Wir haben den Typ geändert und mehrere weitere Knoten gelöscht.
Ergebnisse
Mit Burst-Ressourcen im Cluster nutzen Sie die verfügbare Hardware effizienter, aber der Kubernetes-Scheduler plant Pods basierend auf Ressourcenanforderungen, was problematisch ist. Zwei Fliegen mit einer Klappe schlagen: Um Probleme zu vermeiden und Ressourcen optimal zu nutzen, braucht es eine gute Überwachung. Deshalb wird es nützlich sein (Prometheus-Exporter und Grafana-Dashboard).
Source: habr.com