Jeg opprettet Kube Eagle - en Prometheus-eksportør. Det viste seg å være en kul ting som bidrar til å bedre forstå ressursene til små og mellomstore klynger. Til slutt sparte jeg hundrevis av dollar fordi jeg valgte de riktige maskintypene og konfigurerte applikasjonsressursgrenser for arbeidsbelastninger.
Jeg skal fortelle deg om fordelene , men først skal jeg forklare hva som forårsaket oppstyret og hvorfor overvåking av høy kvalitet var nødvendig.
Jeg klarte flere klynger med 4–50 noder. Hver klynge inneholder opptil 200 mikrotjenester og applikasjoner. For å gjøre bedre bruk av eksisterende maskinvare, ble de fleste distribusjoner konfigurert med burstable RAM og CPU-ressurser. På denne måten kan pods ta tilgjengelige ressurser om nødvendig, og samtidig ikke forstyrre andre applikasjoner på denne noden. Vel, er det ikke flott?
Og selv om klyngen forbrukte relativt lite CPU (8 %) og RAM (40 %), hadde vi stadig problemer med at pods ble forhindret når de prøvde å allokere mer minne enn det som var tilgjengelig på noden. Den gang hadde vi bare ett dashbord for å overvåke Kubernetes-ressurser. Som dette:
Grafana dashbord med kun cAdvisor-beregninger
Med et slikt panel er det ikke noe problem å se noder som spiser mye minne og CPU. Problemet er å finne ut hva årsaken er. For å holde podene på plass kunne man selvsagt sette opp garanterte ressurser på alle pods (etterspurte ressurser lik grensen). Men dette er ikke den smarteste bruken av maskinvare. Klyngen hadde flere hundre gigabyte med minne, mens noen noder sultet, mens andre hadde 4–10 GB igjen i reserve.
Det viser seg at Kubernetes-planleggeren fordelte arbeidsbelastninger ujevnt over tilgjengelige ressurser. Kubernetes-planleggeren tar hensyn til ulike konfigurasjoner: affinitets-, flekker- og toleranseregler, nodevelgere som kan begrense tilgjengelige noder. Men i mitt tilfelle var det ingenting slikt, og podene ble planlagt avhengig av de forespurte ressursene på hver node.
Noden som har flest ledige ressurser og som tilfredsstiller forespørselsbetingelsene, ble valgt for poden. Vi fant ut at de forespurte ressursene på nodene ikke stemte overens med den faktiske bruken, og det var her Kube Eagle og ressursovervåkingsmulighetene kom til unnsetning.
Jeg har nesten alle Kubernetes-klynger overvåket kun med и . Node Exporter gir statistikk om I/O og disk-, CPU- og RAM-bruk, mens Kube State Metrics viser Kubernetes-objektmålinger som forespørsler og CPU- og minneressursgrenser.
Vi må kombinere bruksmålene med forespørsler og grenseverdier i Grafana, og så får vi all informasjon om problemet. Dette høres enkelt ut, men de to verktøyene navngir faktisk etikettene annerledes, og noen beregninger har ingen metadataetiketter i det hele tatt. Kube Eagle gjør alt selv og panelet ser slik ut:
Vi klarte å løse mange problemer med ressurser og spare utstyr:
- Noen utviklere visste ikke hvor mange ressurser mikrotjenester trengte (eller gadd rett og slett ikke). Det var ingen måte for oss å finne feil forespørsler om ressurser - for dette trenger vi å vite forbruk pluss forespørsler og grenser. Nå ser de Prometheus-beregninger, overvåker faktisk bruk og justerer forespørsler og grenser.
- JVM-applikasjoner tar så mye RAM som de kan håndtere. Søppelsamleren frigjør minne kun når mer enn 75 % brukes. Og siden de fleste tjenester har burstable minne, var det alltid okkupert av JVM. Derfor spiste alle disse Java-tjenestene opp mye mer RAM enn forventet.
- Noen applikasjoner ba om for mye minne, og Kubernetes-planleggeren ga ikke disse nodene til andre applikasjoner, selv om de faktisk var friere enn andre noder. En utvikler la ved et uhell til et ekstra siffer i forespørselen og tok et stort stykke RAM: 20 GB i stedet for 2. Ingen la merke til det. Applikasjonen hadde 3 replikaer, så så mange som 3 noder ble berørt.
- Vi introduserte ressursgrenser, endret pods med de riktige forespørslene, og fikk en ideell balanse mellom maskinvarebruk på tvers av alle noder. Et par noder kunne vært stengt helt. Og så så vi at vi hadde feil maskiner (CPU-orientert, ikke minneorientert). Vi endret typen og slettet flere noder.
Resultater av
Med burstable ressurser i klyngen bruker du den tilgjengelige maskinvaren mer effektivt, men Kubernetes-planleggeren planlegger pods basert på forespørsler om ressurser, og dette er fullt. For å slå to fluer i en smekk: For å unngå problemer og bruke ressursene til det fulle, trenger du god overvåking. Det er derfor det vil være nyttig (Prometheus eksportør og Grafana dashbord).
Kilde: www.habr.com