Від стрибків до економії: оптимізація витрат у Kubernetes

Наш рахунок за AWS зріс на 34% за один квартал. Дорожня карта продукту не передбачала жодних змін. Причина була простою: наші кластери Kubernetes марнували гроші.

Інженери часто вгадують, скільки CPU та пам'яті потрібно сервісу. Вони округлюють значення в більшу сторону для безпеки. Це створює «фантомну» потужність. Ви платите за ресурси, які ваші додатки ніколи не використовують.

Ось як ми це виправили та заощадили 34% щомісячних витрат.

Основна проблема: Requests проти Limits

Requests — це те, що ви гарантуєте. Kubernetes використовує це число, щоб розмістити ваш pod на ноді. Саме це число визначає ваш рахунок.

Limits — це стеля. Якщо pod досягає ліміту CPU, він сповільнюється. Якщо він досягає ліміту пам'яті, він завершує роботу.

Багато команд встановлюють requests рівними limits. Це означає, що ви платите за пікову потужність 24/7, навіть коли ваш сервіс не працює.

Наша стратегія економії

  • Вимірюйте перед дією: використовуйте Prometheus та Grafana, щоб бачити фактичне використання.
  • Використовуйте перцентилі: дивіться на використання p95 протягом 4 тижнів. Не використовуйте середні значення. Середні значення приховують стрибки.
  • Оптимізуйте розмір requests: встановлюйте requests на рівні p95 плюс 20% буфера.
  • Керуйте CPU limits: уникайте занадто жорстких CPU limits для критично важливих сервісів, щоб запобігти тротлінгу.
  • Автоматизуйте масштабування: використовуйте HPA для стрибків трафіку та VPA для налаштування окремих podів.

Результати

Ми зменшили кількість нод з 40 до 26. Середнє використання CPU зросло з 14% до 52%. Щомісячні витрати на обчислення впали з $48,200 до $31,900. Затримка (latency) насправді покращилася на 35%.

Оптимізація — це не разовий проєкт. Це звичка. Якщо ви прописуєте запит на ресурси на основі здогадок, ви марнуєте гроші.

Чекліст для вашого кластера:

• Створіть дашборд, що показує запитані ресурси проти фактичного використання. • Встановлюйте requests на основі даних за 4 тижні. • Запускайте VPA в режимі рекомендацій (recommendation mode), перш ніж дозволяти йому вносити зміни. • Переглядайте специфікації ресурсів щокварталу. • Забезпечте інженерним командам видимість їхніх власних витрат.

Source: https://dev.to/samarth_05/from-spikes-to-savings-practical-k8s-cost-optimization-for-2026-75k

Optional learning community: https://t.me/GyaanSetuAi