Огляд Kubecost для економії коштів на Kubernetes у хмарах

В даний час все більше компаній переводять свою інфраструктуру із залізних серверів та власних віртуалок у хмари. Таке рішення легко пояснити: немає необхідності дбати про залізо, кластер легко конфігурується безліччю різних способів… а найголовніше — існуючі технології (на зразок Kubernetes) дозволяють просто масштабувати обчислювальні потужності залежно від навантаження.

Завжди важливим є і фінансовий аспект. Інструмент, про який йтиметься в цій статті, покликаний сприяти скороченню бюджетів при використанні хмарної інфраструктури з Kubernetes.

Запровадження

Kubecost - Каліфорнійський стартап від вихідців з Google, що створює рішення для підрахунку витрат на інфраструктуру в хмарних сервісах (всередині кластера Kubernetes + спільні ресурси), пошуку вузьких місць у налаштуваннях кластера та відправлення відповідних повідомлень до Slack.

У нас є клієнти з Kubernetes як у звичних хмарах AWS і GCP, так і більш рідкісним для Linux-спільноти Azure — загалом, на всіх платформах, які підтримує Kubecost'. Для деяких з них ми вважаємо витрати з внутрішньокластерних сервісів самостійно (за методикою, схожою на ту, що використовує Kubecost), а також слідкуємо за витратами на інфраструктуру і намагаємося їх оптимізувати. Тому логічно, що нас зацікавила можливість автоматизувати такі завдання.

Вихідний код основного модуля Kubecost відкрито на умовах Open Source-ліцензії (Apache License 2.0). Його можна використовувати вільно, а доступних функцій має бути достатньо для невеликих проектів. Однак бізнес є бізнес: решта продукту закрита, їй можна скористатися по платним підпискам, які також мають на увазі комерційну підтримку. Крім того, автори пропонують безкоштовну ліцензію для невеликих кластерів (1 кластер із 10 вузлами — за час написання статті цей ліміт розширився до 20 вузлів) або trial-період із повними можливостями на 1 місяць.

Як все влаштовано

Отже, основна частина Kubecost – це додаток cost-modelнаписана на Go. Helm-чарт, що описує всю систему цілком, називається cost-analyzer і за своєю суттю є збіркою з cost-model з Prometheus, Grafana та кількома dashboard'ами.

Взагалі кажучи, у cost-model є свій веб-інтерфейс, який показує графіки та детальну статистику щодо витрат у табличному вигляді, а також, звичайно, поради щодо оптимізації витрат. Представлені ж у Grafana dashboard'и є більш раннім етапом розвитку Kubecost і містять багато в чому ті ж дані, що й cost-model, доповнюючи їх звичною статистикою з витрат CPU/пам'яті/мережі/дискового простору в кластері та його складових.

Як працює Kubecost?

• Cost-model через API хмарних постачальників отримує ціни на обслуговування.
• Далі, залежно від залізного типу вузла та регіону, вважається вартість по вузлах.
• На основі вартості роботи вузлів кожен кінцевий pod отримує вартість за годину використання процесора, витрати гігабайта пам'яті та вартість години зберігання гігабайта даних - залежно від вузла, на якому він працював, або класу сховища.
• Виходячи з вартості роботи окремих pod'ів вважається оплата за просторами імен, сервісів, Deployment'ам, StatefulSet'ам.
• Для підрахунку статистики використовуються метрики, що надаються kube-state-metrics та node-exporter.

Важливо враховувати, що Kubecost за замовчуванням вважає лише ресурси, доступні в Kubernetes. Зовнішні бази даних, сервери GitLab, сховища S3 та інші сервіси, відсутні в кластері (нехай і знаходяться в тій же хмарі), для нього не видно. Хоча для GCP та AWS можна додати ключі своїх сервіс-акаунтів та порахувати все разом.

Встановлення

Для функціонування Kubecost потрібні:

• Kubernetes версії 1.8 та вище;
• kube-state-metrics;
• Prometheus;
• node-exporter.

Так склалося, що в наших кластерах всі ці умови були дотримані заздалегідь, тому виявилося достатнім лише вказати правильний пункт для доступу в Prometheus. Тим не менш, офіційний Helm-чарт kubecost містить у собі все необхідне, щоб запуститися і на голому кластері.

Встановити Kubecost можна кількома способами:

1. Стандартний спосіб встановлення, описаний у інструкції на сайті розробника. Необхідно додати до Helm репозиторій cost-analyzer, після чого встановити чарт. Залишиться лише прокинути собі порт і допиляти налаштування до бажаного стану вручну (через kubectl) та/або за допомогою веб-інтерфейсу cost-model.

   Даний спосіб ми навіть не пробували, оскільки не використовуємо сторонні готові конфігурації, проте він виглядає як хороший варіант просто спробувати для себе. Якщо ж у вас вже встановлена ​​частина компонентів системи або ви хочете більш тонкого налаштування, краще розглянути другий шлях.

