Създадох Kube Eagle - износител на Prometheus. Оказа се страхотно нещо, което помага да се разберат по-добре ресурсите на малки и средни клъстери. В крайна сметка спестих стотици долари, защото избрах правилните типове машини и конфигурирах ограничения на ресурсите на приложението за работни натоварвания.
Ще ви разкажа за ползите , но първо ще обясня какво предизвика шума и защо беше необходим висококачествен мониторинг.
Управлявах няколко клъстера от 4–50 възела. Всеки клъстер съдържа до 200 микроуслуги и приложения. За да се използва по-добре съществуващият хардуер, повечето внедрявания бяха конфигурирани с burstable RAM и CPU ресурси. По този начин pods могат да вземат наличните ресурси, ако е необходимо, и в същото време не пречат на други приложения на този възел. Е, не е ли страхотно?
И въпреки че клъстерът консумира сравнително малко CPU (8%) и RAM (40%), постоянно имахме проблеми с изпреварването на подовете, когато се опитваха да разпределят повече памет, отколкото беше налична на възела. Тогава имахме само едно табло за наблюдение на ресурсите на Kubernetes. Като този:
Таблото за управление на Grafana само с показатели на cAdvisor
С такъв панел не е проблем да видите възли, които консумират много памет и процесор. Проблемът е да разберем каква е причината. За да се запазят модулите на място, може, разбира се, да се настроят гарантирани ресурси за всички пакети (заявените ресурси са равни на ограничението). Но това не е най-умното използване на хардуер. Клъстерът имаше няколкостотин гигабайта памет, докато някои възли гладуваха, докато други имаха 4–10 GB в резерв.
Оказва се, че планировчикът на Kubernetes разпределя натоварванията неравномерно между наличните ресурси. Планировчикът на Kubernetes взема предвид различни конфигурации: правила за афинитет, петна и толерации, селектори на възли, които могат да ограничат наличните възли. Но в моя случай нямаше нищо подобно и подовете бяха планирани в зависимост от заявените ресурси на всеки възел.
Възелът, който има най-много безплатни ресурси и който отговаря на условията на заявката, беше избран за групата. Установихме, че заявените ресурси на възлите не съответстват на действителното използване и тук Kube Eagle и неговите възможности за наблюдение на ресурсите дойдоха на помощ.
Имам почти всички Kubernetes клъстери, наблюдавани само с и . Node Exporter предоставя статистически данни за I/O и използването на диск, CPU и RAM, докато Kube State Metrics показва обектни показатели на Kubernetes, като заявки и ограничения на ресурсите на CPU и памет.
Трябва да комбинираме показателите за използване с показателите за заявки и ограничения в Grafana и тогава ще получим цялата информация за проблема. Това звучи просто, но двата инструмента всъщност назовават етикетите по различен начин и някои показатели изобщо нямат етикети за метаданни. Kube Eagle прави всичко сам и панелът изглежда така:
Успяхме да разрешим много проблеми с ресурсите и да спестим оборудване:
- Някои разработчици не знаеха от колко ресурси се нуждаят микроуслугите (или просто не си направиха труда). Нямаше начин да намерим неправилни заявки за ресурси - за това трябва да знаем потреблението плюс заявките и лимитите. Сега те виждат показателите на Prometheus, наблюдават действителното използване и коригират заявките и лимитите.
- JVM приложенията отнемат толкова RAM, колкото могат да обработват. Събирачът на отпадъци освобождава памет само когато се използват повече от 75%. И тъй като повечето услуги имат разрушаваща се памет, тя винаги е била заета от JVM. Следователно всички тези Java услуги изяждаха много повече RAM от очакваното.
- Някои приложения поискаха твърде много памет и планировчикът на Kubernetes не даде тези възли на други приложения, въпреки че всъщност те бяха по-свободни от други възли. Един разработчик случайно добави допълнителна цифра в заявката и грабна голямо парче RAM: 20 GB вместо 2. Никой не забеляза. Приложението имаше 3 реплики, така че бяха засегнати до 3 възела.
- Въведохме ограничения на ресурсите, пренасрочихме подове с правилните заявки и получихме идеален баланс на използване на хардуер във всички възли. Няколко възела можеха да бъдат напълно затворени. И тогава видяхме, че имаме грешни машини (ориентирани към процесора, а не към паметта). Променихме типа и изтрихме още няколко възела.
Резултати от
С експлозивни ресурси в клъстера вие използвате наличния хардуер по-ефективно, но планировчикът на Kubernetes планира модули въз основа на заявки за ресурси, а това е изпълнено с проблеми. За да убиете два заека с един камък: за да избегнете проблеми и да използвате максимално ресурсите, имате нужда от добър мониторинг. Ето защо ще бъде полезно (Prometheus exporter и Grafana dashboard).
Източник: www.habr.com