Я стварыў Kube Eagle - экспарцёр Prometheus. Аказалася, крутая штука, якая дапамагае лепш разбірацца ў рэсурсах маленькіх і сярэдніх кластараў. У выніку я зэканоміў не адну сотню даляраў, таму што падбіраў правільныя тыпы машын і наладжваў абмежаванні рэсурсаў прыкладанняў пад працоўныя нагрузкі.
Я раскажу пра перавагі , Але спачатку растлумачу, з-за чаго выйшаў сыр-бор і для чаго спатрэбіўся якасны маніторынг.
Я кіраваў некалькімі кластарамі па 4-50 нод. У кожным кластары - да 200 мікрасэрвісаў і прыкладанняў. Каб больш эфектыўна выкарыстоўваць наяўнае жалеза, большасць дэплояў былі настроены з burstable-аператыўнай памяццю і рэсурсамі ЦП. Так поды могуць браць даступныя рэсурсы, калі трэба, і пры гэтым не мяшаюць іншым прыкладанням на гэтай нодзе. Ну, хіба не здорава?
І хоць кластар спажываў адносна мала ЦП (8%) і аператыўкі (40%), у нас увесь час узнікалі праблемы з выцясненнем подаў, калі яны спрабавалі вылучыць больш памяці, чым даступна на нодзе. Тады ў нас была ўсяго адна панэль для маніторынгу рэсурсаў Kubernetes. Вось такая:
Панэль Grafana толькі з метрыкамі cAdvisor
З такой панэллю ноды, якія ядуць шмат памяці і ЦП, убачыць не праблема. Праблема - разабрацца, у чым прычына. Каб поды заставаліся на месцы, можна было, вядома, наладзіць гарантаваныя рэсурсы на ўсіх падах (запытаныя рэсурсы роўныя ліміту). Але гэта не самае разумнае выкарыстанне жалеза. На кластары было некалькі сотняў гігаў памяці, пры гэтым некаторыя ноды галадалі, а ў іншых заставалася ў запасе па 4-10 ГБ.
Атрымліваецца, планавальнік Kubernetes размяркоўваў працоўныя нагрузкі па даступных рэсурсах нераўнамерна. Планавальнік Kubernetes улічвае розныя канфігурацыі: правілы affinity, taints і tolerations, селектары нод, якія могуць абмяжоўваць даступныя ноды. Але ў маім выпадку нічога такога не было, і поды планаваліся ў залежнасці ад запытаных рэсурсаў на кожнай надзе.
Для пода выбіралася нода, у якой больш за ўсё вольных рэсурсаў і якая задавальняе ўмовам запыту. У нас атрымлівалася, што запытаныя рэсурсы на нодах не супадаюць з фактычным выкарыстаннем, і тут на дапамогу прыйшоў Kube Eagle і яго магчымасці маніторынгу рэсурсаў.
У мяне амаль усе кластары Kubernetes адсочваліся толькі з и . Node Exporter дае статыстыку па ўводу-вываду і выкарыстанню дыска, ЦП і аператыўнай памяці, а Kube State Metrics паказвае метрыкі аб'ектаў Kubernetes, напрыклад, запыты і ліміты на рэсурсы ЦП і памяці.
Нам трэба аб'яднаць метрыкі аб выкарыстанні з метрыкамі запытаў і лімітаў у Grafana, і тады атрымаем усю інфармацыю аб праблеме. Гучыць проста, але на справе ў гэтых двух прыладах пазнакі завуцца па-рознаму, а ў некаторых метрык наогул няма метак метададзеных. Kube Eagle усё робіць сам і панэль выглядае вось так:
У нас атрымалася вырашыць шмат праблем з рэсурсамі і зберагчы абсталяванне:
- Некаторыя распрацоўшчыкі не ведалі, колькі рэсурсаў трэба мікрасэрвісам (ці проста не затлумляліся). Нам не было чым знаходзіць няправільныя запыты на рэсурсы - для гэтага трэба ведаць спажыванне плюс запыты і ліміты. Цяпер яны бачаць метрыкі Prometheus, маніторыць фактычнае выкарыстанне і падладжваюць запыты і ліміты.
- JVM-прыкладанні бяруць гэтулькі аператыўнай памяці, колькі панясуць. Зборшчык смецця вызваляе памяць, толькі калі задзейнічана больш за 75%. А раз у большасці сэрвісаў памяць burstable, яе заўсёды займаў JVM. Таму ўсе гэтыя Java-сэрвісы з'ядалі значна больш аператыўнай памяці, чым чакалася.
- Некаторыя прыкладанні запытвалі занадта шмат памяці, і планавальнік Kubernetes не даваў гэтыя ноды астатнім прыкладанням, хоць па факце яны былі вальней іншых нод. Адзін распрацоўшчык выпадкова дадаў лішнюю лічбу ў запыце і захапіў вялікі кавалак аператыўнай памяці: 20 ГБ замест 2. Ніхто і не заўважыў. У дадатку было 3 рэплікі, так што пацярпела ажно 3 ноды.
- Мы ўвялі абмежаванні на рэсурсы, перапланавалі поды з правільнымі запытамі і атрымалі ідэальны баланс выкарыстання жалеза па ўсіх нодах. Пару нод увогуле можна было закрыць. А потым мы ўбачылі, што ў нас няправільныя машыны (арыентаваныя на ЦП, а не на памяць). Мы змянілі тып і выдалілі яшчэ некалькі нод.
Вынікі
З burstable рэсурсамі ў кластары вы больш эфектыўна выкарыстоўваеце наяўнае жалеза, затое планавальнік Kubernetes плануе поды па запытах на рэсурсы, а гэта багата. Каб забіць двух зайцаў: і праблем пазбегнуць, і рэсурсы выкарыстоўваць па поўнай, - патрэбен добры маніторынг. Для гэтага і спатрэбіцца (экспарцёр Prometheus і панэль маніторынгу Grafana).
Крыніца: habr.com