Kam krijova Kube Eagle - eksportuesin Prometheus. Doli të jetë një gjë e shkëlqyer, që ndihmon në kuptimin më të mirë të burimeve të grupeve të vogla dhe të mesme. Në fund, kursyeva me qindra dollarë, sepse zgjodha llojet e duhura të makinave dhe konfigurava kufijtë e burimeve të aplikacioneve në përputhje me ngarkesat e punës.
Do të flas për avantazhet , por së pari do të shpjegoj se çfarë e shkaktoi këtë situatë dhe përse kishte nevojë për monitorim cilësor.
Kam menaxhuar disa grupe me 4-50 nodë. Në çdo grup - deri në 200 mikroservise dhe aplikacione. Për të përdorur më mirë pajisjet e disponueshme, shumica e deplozeve ishin konfiguruar me memorie dhe burime CPU burstable. Kështu që pod-i mund të marrë burimet e disponueshme, nëse nevojitet, dhe në të njëjtën kohë të mos pengojë aplikacionet e tjera në këtë nodë. A nuk është e mrekullueshme?
Dhe ndonëse grupi konsumonte relativisht pak CPU (8%) dhe RAM (40%), vazhdimisht kishim probleme me përjashtimin e pod-eve, kur ato përpiqeshin të merrnin më shumë memorie sesa ishte e disponueshme në nodë. Atëherë kishim vetëm një panel për monitorimin e burimeve Kubernetes. Ja si ishte:
Paneli Grafana vetëm me metrika cAdvisor
Me këtë panel, nodët që konsumonin shumë memorie dhe CPU, ishin të dukshme pa problem. Problemi ishte të kuptohej se çfarë ishte arsyeja. Për të mbajtur pod-et në vend, mund të konfiguroni burime të garantuara për të gjitha pod-et (burimet e kërkuara barazohen me kufirin). Por kjo nuk është përdorimi më inteligjent i pajisjeve. Në grup ishin disa qindra gigabajt memorie, dhe disa nodë ishin të uritur, ndërsa të tjera kishin mbetje prej 4-10 GB.
Kështu, planifikuesi Kubernetes shpërndante ngarkesat e punës sipas burimeve të disponueshme në mënyrë jo të barabartë. Planifikuesi Kubernetes merr parasysh konfigurime të ndryshme: rregullat e afinitetit, taints dhe tolerations, selektorët e nodëve, që mund të kufizojnë nodët e disponueshme. Por në rastin tim, nuk kishte asgjë të tillë, dhe pod-et planifikoheshin në varësi të burimeve të kërkuara në çdo nodë.
Për një pod zgjidhej nodi me burimet më të lira dhe që plotësonte kushtet e kërkesës. Kaluam në një situatë ku burimet e kërkuara në nodë nuk përputhen me shfrytëzimin aktual, dhe këtu ndihmoi Kube Eagle dhe mundësitë e tij për monitorimin e burimeve.
G hampir të gjitha grupet Kubernetes monitoroheshin vetëm me dhe . Node Exporter ofron statistika për hyrjet dhe daljet dhe përdorimin e diskut, CPU dhe RAM, ndërsa Kube State Metrics tregon metrika për objektet Kubernetes, siç janë kërkesat dhe kufijtë për burimet e CPU dhe memorjes.
Na nevojitet të bashkojmë metrikat e përdorimit me metrikat e kërkesave dhe kufijve në Grafana, dhe atëherë do të kemi të gjitha informacionet mbi problemin. Kjo duket e thjeshtë, por në të vërtetë në këto dy mjete etiketat quhen ndryshe, dhe disa metrika madje nuk kanë fare etiketat e metadatas. Kube Eagle e bën gjithçka automatikisht dhe paneli duket kështu:
Kemi arritur të zgjidhim shumë probleme me burimet dhe të kursejmë pajisjet:
- Disa zhvillues nuk dinin se sa burime i nevojiten mikroshërbimeve (ose thjesht nuk e merrnin seriozisht). Nuk kishim mënyrë për të identifikuar kërkesat e gabshme për burime - për këtë na duhej të dinim konsumin plus kërkesat dhe kufijtë. Tani ata shikojnë metrikat Prometheus, monitorojnë përdorimin aktual dhe përshtasin kërkesat dhe kufijtë.
- Aplikacionet JVM marrin aq shumë RAM sa mund të mbajnë. Mblidhësi i plehrave liro burimin vetëm nëse është përdorur më shumë se 75%. Dhe pasi që shumica e shërbimeve kanë memorje burstable, JVM gjithmonë e konsumonte atë. Prandaj, të gjitha këto shërbime Java konsumonin shumë më tepër RAM sesa pritej.
- Disa aplikacione kërkuan shumë më tepër RAM, dhe planifikuesi i Kubernetes nuk u jepte këto node aplikacioneve të tjera, ndonëse në fakt ata ishin më të lirë se node të tjera. Një zhvillues rastësisht u shtoi një numër të panevojshëm në kërkesë dhe zuri një pjesë të madhe të RAM-it: 20 GB në vend të 2. Askush nuk e vuri re. Aplikacioni kishte 3 replikë, kështu që u prekën deri në 3 node.
- Kemi vendosur kufizime për burimet, riplanifikuar pod-et me kërkesat e duhura dhe arritëm një balans të përsosur të përdorimit të pajisjeve në të gjitha node-t. Disa node mund të mbylleshin plotësisht. Më pas e kuptuam se kishim makineri të gabuara (orientuara ndaj CPU-së, e jo ndaj memorjes). Ndryshuam tipin dhe fshimë edhe disa node të tjera.
Përfundime
Me burimet burstable në klaster, përdorni më efektivisht pajisjet ekzistuese, por planifikuesi i Kubernetes planifikon pod-et sipas kërkesave për burime, dhe kjo është problematike. Për të eliminuar dy zogj me një gur: të shmangim problemet dhe të përdorim burimet në maksimum, na nevojitet një monitorim i mirë. Pikërisht për këtë është i nevojshëm. (eksportuesi Prometheus dhe paneli i monitorimit Grafana).
Burimi: habr.com
