Мен Kube Eagle жасадым - Prometheus экспорттаушысы. Бұл шағын және орта кластерлердің ресурстарын жақсы түсінуге көмектесетін керемет нәрсе болып шықты. Соңында мен жүздеген долларды үнемдедім, себебі мен дұрыс машина түрлерін таңдадым және жұмыс жүктемелері үшін қолданба ресурстарының шектеулерін теңшедім.
Мен сізге пайдасы туралы айтып беремін , бірақ алдымен мен шудың неден туындағанын және неге жоғары сапалы бақылау қажет екенін түсіндіремін.
Мен 4-50 түйіннен тұратын бірнеше кластерді басқардым. Әрбір кластерде 200 микросервис пен қолданбаға дейін бар. Қолданыстағы аппараттық құралдарды жақсырақ пайдалану үшін орналастырулардың көпшілігі жедел жады және процессор ресурстарымен конфигурацияланды. Осылайша, қажет болса, подкасттар қолжетімді ресурстарды ала алады және сонымен бірге осы түйіндегі басқа қолданбаларға кедергі жасамайды. Жақсы емес пе?
Кластер салыстырмалы түрде аз CPU (8%) мен жедел жадты (40%) тұтынса да, бізде түйінде қол жетімді болғаннан көбірек жадты бөлуге тырысқанда, блоктардың алдын ала алынуында үнемі қиындықтар туындады. Ол кезде бізде Kubernetes ресурстарын бақылауға арналған бір ғана бақылау тақтасы болды. Бұл сияқты:
Тек cAdvisor көрсеткіштері бар Grafana бақылау тақтасы
Мұндай панельде көп жад пен процессорды жейтін түйіндерді көру қиын емес. Мәселе оның себебін анықтауда. Қоспаларды орнында ұстау үшін, әрине, барлық подкасттарда кепілдендірілген ресурстарды орнатуға болады (сұралған ресурстар шекке тең). Бірақ бұл аппараттық құралдарды ең ақылды пайдалану емес. Кластерде бірнеше жүз гигабайт жады болды, ал кейбір түйіндер аштыққа ұшырады, ал басқаларында резервте 4–10 ГБ қалды.
Kubernetes жоспарлаушысы қол жетімді ресурстар бойынша жұмыс жүктемелерін біркелкі таратпағаны белгілі болды. Kubernetes жоспарлаушысы әртүрлі конфигурацияларды ескереді: ұқсастық, ақаулар мен рұқсат ету ережелері, қол жетімді түйіндерді шектей алатын түйін селекторлары. Бірақ менің жағдайда ондай ештеңе болған жоқ, және бөтелкелер әрбір түйінде сұралған ресурстарға байланысты жоспарланған.
Ең бос ресурстары бар және сұрау шарттарын қанағаттандыратын түйін подкаст үшін таңдалды. Түйіндердегі сұралған ресурстардың нақты пайдаланумен сәйкес келмейтінін анықтадық және бұл жерде Kube Eagle және оның ресурстарды бақылау мүмкіндіктері көмекке келді.
Менде барлық дерлік Kubernetes кластерлері бар и . Түйін экспорттаушысы енгізу/шығару және дискі, орталық процессор және жедел жадты пайдалану статистикасын береді, ал Kube күйінің көрсеткіштері сұраулар, орталық процессор және жад ресурстарының шектеулері сияқты Kubernetes нысан көрсеткіштерін көрсетеді.
Қолдану көрсеткіштерін Графанадағы сұраулар мен шектеулер көрсеткіштерімен біріктіру керек, содан кейін мәселе туралы барлық ақпаратты аламыз. Бұл қарапайым естіледі, бірақ екі құралда белгілерді басқаша атайды және кейбір көрсеткіштерде метадеректер белгілері мүлдем жоқ. Kube Eagle бәрін өзі жасайды және панель келесідей көрінеді:
Біз ресурстармен және жабдықты үнемдеумен көптеген мәселелерді шеше алдық:
- Кейбір әзірлеушілер микросервистерге қанша ресурстар қажет екенін білмеді (немесе жай ғана алаңдатпады). Ресурстарға дұрыс емес сұрауларды табудың ешқандай жолы болмады - бұл үшін тұтынуды, сонымен қатар сұраулар мен шектеулерді білуіміз керек. Енді олар Prometheus көрсеткіштерін көреді, нақты пайдалануды бақылайды және сұраулар мен шектеулерді реттейді.
- JVM қолданбалары жұмыс істей алатындай көп жедел жадты алады. Қоқыс жинағыш 75%-дан астам пайдаланылған кезде ғана жадты босатады. Көптеген қызметтерде жады бар болғандықтан, оны әрқашан JVM алады. Сондықтан осы Java қызметтерінің барлығы күтілгеннен әлдеқайда көп жедел жадты жеді.
- Кейбір қолданбалар тым көп жадты сұрады және Kubernetes жоспарлаушысы бұл түйіндерді басқа қолданбаларға бермеді, тіпті олар басқа түйіндерге қарағанда бос болды. Бір әзірлеуші байқаусызда сұрауға қосымша сан қосып, оперативті жадтың үлкен бөлігін басып алды: 20 орнына 2 ГБ. Ешкім байқамады. Қолданбаның 3 репликасы болды, сондықтан 3 түйінге әсер етті.
- Біз ресурс шектеулерін енгіздік, дұрыс сұраулары бар подкасттарды қайта жоспарладық және барлық түйіндерде аппараттық құралдарды пайдаланудың тамаша теңгерімін алдық. Бірнеше түйін толығымен жабылуы мүмкін еді. Содан кейін бізде дұрыс емес машиналар бар екенін көрдік (жадыға емес, процессорға бағытталған). Біз түрін өзгертіп, тағы бірнеше түйінді жойдық.
Нәтижелері
Кластердегі серпінді ресурстармен сіз қол жетімді жабдықты тиімдірек пайдаланасыз, бірақ Kubernetes жоспарлаушысы қорларға сұраулар негізінде подкасттарды жоспарлайды және бұл қиын. Екі құсты бір таспен өлтіру үшін: проблемаларды болдырмау және ресурстарды толық пайдалану үшін сізге жақсы бақылау қажет. Сондықтан бұл пайдалы болады (Prometheus экспорттаушысы және Grafana бақылау тақтасы).
Ақпарат көзі: www.habr.com