Uzraugām Kubernetes klasteru resursus

Es esmu izveidojis Kube Eagle — Prometheus eksportētāju. Izrādījās, ka tā ir lieliska lieta, kas palīdz labāk izprast mazo un vidējo klasteru resursus. Rezultātā es ietaupīju vairākus simtus dolāru, jo izvēlējos pareizos mašīnu tipus un pielāgoju aplikāciju resursu ierobežojumus darba slodzēm.

Es pastāstīšu par priekšrocībām Kube Eagle, bet vispirms izskaidrošu, kāpēc radās problēmas un kādēļ vajadzēja kvalitatīvu monitoringu.

Es pārvaldīju vairākus klasterus ar 4–50 mezgliem. Katrā klasterī ir līdz 200 mikroservisiem un aplikācijām. Lai efektīvāk izmantotu pieejamo aparatūru, lielākā daļa izvietošanas bija konfigurēta ar burstable operatīvo atmiņu un CPU resursiem. Tādējādi podi varēja izmantot pieejamos resursus, ja tas bija nepieciešams, un tajā pašā laikā netraucēja citām aplikācijām šajā mezglā. Nu, vai tas nav lieliski?

Un, lai gan klasteris patērēja relatīvi maz CPU (8%) un operatīvās atmiņas (40%), mums pastāvīgi radās problēmas ar podu izraidīšanu, kad tie mēģināja pieprasīt vairāk atmiņas, nekā bija pieejams mezglā. Tajā laikā mums bija tikai viena panelis Kubernetes resursu monitorēšanai. Šāda:

Grafana panelis tikai ar cAdvisor metriem

Ar šādu paneli mezgliem, kas patērē daudz atmiņas un CPU, redzēt nav problēma. Problēma ir saprast, kāds ir cēlonis. Lai podi paliktu savā vietā, varētu, protams, konfigurēt garantētos resursus visiem podiem (pieprasītie resursi ir vienādi ar ierobežojumu). Bet tas nav visprātīgākais aparatūras izmantošana. Klasterī bija vairākas simti gigabaiti atmiņas, taču dažiem mezgliem trūka resursu, bet citiem bija saglabājušies 4–10 GB.

Izrādās, Kubernetes plānotājs nevienmērīgi sadalīja darba slodzes pa pieejamajiem resursiem. Kubernetes plānotājs ņem vērā dažādas konfigurācijas: affinitātes noteikumus, taints un tolerances, mezglu selektorus, kas var ierobežot pieejamos mezglus. Bet manā gadījumā nekas tāds nebija, un podi tika plānoti atbilstoši pieprasītajiem resursiem katrā mezglā.

Poda izvēlē bija mezgls, kuram bija visvairāk brīvo resursu un kurš atbilda pieprasījuma prasībām. Mums iznāca, ka pieprasītie resursi mezglos nesakrīt ar faktisko lietojumu, un šeit palīgu sniedza Kube Eagle un tā resursu monitorēšanas iespējas.

Man gandrīz visi Kubernetes klasteri tika uzraudzīti tikai ar Node exporter un Kube State Metrics. Node Exporter nodrošina statistiku par ieeju-izeju un diska, CPU un operatīvās atmiņas izmantošanu, bet Kube State Metrics parāda Kubernetes objektu metriku, piemēram, pieprasījumus un ierobežojumus attiecībā uz CPU un atmiņu.

Mums ir jāapvieno izmantošanas metriķi ar pieprasījumu un ierobežojumu metriķiem Grafana, un tad mēs iegūsim visu informāciju par problēmu. Tas izklausās vienkārši, bet patiesībā šajos divos rīkos etiķetes tiek sauktas atšķirīgi, un dažiem metriķiem vispār nav metadatu etiķešu. Kube Eagle visu izdarīs pats, un panelis izskatās šādi:

Kube Eagle uzraudzības panelis

Mums izdevās atrisināt daudz resursu problēmu un ietaupīt dzelzi:

1. Daži izstrādātāji nezināja, cik daudz resursu nepieciešams mikroservisiem (vai vienkārši par to nenogurdināja). Mums nebija ar ko atrast nepareizos resursu pieprasījumus - tam ir jāzina patēriņš plus pieprasījumi un ierobežojumi. Tagad viņi redz Prometheus metriķus, uzrauga faktiskās izmantošanas līmeni un pielāgo pieprasījumus un ierobežojumus.
2. JVM lietojumprogrammas patērē tik daudz operatīvās atmiņas, cik vien var. Atkritumu savācējs atbrīvo atmiņu tikai tad, ja tiek izmantots vairāk nekā 75%. Un, tā kā lielākajai daļai servisu ir burstable atmiņa, to vienmēr aizņēma JVM. Tāpēc visi šie Java servisi patērēja daudz vairāk operatīvās atmiņas, nekā tika gaidīts.
3. Dažas lietojumprogrammas pieprasīja pārāk daudz atmiņas, un Kubernetes īstenotājs nedeva šīs noderības citiem lietojumiem, kaut arī tām faktiski bija vairāk brīvas atmiņas nekā citām noderībām. Viens izstrādātājs nejauši pievienoja lieku ciparu pie pieprasījuma un aizņēma lielu operatīvās atmiņas gabalu: 20 GB vietā 2. Neviens pat nepamanīja. Lietojumprogrammai bija 3 replikas, tāpēc cieta 3 noderības.
4. Mēs ieviesām resursu ierobežojumus, pārlikām podus ar pareiziem pieprasījumiem un ieguvām ideālu dzelzs izmantošanas līdzsvaru visās noderībās. Dažas noderības varēja pat slēgt. Pēc tam mēs redzējām, ka mums ir nepareizas mašīnas (vērstas uz CPU, nevis atmiņu). Mēs mainījām tipu un izdzēšam vēl dažas noderības.

Secinājumi

Ar burstable resursiem klasterī jūs efektīvāk izmantojat esošo aparatūru, taču Kubernetes plānotājs plāno podus atbilstoši resursu pieprasījumiem, un tas ir riskanti. Lai nogalinātu divus zaķus: un problēmas novērstu, un resursus izmantotu pilnībā, - nepieciešams labs uzraudzības rīks. Tieši tam Kube Eagle būs noderīgs. Kube Eagle (Prometheus eksportētājs un Grafana uzraudzības panelis).

Avots: habr.com