CASE STUDY // KUBERNETES OPTIMIZATION

Как мы сократили стоимость
Kubernetes на 40%

Детальный разбор кейса: от гиперпроvisioning'а до автоматизации ресурсов через VPA. Инженерная точность в мире данных.

Клиент FinTech Core Systems

Стек K8s, Prometheus, Go

Дата 14 Октября 2023

Проблема: Over-provisioning

Клиент эксплуатировал кластер из 45 нод в Yandex Cloud. Основная проблема заключалась в ручном выставлении лимитов ресурсов (Requests/Limits) для подов.

DevOps-инженеры, стремясь избежать OOMKilled ошибок, завышали лимиты в 3-4 раза относительно реального потребления. Это приводило к эффекту "раздувания" кластера: планировщик K8s резервировал ресурсы, которые на самом деле простаивали, но за которые приходилось платить.

➜ Средняя утилизация CPU: 12%
➜ Средняя утилизация RAM: 18%
➜ Ежемесячный счет: 1.2M RUB

Схема проблемы с распределением ресурсов в кластере Kubernetes

Методология: Внедрение VPA

Мы отказались от ручного тюнинга в пользу данных. Основой решения стал Vertical Pod Autoscaler (VPA), интегрированный с Prometheus.

VPA анализирует историю потребления ресурсов и предлагает оптимальные значения requests и limits. Однако, простое включение VPA может привести к нестабильности. Мы применили гибридный подход:

01.

Анализ исторических данных

Сбор метрик за 30 дней через Prometheus. Выявление "хвостовых" пиков нагрузки (P99), чтобы не жертвовать производительностью ради экономии.

02.

Режим "Recommendation"

Запуск VPA в режиме, где он не перезапускает поды, а выдает рекомендации. Это позволило команде DevOps оценить безопасность изменений.

03.

Пост-градиентное внедрение

Переход в режим "Auto" только для не-критичных микросервисов (бэкенды, крон-задачи), с последующим rollout на ядро системы.

Результаты и метрики

Через 4 недели после стабилизации конфигурации мы зафиксировали следующие показатели:

40% Снижение затрат (Cost)

68% Утилизация CPU

-18 Нод в кластере (Nodes)

0 Incidents (OOMKilled)

График потребления (CPU Cores)

BEFORE (Allocated)

AFTER (Optimized)

Синий столбец — реальный запрос ресурсов после настройки VPA. Серый — предыдущий "запасной" объем.

Техническая реализация

Ключевым моментом стало правильное конфигурирование манифеста VPA. Мы использовали стратегию Auto с настройкой updateMode: "Auto".

vpa-config.yaml YAML

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: backend-api-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       backend-api
  updatePolicy:
    updateMode: "Auto" 
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: "2"
        memory: 2Gi
      controlledResources: ["cpu", "memory"]

Best Practices

При внедрении VPA критически важно задать minAllowed и maxAllowed. Без этих ограничений VPA может снизить ресурсы до уровня, критичного для старта приложения (Cold Start), или, наоборот, разрешить монополизацию ноды одним подом.

Также мы рекомендуем отключать VPA для StatefulSet'ов с жестким требованием к стабильности IP и диска, используя для них статические лимиты на основе P99.

Готовы оптимизировать
вашу инфраструктуру?

Не позволяйте неэффективным настройкам сжигать бюджет. Проведите аудит с экспертами ПингКит.

Заказать аудит Связаться с инженером

Связь с нами

Технический отдел

tech@pingkit.ru

Москва, Пресненская наб., 12
Башня Федерация

Как мы сократили стоимость Kubernetes на 40%