Övervaka resurser i Kubernetes-kluster

Jag skapade Kube Eagle – en Prometheus-exportör. Det visade sig vara en fantastisk sak som hjälper till att förstå resurserna i små och medelstora kluster bättre. I slutändan sparade jag flera hundra dollar eftersom jag valde rätt typ av maskiner och justerade begränsningarna för resurserna till applikationerna utifrån arbetsbelastningen.

Jag kommer att berätta om fördelarna Kube Eagle, men först förklarar jag vad som ledde till problemet och varför kvalitetsmonitorering behövdes.

Jag hanterade flera kluster med 4 till 50 noder. I varje kluster fanns upp till 200 mikrotjänster och applikationer. För att effektivare använda den tillgängliga hårdvaran var de flesta distribuerade med burstable RAM och CPU-resurser. Så poddar kan ta tillgängliga resurser vid behov utan att störa andra applikationer på den noden. Är det inte fantastiskt?

Och även om klustret förbrukade relativt lite CPU (8%) och minne (40%), hade vi ständigt problem med att poddar blev utdrivna när de försökte ta mer minne än vad som fanns tillgängligt på noden. Då hade vi bara en panel för att övervaka Kubernetes-resurser. Så här såg den ut:

Grafana-panel med endast cAdvisor-metrik

Med en sådan panel är det enkelt att se noder som konsumerar mycket minne och CPU. Problemet är att förstå orsaken. För att poddarna skulle stanna kvar på plats kunde vi självklart ställa in garanterade resurser på alla poddar (begärda resurser är lika med gränsen). Men det är inte det smartaste sättet att använda hårdvaran. Klustret hade flera hundra gigabyte minne, men vissa noder led av resursbrist medan andra hade 4 till 10 GB över.

Det visar sig att Kubernetes-planeraren fördelade arbetsbelastningen ojämnt över de tillgängliga resurserna. Kubernetes-planeraren tar hänsyn till olika konfigurationer: affinity-regler, taints och tolerations, nodselekterare som kan begränsa tillgängliga noder. Men i mitt fall fanns inget sådant, och poddar planerades utifrån begärda resurser på varje nod.

För en podd valdes en nod som hade mest lediga resurser och som uppfyllde begärans villkor. Vi fick en situation där de begärda resurserna på noderna inte matchade den faktiska användningen, och här kom Kube Eagle in i bilden med sina övervakningsmöjligheter.

Nästan alla mina Kubernetes-kluster övervakades endast med Node exporter och Kube State Metrics. Node Exporter ger statistik över in- och utdata samt användning av disk, CPU och RAM, medan Kube State Metrics visar metrik för Kubernetes-objekt, såsom resursförfrågningar och begränsningar för CPU och minne.

Vi behöver kombinera användningsmetrik med resursförfrågningar och begränsningar i Grafana, så får vi all information om problemet. Det låter enkelt, men i dessa två verktyg kallas ceptorna olika, och vissa metrik har helt enkelt inga metadata-taggar. Kube Eagle sköter allt automatiskt och instrumentpanelen ser ut så här:

Kube Eagle-mätpanel

Vi har lyckats lösa många resursproblem och spara utrustning:

1. Vissa utvecklare visste inte hur många resurser mikrotjänsterna behövde (eller brydde sig helt enkelt inte). Vi hade inget sätt att hitta felaktiga resursförfrågningar - för detta behövs både konsumtion och begärningar och begränsningar. Nu ser de Prometheus-mått, övervakar faktisk användning och justerar sina förfrågningar och begränsningar.
2. JVM-applikationer tar så mycket RAM som möjligt. Skräpsamlaren frigör minne endast om mer än 75 % används. Eftersom majoriteten av tjänsterna har burstable minne, upptogs det alltid av JVM. Därför åt alla dessa Java-tjänster betydligt mer RAM än väntat.
3. Vissa applikationer begärde för mycket minne, och Kubernetes-schemaläggaren gav inte dessa noder till andra applikationer, även om de i verkligheten var ledigare än andra noder. En utvecklare råkade skriva in en extra siffra i sin begäran och tog en stor del av RAM: 20 GB istället för 2. Ingen märkte något. Applikationen hade 3 repliker, så det drabbade hela 3 noder.
4. Vi införde resursbegränsningar, omplanerade pods med rätt förfrågningar och fick en perfekt balans i hårdvaruanvändningen över alla noder. Ett par noder kunde till och med stängas ner. Och sedan såg vi att vi hade fel typ av maskiner (fokuserade på CPU istället för minne). Vi bytte typ och tog bort ytterligare några noder.

Sammanfattning

Med burstable resurser i klustret utnyttjar du den tillgängliga hårdvaran effektivare, men Kubernetes-schemaläggaren planerar pods utifrån resursförfrågningar, vilket kan bli problematiskt. För att döda två flugor i en smäll: undvika problem och maximera resursanvändningen, behövs bra övervakning. Det är här Kube Eagle kommer in. Kube Eagle (exportör för Prometheus och Grafana övervakningspanel).

Källa: habr.com