2. Використовувати по суті той же чарт, але самостійно конфігурувати та встановити його будь-яким зручним способом.

   Як уже згадувалося, крім власне kubecost'а цей чарт містить чарти Grafana та Prometheus, які також можна налаштувати за своїм бажанням.

   Є в чарті values.yaml для cost-analyzer дозволяє настроювати:

   • перелік компонентів cost-analyzer, які потрібно розгорнути;
   • свій endpoint для Prometheus (якщо він у вас вже є);
   • домени та інші настройки ingress'ів для cost-model та Grafana;
   • анотації для pod'ів;
   • необхідність використання постійних сховищ та їх розмір.

   Повний список доступних опцій конфігурування з описом є в документації.

   Оскільки kubecost у базовому варіанті не вміє обмежувати доступ, потрібно відразу налаштувати basic-auth для веб-панелі.

3. встановити тільки ядро ​​системи - Cost-model. Для цього необхідно мати в кластері встановлений Prometheus і вказати відповідне значення його адреси у змінній prometheusEndpoint для Helm'а. Після цього застосувати набір YAML-конфігурацій у кластері.

   Знову ж таки, доведеться вручну додати Ingress з basic-auth. І нарешті, потрібно додати секцію для збору метрик cost-model в extraScrapeConfigs у конфізі Prometheus:

   - job_name: kubecost
     honor_labels: true
     scrape_interval: 1m
     scrape_timeout: 10s
     metrics_path: /metrics
     scheme: http
     dns_sd_configs:
     - names:
       - <адрес вашего сервиса kubecost>
       type: 'A'
       port: 9003

Що отримуємо?

При повноцінній установці у нашому розпорядженні виявляється веб-панель kubecost та Grafana з набором dashboard'ів.

Загальна вартість, що відображається на головному екрані, фактично показує розрахункову вартість ресурсів протягом місяця. Це прогнозована ціна, що відображає вартість використання кластера (на місяць) за поточного рівня споживання ресурсів.

Ця метрика — більше для аналізу витрат та їхньої оптимізації. Загальні витрати за абстрактний липень у Kubecost дивитися не дуже зручно: за цим доведеться йти в білінг. Зате можна подивитися витрати з розбивкою по просторах імен, лейблам, pod'ам за 1/2/7/30/90 днів, чого білінг вам ніколи не покаже.

До слова про лейблах. Варто відразу зайти в налаштування та виставити назви лейблів, які будуть використовуватись як додаткові категорії для угруповання витрат:

Лейбли на них можна повісити будь-які зручно, якщо у вас вже існує своя система маркування.

Також там можна змінити адресу API endpoint'а, до якої підключається cost-model, налаштувати розмір знижки в GCP і виставити власні ціни на ресурси та валюту для їх виміру (фіча чомусь не впливає на Total cost).

Kubecost вміє показувати різні проблеми у кластері (і навіть алертити у разі небезпеки). На жаль, опція не налаштовується, а тому якщо у вас є оточення для розробників і вони використовуються, можна буде постійно спостерігати щось подібне:

Важливий інструмент Cluster Savings. Він вимірює активність pod'ів (споживання ресурсів, у тому числі і мережевих), а також вважає, скільки грошей і на чому можна заощадити.

Може здатися, що поради щодо оптимізації досить очевидні, проте досвід підказує, що все одно є до чого придивитися. Зокрема, відстежується мережна активність pod'ів (Kubecost пропонує звернути увагу на неактивних), порівнюється запитана і реальна витрата пам'яті та CPU, а також CPU, що використовується вузлами кластера (пропонує згорнути кілька вузлів в один), навантаження на диски та ще кілька десятків параметрів.

Як і в будь-якому питанні щодо оптимізації, до оптимізації ресурсів на основі даних Kubecost потрібно ставитися з обережністю. Наприклад, Cluster Savings пропонує видалити вузли, стверджуючи, що це безпечно, проте не враховує наявність у розгорнутих на них pod'у node-selector'ів і taint'ів, що не є на інших вузлах. Та й взагалі, навіть автори продукту у своїй недавній статті (До речі, вона може виявитися дуже корисною тим, хто цікавиться темою проекту) рекомендують не кидатися з головою в оптимізацію витрат, а підходити до питання обдумано.

Підсумки

Після використання Kubecost протягом місяця на парі проектів можемо зробити висновок, що це цікавий (а ще легкий в освоєнні та встановленні) інструмент для аналізу та оптимізації витрат на послуги хмарних провайдерів, які використовуються для Kubernetes-кластерів. Підрахунки виходять дуже точними: у наших експериментах вони збігалися з тим, що насправді вимагали провайдери.

Не обійшлося і без мінусів: є некритичні баги, функціональні можливості подекуди не покривають специфічних для деяких проектів потреб. Однак, якщо потрібно швидко зрозуміти, куди йдуть гроші і що можна «порізати», щоби стабільно знизити рахунок за хмарні послуги на 5-30% (так і сталося у нашому випадку), — це відмінний варіант.

PS

Читайте також у нашому блозі:

• «Автомасштабування та керування ресурсами в Kubernetes (огляд та відео доповіді)»;
• «Kubernetes-пригода Dailymotion: створення інфраструктури в хмарах + on-premises»;
• «Kubernetes tips & tricks: про виділення вузлів та про навантаження на веб-додаток».

Джерело: habr.com