Я створив 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