Ik heb Kube Eagle gemaakt - een Prometheus-exporteur. Het bleek iets cools te zijn dat helpt om de hulpbronnen van kleine en middelgrote clusters beter te begrijpen. Uiteindelijk heb ik honderden dollars bespaard omdat ik de juiste machinetypen had geselecteerd en de limieten voor applicatieresources voor workloads had geconfigureerd.
Ik zal je vertellen over de voordelen , maar eerst zal ik uitleggen wat de ophef veroorzaakte en waarom hoogwaardige monitoring nodig was.
Ik beheerde verschillende clusters van 4 tot 50 knooppunten. Elk cluster bevat maximaal 200 microservices en applicaties. Om de bestaande hardware beter te kunnen gebruiken, werden de meeste implementaties geconfigureerd met burstable RAM- en CPU-bronnen. Op deze manier kunnen pods indien nodig beschikbare bronnen overnemen en tegelijkertijd andere applicaties op dit knooppunt niet hinderen. Nou, is het niet geweldig?
En hoewel het cluster relatief weinig CPU (8%) en RAM (40%) verbruikte, hadden we voortdurend problemen met het overnemen van pods wanneer ze probeerden meer geheugen toe te wijzen dan beschikbaar was op het knooppunt. Destijds hadden we slechts één dashboard voor het monitoren van Kubernetes-bronnen. Soortgelijk:
Grafana-dashboard met alleen cAdvisor-statistieken
Met zo’n paneel is het geen probleem om knooppunten te zien die veel geheugen en CPU in beslag nemen. Het probleem is om erachter te komen wat de reden is. Om de pods op hun plaats te houden, zou je natuurlijk gegarandeerde grondstoffen op alle pods kunnen instellen (aangevraagde grondstoffen gelijk aan de limiet). Maar dit is niet het slimste gebruik van hardware. Het cluster beschikte over enkele honderden gigabytes aan geheugen, terwijl sommige knooppunten honger leden, terwijl andere nog 4 tot 10 GB in reserve hadden.
Het blijkt dat de Kubernetes-planner de werklast ongelijkmatig verdeelde over de beschikbare bronnen. De Kubernetes-planner houdt rekening met verschillende configuraties: affiniteits-, taints- en tolerantieregels, knooppuntselectors die de beschikbare knooppunten kunnen beperken. Maar in mijn geval bestond zoiets niet en werden de pods gepland afhankelijk van de gevraagde bronnen op elk knooppunt.
Het knooppunt met de meeste vrije bronnen en dat voldoet aan de aanvraagvoorwaarden is geselecteerd voor de pod. We ontdekten dat de gevraagde bronnen op de knooppunten niet overeenkwamen met het daadwerkelijke gebruik, en dit is waar Kube Eagle en zijn mogelijkheden voor het monitoren van bronnen te hulp kwamen.
Ik heb bijna alle Kubernetes-clusters alleen gemonitord и . Node Exporter biedt statistieken over I/O- en schijf-, CPU- en RAM-gebruik, terwijl Kube State Metrics Kubernetes-objectstatistieken toont, zoals verzoeken en CPU- en geheugenresourcelimieten.
We moeten de gebruiksstatistieken combineren met de verzoeken en limietstatistieken in Grafana, en dan krijgen we alle informatie over het probleem. Dit klinkt eenvoudig, maar de twee tools benoemen de labels eigenlijk anders, en sommige statistieken hebben helemaal geen metadatalabels. Kube Eagle doet alles zelf en het paneel ziet er als volgt uit:
We zijn erin geslaagd veel problemen met middelen op te lossen en apparatuur te besparen:
- Sommige ontwikkelaars wisten niet hoeveel bronnen microservices nodig hadden (of deden er gewoon geen moeite mee). Er was geen manier voor ons om onjuiste verzoeken om bronnen te vinden - hiervoor moeten we het verbruik plus verzoeken en limieten kennen. Nu zien ze Prometheus-statistieken, monitoren ze het daadwerkelijke gebruik en passen ze verzoeken en limieten aan.
- JVM-applicaties gebruiken zoveel RAM als ze aankunnen. De garbage collector geeft alleen geheugen vrij als meer dan 75% wordt gebruikt. En aangezien de meeste services burstable-geheugen hebben, werd dit altijd bezet door de JVM. Daarom verbruikten al deze Java-services veel meer RAM dan verwacht.
- Sommige applicaties vroegen te veel geheugen, en de Kubernetes-planner gaf deze knooppunten niet aan andere applicaties, ook al waren ze in feite vrijer dan andere knooppunten. Eén ontwikkelaar voegde per ongeluk een extra cijfer toe aan het verzoek en pakte een groot stuk RAM: 20 GB in plaats van 2. Niemand merkte het. De applicatie had 3 replica's, dus maar liefst 3 knooppunten werden getroffen.
- We hebben resourcelimieten geïntroduceerd, pods opnieuw gepland met de juiste verzoeken en een ideale balans bereikt tussen hardwaregebruik op alle knooppunten. Een paar knooppunten hadden helemaal gesloten kunnen zijn. En toen zagen we dat we de verkeerde machines hadden (CPU-georiënteerd, niet geheugen-georiënteerd). We hebben het type gewijzigd en nog een aantal knooppunten verwijderd.
Resultaten van
Met burstable resources in het cluster maak je efficiënter gebruik van de beschikbare hardware, maar de Kubernetes-planner plant pods op basis van verzoeken om resources, en dat is lastig. Om twee vliegen in één klap te slaan: om problemen te voorkomen en middelen optimaal te benutten, heb je goede monitoring nodig. Daarom zal het nuttig zijn (Prometheus-exporteur en Grafana-dashboard).
Bron: www.habr.com
