Unë krijova Kube Eagle - një eksportues i Prometeut. Doli të ishte një gjë e lezetshme që ndihmon për të kuptuar më mirë burimet e grupimeve të vogla dhe të mesme. Në fund, kurseva qindra dollarë sepse zgjodha llojet e duhura të makinerive dhe konfigurova kufijtë e burimeve të aplikacionit për ngarkesat e punës.
Unë do t'ju tregoj për përfitimet , por fillimisht do të shpjegoj se çfarë e shkaktoi bujën dhe pse ishte i nevojshëm monitorimi me cilësi të lartë.
Kam menaxhuar disa grupime me 4-50 nyje. Çdo grup përmban deri në 200 mikroshërbime dhe aplikacione. Për të përdorur më mirë harduerin ekzistues, shumica e vendosjeve u konfiguruan me burime RAM dhe CPU të shpërthyer. Në këtë mënyrë, pods mund të marrin burimet e disponueshme nëse është e nevojshme, dhe në të njëjtën kohë të mos ndërhyjnë me aplikacionet e tjera në këtë nyje. Epo, a nuk është mirë?
Dhe megjithëse grupi konsumonte relativisht pak CPU (8%) dhe RAM (40%), ne vazhdimisht kishim probleme me parandalimin e pods kur ata u përpoqën të shpërndanin më shumë memorie sesa ishte në dispozicion në nyje. Në atë kohë kishim vetëm një panel kontrolli për monitorimin e burimeve të Kubernetes. Si kjo:
Paneli i Grafana vetëm me matjet e cAdvisor
Me një panel të tillë, nuk është problem të shohësh nyje që hanë shumë memorie dhe CPU. Problemi është të kuptojmë se cila është arsyeja. Për të mbajtur pods në vend, sigurisht që mund të vendosen burime të garantuara në të gjitha pods (burimet e kërkuara të barabarta me kufirin). Por ky nuk është përdorimi më i zgjuar i harduerit. Grupi kishte disa qindra gigabajt memorie, ndërkohë që disa nyje po vuanin nga uria, ndërsa të tjerat kishin rezervë 4–10 GB.
Rezulton se planifikuesi Kubernetes shpërndau ngarkesat e punës në mënyrë të pabarabartë nëpër burimet e disponueshme. Planifikuesi Kubernetes merr parasysh konfigurime të ndryshme: rregullat e afinitetit, njollave dhe tolerimeve, përzgjedhësit e nyjeve që mund të kufizojnë nyjet e disponueshme. Por në rastin tim nuk kishte asgjë të tillë, dhe pods ishin planifikuar në varësi të burimeve të kërkuara në secilën nyje.
Për podin u zgjodh nyja që ka më shumë burime të lira dhe që plotëson kushtet e kërkesës. Ne zbuluam se burimet e kërkuara në nyjet nuk përputheshin me përdorimin aktual, dhe këtu erdhën në ndihmë Kube Eagle dhe aftësitë e tij të monitorimit të burimeve.
Unë kam pothuajse të gjitha grupimet Kubernetes të monitoruara vetëm me и . Node Exporter ofron statistika mbi përdorimin e I/O dhe të diskut, CPU-së dhe RAM-it, ndërsa Kube State Metrics tregon matjet e objekteve të Kubernetes si kërkesat dhe kufizimet e burimeve të CPU-së dhe kujtesës.
Duhet të kombinojmë matjet e përdorimit me matjet e kërkesave dhe kufijve në Grafana dhe më pas do të marrim të gjithë informacionin rreth problemit. Kjo tingëllon e thjeshtë, por të dy mjetet në fakt i emërtojnë etiketat ndryshe, dhe disa metrikë nuk kanë fare etiketa meta të dhënash. Kube Eagle bën gjithçka vetë dhe paneli duket si ky:
Ne arritëm të zgjidhim shumë probleme me burimet dhe të kursejmë pajisjet:
- Disa zhvillues nuk e dinin se sa burime kishin nevojë për mikroshërbime (ose thjesht nuk u shqetësuan). Nuk kishte asnjë mënyrë që ne të gjenim kërkesa të pasakta për burime - për këtë ne duhet të dimë konsumin plus kërkesat dhe kufijtë. Tani ata shohin matjet e Prometheus, monitorojnë përdorimin aktual dhe rregullojnë kërkesat dhe kufijtë.
- Aplikacionet JVM marrin aq shumë RAM sa mund të përballojnë. Mbledhësi i plehrave lëshon memorie vetëm kur përdoret më shumë se 75%. Dhe meqenëse shumica e shërbimeve kanë memorie të shpërthyer, ajo ishte gjithmonë e zënë nga JVM. Prandaj, të gjitha këto shërbime Java po konsumonin shumë më tepër RAM sesa pritej.
- Disa aplikacione kërkuan shumë memorie dhe planifikuesi Kubernetes nuk ua dha këto nyje aplikacioneve të tjera, edhe pse në fakt ato ishin më të lira se nyjet e tjera. Një zhvillues shtoi aksidentalisht një shifër shtesë në kërkesë dhe rrëmbeu një pjesë të madhe RAM: 20 GB në vend të 2. Askush nuk e vuri re. Aplikacioni kishte 3 kopje, kështu që u prekën deri në 3 nyje.
- Ne prezantuam kufijtë e burimeve, riplanifikuam podet me kërkesat e sakta dhe morëm një ekuilibër ideal të përdorimit të harduerit në të gjitha nyjet. Disa nyje mund të ishin mbyllur fare. Dhe më pas pamë se kishim makina të gabuara (të orientuara nga CPU, jo të orientuara nga memoria). Ne ndryshuam llojin dhe fshimë disa nyje të tjera.
Rezultatet e
Me burime të shpërthyera në grup, ju përdorni harduerin e disponueshëm në mënyrë më efikase, por planifikuesi Kubernetes planifikon pods bazuar në kërkesat për burime, dhe kjo është e mbushur me. Për të vrarë dy zogj me një gur: për të shmangur problemet dhe për të përdorur burimet në maksimum, keni nevojë për monitorim të mirë. Kjo është arsyeja pse do të jetë e dobishme (Prometheus eksportues dhe pulti i Grafana).
Burimi: www.habr.com