Es izveidoju Kube Eagle - Prometheus eksportētāju. Tā izrādījās forša lieta, kas palīdz labāk izprast mazo un vidējo klasteru resursus. Galu galā es ietaupīju simtiem dolāru, jo izvēlējos pareizos mašīnu veidus un konfigurēju lietojumprogrammu resursu ierobežojumus darba slodzei.
Es jums pastāstīšu par priekšrocībām , bet vispirms es paskaidrošu, kas izraisīja satraukumu un kāpēc bija nepieciešama augstas kvalitātes uzraudzība.
Es pārvaldīju vairākas 4–50 mezglu kopas. Katrā klasterī ir līdz 200 mikropakalpojumiem un lietojumprogrammām. Lai labāk izmantotu esošo aparatūru, lielākā daļa izvietojumu tika konfigurēti ar pārraujamiem RAM un CPU resursiem. Tādā veidā podi vajadzības gadījumā var izmantot pieejamos resursus un tajā pašā laikā netraucēt citām šī mezgla lietojumprogrammām. Nu, vai nav lieliski?
Un, lai gan klasteris patērēja salīdzinoši maz CPU (8%) un operatīvās atmiņas (40%), mums pastāvīgi bija problēmas ar aplikācijām, kad tās mēģināja piešķirt vairāk atmiņas, nekā bija pieejams mezglā. Toreiz mums bija tikai viens informācijas panelis Kubernetes resursu uzraudzībai. Kā šis:
Grafana informācijas panelis ar tikai cAdvisor metriku
Izmantojot šādu paneli, nav problēmu redzēt mezglus, kas patērē daudz atmiņas un CPU. Problēma ir noskaidrot, kāds ir iemesls. Lai noturētu podi vietā, var, protams, iestatīt garantētus resursus uz visiem podiem (pieprasītie resursi ir vienādi ar limitu). Bet šī nav visgudrākā aparatūras izmantošana. Klasterim bija vairāki simti gigabaitu atmiņas, kamēr daži mezgli bija izsalkuši, bet citiem bija rezervē palikuši 4–10 GB.
Izrādās, ka Kubernetes plānotājs nevienmērīgi sadalīja darba slodzi pa pieejamajiem resursiem. Kubernetes plānotājs ņem vērā dažādas konfigurācijas: afinitāti, bojājumus un pielaides noteikumus, mezglu atlasītājus, kas var ierobežot pieejamos mezglus. Bet manā gadījumā nekas tāds nebija, un podi tika plānoti atkarībā no pieprasītajiem resursiem katrā mezglā.
Podam tika atlasīts mezgls, kuram ir visvairāk brīvo resursu un kas atbilst pieprasījuma nosacījumiem. Mēs atklājām, ka pieprasītie resursi mezglos neatbilst faktiskajam lietojumam, un šeit palīgā nāca Kube Eagle un tā resursu uzraudzības iespējas.
Man gandrīz visi Kubernetes klasteri tiek uzraudzīti tikai ar и . Node Exporter nodrošina statistiku par I/O un diska, CPU un RAM lietojumu, savukārt Kube State Metrics parāda Kubernetes objektu metriku, piemēram, pieprasījumus un CPU un atmiņas resursu ierobežojumus.
Mums ir jāapvieno lietojuma metrika ar Grafana pieprasījumu un ierobežojumu metriku, un tad mēs iegūsim visu informāciju par problēmu. Tas izklausās vienkārši, taču abiem rīkiem etiķetes tiek nosauktas atšķirīgi, un dažiem rādītājiem vispār nav metadatu etiķešu. Kube Eagle visu dara pats, un panelis izskatās šādi:
Mums izdevās atrisināt daudzas problēmas ar resursiem un ietaupīt aprīkojumu:
- Daži izstrādātāji nezināja, cik daudz resursu mikropakalpojumiem nepieciešams (vai vienkārši neuztraucās). Mums nebija iespējas atrast nepareizus resursu pieprasījumus - lai to izdarītu, mums ir jāzina patēriņš plus pieprasījumi un ierobežojumi. Tagad viņi redz Prometheus metriku, uzrauga faktisko lietojumu un pielāgo pieprasījumus un ierobežojumus.
- JVM lietojumprogrammas aizņem tik daudz RAM, cik tās spēj apstrādāt. Atkritumu savācējs atbrīvo atmiņu tikai tad, ja tiek izmantots vairāk nekā 75%. Un tā kā lielākajai daļai pakalpojumu ir pārsprāgta atmiņa, to vienmēr izmantoja JVM. Tāpēc visi šie Java pakalpojumi patērēja daudz vairāk RAM, nekā gaidīts.
- Dažas lietojumprogrammas pieprasīja pārāk daudz atmiņas, un Kubernetes plānotājs nepiešķīra šos mezglus citām lietojumprogrammām, lai gan patiesībā tie bija brīvāki nekā citi mezgli. Viens izstrādātājs pieprasījumam nejauši pievienoja papildu ciparu un satvēra lielu RAM: 20 GB, nevis 2. Neviens to nepamanīja. Lietojumprogrammai bija 3 kopijas, tāpēc tika ietekmēti pat 3 mezgli.
- Mēs ieviesām resursu ierobežojumus, pārplānojām blokus ar pareiziem pieprasījumiem un ieguvām ideālu aparatūras lietojuma līdzsvaru visos mezglos. Pāris mezgli varēja būt slēgti pavisam. Un tad mēs redzējām, ka mums ir nepareizas iekārtas (orientētas uz CPU, nevis uz atmiņu). Mēs mainījām veidu un izdzēsām vēl vairākus mezglus.
Rezultāti
Ja klasterī ir pārraujami resursi, pieejamā aparatūra tiek izmantota efektīvāk, taču Kubernetes plānotājs ieplāno aplikumus, pamatojoties uz resursu pieprasījumiem, un tas ir sarežģīti. Lai nogalinātu divus putnus ar vienu akmeni: lai izvairītos no problēmām un maksimāli izmantotu resursus, ir nepieciešama laba uzraudzība. Tāpēc tas būs noderīgi (Prometheus eksportētājs un Grafana informācijas panelis).
Avots: www.habr.com