От скачков к экономии: оптимизация затрат в Kubernetes

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

Инженеры часто пытаются угадать, сколько CPU и памяти требуется сервису. Они округляют значения в большую сторону для подстраховки. Это создает «фантомную» мощность. Вы платите за ресурсы, которые ваши приложения никогда не используют.

Вот как мы это исправили и сэкономили 34% ежемесячных расходов.

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

Requests — это то, что вы гарантируете. Kubernetes использует это значение, чтобы разместить ваш pod на узле (node). Именно это значение формирует ваш счет.

Limits — это потолок. Если pod достигает лимита CPU, он замедляется. Если он достигает лимита памяти, он завершается.

Многие команды устанавливают requests равными limits. Это означает, что вы платите за пиковую мощность 24/7, даже когда ваш сервис простаивает.

Наша стратегия экономии

  • Измеряйте перед тем, как действовать: используйте Prometheus и Grafana, чтобы видеть фактическое потребление.
  • Используйте перцентили: смотрите на использование p95 за 4 недели. Не используйте средние значения. Средние значения скрывают скачки.
  • Оптимизируйте размер requests: устанавливайте requests на уровне p95 плюс 20% буфера.
  • Управляйте CPU limits: избегайте слишком жестких лимитов CPU для критически важных сервисов, чтобы предотвратить троттлинг (throttling).
  • Автоматизируйте масштабирование: используйте HPA для скачков трафика и VPA для настройки отдельных подов.

Результаты

Мы сократили количество узлов с 40 до 26. Средняя загрузка CPU выросла с 14% до 52%. Ежемесячные расходы на вычисления снизились с $48,200 до $31,900. Задержка (latency) фактически улучшилась на 35%.

Оптимизация — это не разовый проект. Это привычка. Если вы прописываете запрос ресурсов (resource request) наугад, вы тратите деньги впустую.

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

• Создайте дашборд, показывающий запрошенные vs фактические ресурсы. • Устанавливайте 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