Jeg har skabt Kube Eagle – en Prometheus-udbyder. Det viste sig at være et fantastisk værktøj, der hjælper med at få et bedre overblik over ressourcerne i små og mellemstore klynger. I sidste ende har jeg sparet mange penge, fordi jeg kunne vælge de rigtige maskintyper og justere ressourcegrænserne for applikationer i forhold til arbejdsbelastningen.
Jeg vil fortælle om fordelene ved , men først vil jeg forklare, hvad der ledte til forvirringen, og hvorfor der var brug for en kvalitetsmonitorering.
Jeg har administreret flere klynger med 4-50 noder. Hver klynge har op til 200 mikrotjenester og applikationer. For at udnytte det eksisterende hardware bedre var de fleste deployment konfigureret med burstandart RAM og CPU-ressourcer. På den måde kan pods tage de tilgængelige ressourcer, når det er nødvendigt, uden at forstyrre de andre applikationer på den samme node. Er det ikke fantastisk?
Og selvom klyngen kun brugte relativt lidt CPU (8%) og RAM (40%), havde vi hele tiden problemer med at udsætte pods, når de forsøgte at allokere mere hukommelse, end der var tilgængeligt på noden. Vi havde så kun et enkelt dashboard til overvågning af Kubernetes-ressourcer. Sådan her:
Grafana-dashboard kun med cAdvisor-metrics
Med et sådant dashboard er det ikke et problem at se noder, der bruger meget RAM og CPU. Problemet er at finde ud af, hvad årsagen er. For at sikre, at pods forbliver aktive, kunne man selvfølgelig have konfigureret garanterede ressourcer for alle pods (anmodede ressourcer er lig med grænsen). Men det er ikke den mest intelligente anvendelse af hardware. Klyngen havde flere hundrede gigabyte hukommelse, mens nogle noder led, mens andre havde 4-10 GB til overs.
Det viser sig, at Kubernetes-planlæggeren fordelte arbejdsbelastningerne uensartet på de tilgængelige ressourcer. Kubernetes-planlæggeren tager forskellige konfigurationer i betragtning: affinity-regler, taints og tolerations, node-selektorer, som kan begrænse de tilgængelige noder. Men i mit tilfælde var der ikke noget af det, og pods blev planlagt i forhold til de anmodede ressourcer på hver node.
For hvert pod blev der valgt en node med flest ledige ressourcer, som opfyldte anmodningskriterierne. Det viste sig, at de anmodede ressourcer på noderne ikke svarede til det faktiske forbrug, og her kom Kube Eagle og dets ressourceovervågningsmuligheder til hjælp.
Jeg har næsten alle Kubernetes-klynger overvåget kun med og . Node Exporter giver statistik om input-output og brug af disk, CPU og RAM, mens Kube State Metrics viser metrics for Kubernetes-objekter som fx anmodninger og grænser for CPU- og hukommelsesressourcer.
Vi skal kombinere brugsmetrics med anmodnings- og grænsmetrics i Grafana, og så får vi al information om problemet. Det lyder simpelt, men i disse to værktøjer kaldes labels forskelligt, og nogle metrics har slet ikke metadata labels. Kube Eagle klarer det hele selv, og panelet ser sådan ud:
Vi har været i stand til at løse mange ressourcemæssige problemer og spare på udstyret:
- Nogle udviklere vidste ikke, hvor mange ressourcer der var behov for hos mikrotjenesterne (eller gad bare ikke tænke over det). Vi havde ikke værktøjerne til at finde forkerte ressourceanmodninger — for det kræver, at man kender forbrug plus anmodninger og grænser. Nu kan de se Prometheus-metrics, overvåge det faktiske forbrug og justere anmodningerne og grænserne.
- JVM-applikationer tager så meget RAM, som de kan bære. Garbage collector frigiver hukommelse, kun hvis mere end 75% anvendes. Og da de fleste tjenester har burstable hukommelse, tog JVM altid den plads. Derfor brugte alle disse Java-tjenester meget mere RAM end forventet.
- Nogle applikationer anmodede om for meget hukommelse, og Kubernetes-planlæggeren gav ikke disse noder til de andre applikationer, selvom de faktisk var mindre belastede end andre noder. En udvikler tilføjede ved et uheld et ekstra ciffer i anmodningen og beslaglagde en stor del hukommelse: 20 GB i stedet for 2. Ingen lagde mærke til det. Applikationen havde 3 replikaer, så 3 noder var ramt.
- Vi indførte ressourcestramme, omplanlagde pods med de rigtige anmodninger og opnåede en perfekt balance i ressourceudnyttelsen på tværs af alle noder. Et par noder kunne faktisk lukkes ned. Og så så vi, at vi havde de forkerte maskiner (orienteret mod CPU, ikke hukommelse). Vi ændrede type og fjernede yderligere et par noder.
Resumé
Med burstable ressourcer i klyngen bruger du dit hardware mere effektivt, men Kubernetes-planlæggeren planlægger pods baseret på ressourceanmodninger, hvilket kan være problematisk. For at dræbe to fluer med ét smæk: undgå problemer og udnytte ressourcerne fuldt ud — er der brug for en god overvågning. Det er her, [eksportør Prometheus og panel overvågning Grafana] kommer ind i billedet. (exportør Prometheus og panel overvågning Grafana).
Kilde: habr.com
