Overvåker ressurser i Kubernetes-klynger

Jeg har laget Kube Eagle – en Prometheus-eksportør. Det viste seg å være en flott løsning som hjelper til med å forstå ressursene i små og mellomstore klynger bedre. Resultatet er at jeg har spart flere hundre dollar fordi jeg har valgt de riktige maskintypene og tilpasset ressursbegrensningene for applikasjonene etter arbeidsbelastningen.

Jeg vil fortelle om fordelene Kube Eagle, men først vil jeg forklare hva som førte til problemene og hvorfor vi trengte en kvalitetsmonitorering.

Jeg har administrert flere klynger med 4–50 noder. I hver klynge er det opptil 200 mikroseriver og applikasjoner. For å bruke det tilgjengelige maskinvaren mer effektivt, ble de fleste distribusjoner konfigurert med burstable minne og CPU-ressurser. På denne måten kan podden ta tilgjengelige ressurser når det trengs, uten å forstyrre andre applikasjoner på denne noden. Er ikke det flott?

Og selv om klyngen forbrukte relativt lite CPU (8%) og minne (40%), oppstod det stadig problemer med å fordrive poddene når de prøvde å tildele mer minne enn det som var tilgjengelig på noden. Da hadde vi bare ett panel for overvåking av Kubernetes-ressurser. Slik så det ut:

Grafana-panel kun med cAdvisor-metrikker

Med et slikt panel er det ikke et problem å se noder som bruker mye minne og CPU. Problemet er å finne årsaken. For at poddene skulle bli værende på plass, kunne man selvfølgelig ha satt opp garanterte ressurser på alle poddene (forespurte ressurser er lik grensen). Men det er ikke den smarteste bruken av maskinvaren. Klyngen hadde flere hundre gigabyte minne, mens noen noder sultet og andre hadde 4–10 GB tilgjengelig.

Det viser seg at Kubernetes-planleggeren fordelte arbeidsbelastningene ujevnt basert på tilgjengelige ressurser. Kubernetes-planleggeren tar hensyn til forskjellige konfigurasjoner: affinity-regler, taints og tolereringer, nodeselektorer som kan begrense tilgjengelige noder. Men i mitt tilfelle var det ikke noe slikt, og poddene ble planlagt basert på de forespurte ressursene på hver node.

For en pod ble det valgt en node med flest tilgjengelige ressurser som oppfylte forespørselens betingelser. Det vi oppdaget var at de forespurte ressursene på nodene ikke samsvarte med det faktiske forbruket, og her kom Kube Eagle og dens overvåkingsmuligheter til unnsetning.

Nesten alle Kubernetes-klynger mine ble overvåket bare med Node exporter og Kube State Metrics. Node Exporter gir statistikk for inn- og utdata, diskbruk, CPU og minnebruk, mens Kube State Metrics viser metrikker for Kubernetes-objekter, som CPU- og minneforespørsel og begrensninger.

Vi trenger å kombinere bruksmetrikker med forespørsels- og begrensningsmetrikker i Grafana, så vi får all informasjon om problemet. Det høres enkelt ut, men i disse to verktøyene har etikettene forskjellige navn, og noen metrikker har ikke metadataetiketter i det hele tatt. Kube Eagle gjør alt dette selv, og panelet ser slik ut:

Kube Eagle-overvåkningspanelet

Vi har lykkes med å løse mange ressursproblemer og spare hardware:

1. Noen utviklere visste ikke hvor mye ressurser mikrotjenester trenger (eller brydde seg ikke). Vi hadde ingen måte å oppdage feilaktige ressursforespørsler på — for dette må man kjenne til forbruket pluss forespørslene og begrensningene. Nå ser de Prometheus-metrikker, overvåker det faktiske forbruket og justerer forespørslene og begrensningene.
2. JVM-applikasjoner bruker så mye minne som de kan. Søppelsamleren frigjør minne bare når mer enn 75% er i bruk. Og siden de fleste tjenester har burstable minne, ble det alltid opptatt av JVM. Derfor brukte alle disse Java-tjenestene mye mer minne enn forventet.
3. Noen applikasjoner ba om for mye minne, og Kubernetes-planleggeren ga ikke disse nodene til andre applikasjoner, selv om de faktisk var mer ledige enn andre noder. En utvikler la tilfeldig til et ekstra tall i forespørselen og tok en stor del av minnet: 20 GB i stedet for 2. Ingen la merke til det. Applikasjonen hadde 3 replikaer, så det påvirket faktisk 3 noder.
4. Vi innførte ressursbegrensninger, omplanla podene med riktige forespørselene og oppnådde perfekt balanse mellom bruken av maskinvare på alle nodene. Noen noder kunne faktisk stenges. Så vi oppdaget at vi hadde feil maskiner (rettet mot CPU, ikke minne). Vi byttet type og fjernet ytterligere noen noder.

Resultater

Med burstable ressurser i klyngen utnytter du det tilgjengelige utstyret mer effektivt, men Kubernetes-planleggeren planlegger podene basert på ressursforespørslene, noe som kan være problematisk. For å drepe to fluer i en smekk: unngå problemer og bruke ressursene optimalt, er god overvåking nødvendig. Dette vil være nyttig. Kube Eagle (exporter of Prometheus and Grafana monitoring panel).

Kilde: habr.com