Jag skapade Kube Eagle - en Prometheus-exportör. Det visade sig vara en cool grej som hjälper till att bättre förstå resurserna i små och medelstora kluster. Till slut sparade jag hundratals dollar eftersom jag valde rätt maskintyper och konfigurerade applikationsresursgränser för arbetsbelastningar.
Jag ska berätta om fördelarna , men först ska jag förklara vad som orsakade uppståndelsen och varför övervakning av hög kvalitet behövdes.
Jag hanterade flera kluster med 4–50 noder. Varje kluster innehåller upp till 200 mikrotjänster och applikationer. För att bättre utnyttja befintlig hårdvara konfigurerades de flesta distributioner med burstable RAM- och CPU-resurser. På så sätt kan pods ta tillgängliga resurser om det behövs, och samtidigt inte störa andra applikationer på denna nod. Tja, är det inte bra?
Och även om klustret förbrukade relativt lite CPU (8 %) och RAM (40 %), hade vi ständigt problem med att pods blev förebyggda när de försökte allokera mer minne än vad som var tillgängligt på noden. Då hade vi bara en instrumentpanel för att övervaka Kubernetes-resurser. Så här:
Grafana instrumentpanel med endast cAdvisor-statistik
Med en sådan panel är det inga problem att se noder som äter mycket minne och CPU. Problemet är att ta reda på vad orsaken är. För att hålla poddarna på plats skulle man givetvis kunna sätta upp garanterade resurser på alla poddar (begärda resurser lika med gränsen). Men detta är inte den smartaste användningen av hårdvara. Klustret hade flera hundra gigabyte minne, medan vissa noder svalt, medan andra hade 4–10 GB kvar i reserv.
Det visar sig att Kubernetes-schemaläggaren fördelade arbetsbelastningar ojämnt över tillgängliga resurser. Kubernetes-schemaläggaren tar hänsyn till olika konfigurationer: regler för affinitet, fläckar och tolerationer, nodväljare som kan begränsa de tillgängliga noderna. Men i mitt fall fanns det inget liknande, och poddarna planerades beroende på de begärda resurserna på varje nod.
Den nod som har flest lediga resurser och som uppfyller förfrågningsvillkoren valdes för podden. Vi fann att de begärda resurserna på noderna inte matchade den faktiska användningen, och det var här Kube Eagle och dess resursövervakningsfunktioner kom till undsättning.
Jag har nästan alla Kubernetes-kluster endast övervakade med и . Node Exporter tillhandahåller statistik om I/O och disk, CPU och RAM-användning, medan Kube State Metrics visar Kubernetes-objektmått såsom förfrågningar och CPU- och minnesresursgränser.
Vi måste kombinera användningsmåtten med förfrågningar och gränsvärden i Grafana, och sedan får vi all information om problemet. Detta låter enkelt, men de två verktygen namnger etiketterna på olika sätt, och vissa mätvärden har inga metadataetiketter alls. Kube Eagle gör allt själv och panelen ser ut så här:
Vi lyckades lösa många problem med resurser och spara utrustning:
- Vissa utvecklare visste inte hur många resurser mikrotjänster behövde (eller brydde sig helt enkelt inte). Det fanns inget sätt för oss att hitta felaktiga förfrågningar om resurser - för detta behöver vi veta konsumtion plus förfrågningar och gränser. Nu ser de Prometheus-mått, övervakar faktisk användning och justerar förfrågningar och gränser.
- JVM-applikationer tar så mycket RAM som de kan hantera. Sophämtaren släpper minne endast när mer än 75 % används. Och eftersom de flesta tjänster har burstable minne, var det alltid ockuperat av JVM. Därför åt alla dessa Java-tjänster upp mycket mer RAM än väntat.
- Vissa applikationer begärde för mycket minne, och Kubernetes-schemaläggaren gav inte dessa noder till andra applikationer, även om de i själva verket var friare än andra noder. En utvecklare lade av misstag till en extra siffra i begäran och tog en stor bit RAM: 20 GB istället för 2. Ingen märkte det. Applikationen hade 3 repliker, så så många som 3 noder påverkades.
- Vi introducerade resursbegränsningar, omplanerade pods med rätt förfrågningar och fick en idealisk balans mellan hårdvaruanvändning över alla noder. Ett par noder kunde ha stängts helt och hållet. Och så såg vi att vi hade fel maskiner (CPU-orienterade, inte minnesorienterade). Vi ändrade typen och tog bort flera noder till.
Resultat av
Med sprängbara resurser i klustret använder du den tillgängliga hårdvaran mer effektivt, men Kubernetes schemaläggare schemalägger poddar baserat på förfrågningar om resurser, och det är fullt ut. För att slå två flugor i en smäll: för att undvika problem och för att utnyttja resurserna fullt ut behöver du bra övervakning. Det är därför det kommer att vara användbart (Prometheus exportör och Grafana instrumentpanel).
Källa: will.com