Следим за ресурсите на Kubernetes клъстери

Създадох Kube Eagle – експортер за Prometheus. Оказа се, че е страхотно решение, което помага да се разберат по-добре ресурсите на малките и средни клъстери. В крайна сметка спестих не една стотица долара, защото подбирах правилните типове машини и настройвах ограниченията на ресурсите на приложенията в зависимост от работните натоварвания.

Ще говоря за предимствата на Kube Eagle, но първо ще обясня причините за проблемите и защо беше необходим качествен мониторинг.

Управлявах няколко клъстера с по 4-50 нода. Във всеки клъстер - до 200 микросервиза и приложения. За да използваме по-ефективно наличния хардуер, повечето деплойменти бяха настроени с burstable оперативна памет и ресурси на ЦП. По този начин подовете могат да вземат достъпни ресурси, ако имат нужда, без да пречат на другите приложения на тази нода. Не звучи ли чудесно?

И въпреки че клъстерът консумираше относително малко ЦП (8%) и оперативна памет (40%), постоянно възникваха проблеми с изтласкването на подовете, когато те се опитваха да заделят повече памет, отколкото е налично на нода. Тогава имахме само една табло за мониторинг на ресурсите на Kubernetes. Ето такова:

Табло на Grafana само с метрики от cAdvisor

С такова табло е лесно да се видят нодите, които консумират много памет и ЦП. Проблемът е да се разбере причината. За да подовете останат на мястото си, можеше, разбира се, да настроим гарантирани ресурси за всички подове (заявени ресурси са равни на лимита). Но това не е най-разумното използване на хардуер. В клъстера имаше няколко стотин гигабайта памет, но някои ноди страдаха от недостиг, а на други оставяха по 4-10 GB.

Получава се, че Kubernetes планировчикът разпределя работните натоварвания по наличните ресурси неравномерно. Планировчикът на Kubernetes взема предвид различни конфигурации: правила за affinity, taints и tolerations, селектори за ноди, които могат да ограничат наличните ноди. Но в моя случай нямаше такива условия и подовете се планираха в зависимост от заявените ресурси на всяка нода.

За пода се избираше нода с най-много свободни ресурси, която удовлетворява условията на заявката. Получи се така, че заявените ресурси на нодите не съвпадат с фактическото използване и тук на помощ дойде Kube Eagle и неговите възможности за мониторинг на ресурсите.

Имам почти всички Kubernetes клъстери наблюдавани само с Node exporter и Kube State Metrics. Node Exporter предоставя статистика за вход/изход и използването на диск, CPU и оперативна памет, а Kube State Metrics показва метрики на Kubernetes обекти, например, заявки и лимити за ресурси CPU и памет.

Трябва да комбинираме метриките за използване с метриките за заявки и лимити в Grafana, и тогава ще получим цялата информация за проблема. Звучи просто, но всъщност в тези два инструмента етикетите се наричат различно, а някои метрики изобщо нямат метаданни. Kube Eagle прави всичко автоматично и панелът изглежда ето така:

Панелът за мониторинг на Kube Eagle

Успяхме да решим много проблеми с ресурсите и да спестим оборудване:

1. Някои разработчици не знаеха колко ресурси нуждаят микросервизите (или просто не се притесняваха). Нямахме как да открием неправилни заявки за ресурси - за това е нужно да знаем консумацията плюс заявки и лимити. Сега те виждат метрики от Prometheus, следят фактическото използване и настройват заявки и лимити.
2. JVM приложенията взимат толкова оперативна памет, колкото могат. Събирачът на смет отваря памет само ако е ангажирано повече от 75%. А тъй като повечето услуги имат burstable памет, JVM винаги я заемаше. Поради това всички тези Java услуги консумираха много повече оперативна памет, отколкото беше очаквано.
3. Някои приложения искаха твърде много памет, а планировчикът на Kubernetes не предоставяше тези нодове на останалите приложения, независимо че по факта бяха по-свободни от други нодове. Един разработчик случайно добави излишна цифра в заявката и захвана голямо количество оперативна памет: 20 GB вместо 2. Никой не забеляза. Приложението имаше 3 реплики, така че пострадаха цели 3 нодове.
4. Установихме ограничения за ресурсите, препланирахме подовете с правилни заявки и постигнахме идеален баланс на използването на хардуера между всички нодове. Няколко нода дори можеха да бъдат закрити. А след това видяхме, че имаме неправилни машини (ориентирани към CPU, а не към памет). Сменихме типа и изтрихме още няколко нода.

Итог

С burstable ресурси в клъстера, вие по-ефективно използвате наличното оборудване, но задавачът на Kubernetes планира подовете въз основа на заявките за ресурси, което може да доведе до проблеми. За да постигнете две цели: да избегнете проблеми и да използвате ресурсите максимално, е необходим добро наблюдение. За това ще ви е полезно Kube Eagle (експортер Prometheus и панел за наблюдение Grafana).

Източник: habr.com