Am creat Kube Eagle – un exporter Prometheus. S-a dovedit a fi o unealtă grozavă, care ajută la înțelegerea mai bună a resurselor în clusterele mici și medii. În final, am economisit câteva sute de dolari, deoarece am ales tipurile corecte de mașini și am configurat limitările resurselor aplicațiilor în funcție de sarcinile de lucru.
Voi vorbi despre avantajele , dar mai întâi voi explica de ce a apărut o problemă și de ce a fost necesară o monitorizare de calitate.
Am gestionat mai multe clustere cu 4–50 de noduri. În fiecare cluster sunt până la 200 de microservicii și aplicații. Pentru a folosi mai eficient echipamentele existente, majoritatea implementărilor au fost configurate cu memorie și resurse CPU de tip burstable. Astfel, podurile pot utiliza resursele disponibile, dacă este necesar, fără a deranja alte aplicații de pe acest nod. Nu este grozav?
Și, deși clusterul consuma relativ puțin CPU (8%) și memorie (40%), întâmpinam constant probleme cu eliminarea podurilor atunci când încercau să aloce mai multă memorie decât era disponibil pe nod. Atunci am avut doar o singură panou pentru monitorizarea resurselor Kubernetes. Iată-l:
Panoul Grafana doar cu metrice cAdvisor
Cu un astfel de panou, este ușor să vezi nodurile care consumă multă memorie și CPU. Problema este să înțelegi care este cauza. Pentru ca podurile să rămână în loc, am putea, desigur, să configurăm resursele garantate pe toate podurile (resursele solicitate sunt egale cu limita). Dar nu este cea mai inteligentă utilizare a echipamentului. Clusterele aveau câteva sute de gigaocteți de memorie, în timp ce unele noduri sufereau de foame, iar altele aveau de rezervă între 4–10 GB.
Se dovedește că planificatorul Kubernetes distribuia sarcinile de lucru pe resursele disponibile inegal. Planificatorul Kubernetes ia în considerare diferite configurații: regulile de afinitate, taints și tolerations, selecții de noduri, care pot restricționa nodurile disponibile. Dar în cazul meu nu existau astfel de condiții, iar podurile erau planificate în funcție de resursele solicitate pe fiecare nod.
Pentru un pod era aleasă nodul cu cele mai multe resurse libere și care îndeplinea condițiile cererii. Se întâmpla că resursele solicitate pe noduri nu coincideau cu utilizarea efectivă, iar aici a intervenit Kube Eagle și capacitățile sale de monitorizare a resurselor.
Am monitorizat aproape toate clusterele Kubernetes doar cu și Node Exporter oferă statisticile despre intrare-ieșire și utilizarea discului, CPU și memorie, iar Kube State Metrics afișează metricile obiectelor Kubernetes, cum ar fi cererile și limitele resurselor CPU și memorie.
Trebuie să combinăm metricile de utilizare cu metricile cererilor și limitelor în Grafana, și atunci vom obține toate informațiile despre problemă. Pare simplu, dar în realitate aceste două instrumente denumesc diferit etichetele, iar unele metrici nu au deloc etichete de metadate. Kube Eagle face totul automat și panoul arată astfel:
Am reușit să rezolvăm multe probleme cu resursele și să economisim echipamente:
- Unii dezvoltatori nu știau câte resurse aveau nevoie microserviciile (sau pur și simplu nu se complicau cu asta). Nu aveam cu ce să identificăm cererile eronate la resurse - pentru asta trebuie să știm consumul plus cererile și limitele. Acum văd metricile Prometheus, monitorizează utilizarea efectivă și ajustează cererile și limitele.
- Aplicațiile JVM consumă atâta memorie RAM cât pot. Colectorul de gunoi eliberează memoria doar când este utilizat mai mult de 75%. Și, având în vedere că majoritatea serviciilor folosesc memorie burstable, JVM-ul o ocupa întotdeauna. Din acest motiv, toate aceste servicii Java consumau mult mai multă memorie RAM decât era de așteptat.
- Unele aplicații solicitau prea multă memorie, iar programatorul Kubernetes nu oferea acele noduri altor aplicații, deși în realitate erau mai libere decât alte noduri. Un dezvoltator a adăugat din greșeală o cifră în plus la cerere și a capturat un segment mare de memorie RAM: 20 GB în loc de 2. Nimeni nu a observat. Aplicația avea 3 replici, astfel că 3 noduri au fost afectate.
- Am impus limite la resurse, am reproiectat podurile cu cereri corecte și am obținut un echilibru perfect al utilizării echipamentelor între toate nodurile. Unele noduri puteau fi chiar închise. Apoi am realizat că aveam mașini greșite (orientate pe CPU, nu pe memorie). Am schimbat tipul și am eliminat încă câteva noduri.
Concluzii
Cu resurse burstable în cluster, utilizați mai eficient echipamentele disponibile, dar planificatorul Kubernetes își planifică podurile în funcție de cererile de resurse, ceea ce poate fi riscant. Pentru a omorî doi iepuri dintr-o lovitură: pentru a evita problemele și a utiliza resursele la maximum, este nevoie de un bun sistem de monitorizare. Acesta este exact ceea ce este necesar. (expeditor Prometheus și panou de monitorizare Grafana).
Sursa: habr.com
