Ваш кластер Kubernetes теряет деньги: вот как это остановить

99,94% кластеров имеют избыточное выделение ресурсов. Вот как присоединиться к тем 0,06%, которые этого не делают.

Я с недоверием смотрел на наш счет за облачные услуги. У нас работал скромный кластер Kubernetes из 50 подов на десяти узлах, и каким-то образом мы тратили больше, чем команды, у которых нагрузка была втрое больше. Хуже всего то, что я понятия не имел, куда уходят деньги.

Звучит знакомо?

После нескольких месяцев расследований я обнаружил горькую правду: мы платили за ресурсы, которые никогда не использовали. И, согласно отчету Cast AI 2025 Kubernetes Cost Benchmark Report, не мы одни. Поразительные 99,94% кластеров Kubernetes имеют избыточное выделение ресурсов.

Задумайтесь над этим. Практически каждый кластер Kubernetes, работающий сейчас в производственной среде, тратит деньги впустую.

Скрытый налог, который вы платите каждый месяц

Вот что на самом деле показывают данные сравнительного анализа:

• Средняя загрузка CPU: 10%
• Средний уровень использования памяти: 23%
• Разница в избыточном выделении ресурсов: в 8 раз больше запрошенного, чем фактически использованного объема.

Это значит, что на каждый доллар, потраченный на вычислительные ресурсы, примерно 75 центов уходит на простаивающие ресурсы. По оценкам BCG, до 30% всех расходов на облачные сервисы расходуются таким образом впустую. Для многих организаций это миллионы долларов в год.

Но вот в чем дело: это не из-за небрежности инженеров. Сама система спроектирована так, чтобы такое происходило.

Почему мы выделяем слишком много ресурсов (и почему это абсолютно рационально)

Вспомните, когда вы в последний раз запрашивали ресурсы для развертывания. Что вы тогда подумали?

Если вы похожи на большинство инженеров, это было что-то вроде: «Я точно не знаю, что именно нужно, но я точно не хочу, чтобы программа зависла. Лучше запросить больше, чем меньше».

Это совершенно рациональное поведение. Последствия недостаточного выделения ресурсов немедленны и болезненны:

• Поды подвергаются ограничению скорости.
• Приложения замедляются
• Ошибка нехватки памяти убивает ваши сервисы
• Инженер на дежурстве получает уведомление в 3 часа утра

Последствия избыточного выделения ресурсов? Абстрактное число в счете, которое может когда-нибудь проверить чья-то команда… в будущем.

Поэтому мы добавляем буферы. Довольно щедрые. Исследования показывают, что среднее избыточное выделение CPU составляет 40%, а памяти — 57%. И 59% контейнеров вообще не имеют установленных лимитов CPU, то есть верхней границы нет.

Страх перед проблемами с производительностью создает замкнутый круг, ведущий к расточительству.

Пятишаговая методика решения этой проблемы

Я подробно расскажу вам о процессе, который помог нам сократить расходы на Kubernetes на 47% за шесть недель. Никакой магии, никаких дорогостоящих консультантов, просто систематическое применение уже существующих инструментов и практик.

Шаг 1: Обеспечьте видимость (Нельзя исправить то, чего не видишь)

Прежде чем что-либо оптимизировать, необходимо понять, на что вы фактически тратите деньги и куда.

Разверните OpenCost или Kubecost в своем кластере. Эти инструменты обеспечивают распределение ресурсов по пространствам имен и рабочим нагрузкам, напрямую соотнося с командами и продуктами.

# Install OpenCost via Helm
helm install opencost opencost/opencost \
  --namespace opencost-system \
  --create-namespace

Фонд FinOps рекомендует использовать метод «демонстрации результатов» в качестве первого шага для изменения поведения. Когда команды могут точно видеть, во сколько обходится их работа, происходит нечто интересное: они начинают проявлять интерес.

Быстрый способ добиться успеха: стандартизировать метки Kubernetes для распределения затрат. Как минимум, каждая рабочая нагрузка должна иметь: app, team, env, и cost-centre. Это единственное изменение превратит ваши данные о выставлении счетов из шума в полезную информацию.

Шаг 2: Оптимизируйте рабочую нагрузку

Именно здесь кроется настоящая экономия.

Goldilocks — это инструмент с открытым исходным кодом, который отслеживает ваши рабочие нагрузки и рекомендует оптимальные настройки ресурсов на основе фактического использования:

# Install Goldilocks
helm install goldilocks fairwinds-stable/goldilocks \
 --namespace goldilocks \
 --create-namespace
# Enable monitoring for a namespace
kubectl label ns your-namespace goldilocks.fairwinds.com/enabled=true

После нескольких дней сбора данных Goldilocks предоставляет рекомендации через панель управления. В нашем случае он выявил поды, которые запрашивали 4 ядра CPU, но фактически использовали 0,3.

Формула подбора оптимального размера:

• Установите количество запросов на уровне 95-го процентиля фактического использования.
• Установите лимиты памяти равными запросам на использование памяти (это предотвратит неожиданные ошибки нехватки памяти).
• Рассмотрите возможность полного снятия ограничений на использование ЦП, поскольку они часто приносят больше вреда, чем пользы, из-за чрезмерного снижения производительности.

Зачем снимать ограничения на использование CPU? CPU — это «сжимаемый» ресурс. Когда контейнер превышает свой лимит, его производительность снижается, а не завершается. Это звучит разумно, пока вы не поймете, что снижение производительности может привести к скачкам задержки, которые невероятно сложно отлаживать.

Если у вас нет особых причин ограничивать использование CPU, позволяйте контейнерам увеличивать свою производительность, когда появляется достаточно ресурсов.

Шаг 3: Внедрите автомасштабирование (правильным образом)

Большинство команд используют Horizontal Pod Autoscaler (HPA), но оставляют многое без внимания.

Настройте масштабирование автопарсинга по уровням:

1. HPA масштабирует поды горизонтально на основе метрик
2. VPA (Vertical Pod Autoscaler) автоматически корректирует запросы на ресурсы.
3. Cluster Autoscaler или Karpenter регулируют количество узлов

Особого внимания заслуживает Karpenter. В отличие от Cluster Autoscaler, он выделяет узлы в режиме реального времени на основе ожидающих запросов на поды, автоматически выбирая наиболее экономически эффективные типы экземпляров:

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: "kubernetes.io/arch"
      operator: In
      values: ["amd64", "arm64"]
    - key: "karpenter.sh/capacity-type"
      operator: In
      values: ["spot", "on-demand"]
  limits:
    resources:
      cpu: 1000

Обратите внимание на варианты ARM64 и Spot-экземпляров. Организации, использующие сочетание различных архитектур и Spot-экземпляров, отмечают среднюю экономию в 59%. Azure сообщает об экономии до 65% только за счет процессоров ARM.

Шаг 4: Автоматизируйте рутинные задачи

Вот где, на мой взгляд, большинство инициатив в сфере финансовых операций заходят в тупик: они генерируют отличные рекомендации, которые никто не принимает во внимание.

Традиционные инструменты часто предоставляют рекомендации без автоматизации, оставляя командам необходимость вручную корректировать настройки ресурсов. Это приводит к формированию списка задач, приоритеты в котором никогда не отдаются разработке новых функций.

Решение? Автономные платформы оптимизации.

Такие инструменты, как CAST AI и Sedai, не просто дают рекомендации, они действуют. Они непрерывно анализируют ваши нагрузки и вносят корректировки в реальном времени с соответствующими ограничениями:

• Автоматическая компоновка подов для максимального использования узлов
• Интеллектуальное планирование для предотвращения фрагментации
• Проактивное масштабирование на основе прогнозируемого (а не только текущего) спроса.

Для команд, которым некомфортно работать с полной автоматизацией, эти инструменты могут сначала работать в «режиме рекомендаций». Но настоящая экономия приходит при полном автономном режиме.

Шаг 5: Управление и обеспечение устойчивого развития

Оптимизация затрат — это не проект, а практика.

Внедрите ограничения:

• Для всех производственных нагрузок необходимо запрашивать ресурсы (используйте OPA Gatekeeper или Kyverno).
• Установите квоты ресурсов на уровне пространства имен.
• Просматривайте панели мониторинга затрат на еженедельных совещаниях команды.
• Создавайте оповещения в Slack/Teams о нетипичных расходах.

# Example: Block deployments without resource requests
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-requests
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-requests
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "CPU and memory requests are required"
      pattern:
        spec:
          containers:
          - resources:
              requests:
                memory: "?*"
                cpu: "?*"

Концепция FinOps Foundation (Информирование, Оптимизация, Эксплуатация) идеально подходит для Kubernetes. Начните с обеспечения прозрачности, применяйте целенаправленные исправления, а затем выстройте систему управления, чтобы экономия сохранялась.

Быстрые победы на этой неделе

Если вы хотите быстро увидеть результаты, сосредоточьтесь на этих эффективных действиях:

1. Устраните «зомби-нагрузки» в непроизводственной среде: масштабируйте dev/staging до нуля вне рабочего времени.
2. Объедините балансировщики нагрузки: каждый LoadBalancer создает облачные ресурсы; используйте Ingress
3. Удалите неиспользуемые PVC: затраты на хранение данных накапливаются; найдите и удалите оставшиеся тома
4. Проанализируйте телеметрию с высокой кардинальностью: затраты на наблюдаемость могут быть сопоставимы с вычислительными; оптимизируйте метрики.

Большинство команд добиваются ощутимого снижения показателей в течение двух недель, сосредоточившись на этих четырех областях.

Настоящий урок

Вот что я понял, взяв под контроль наши расходы: с технологиями никогда не было сложно.

Самым сложным было обеспечить прозрачность и подотчетность. Как только команды смогли видеть свои затраты и поняли, что за ними следят, поведение изменилось естественным образом. Инженеры начали спрашивать: «Нужно ли нам это?», прежде чем запускать ресурсы. Оптимизация ресурсов стала частью контрольного списка развертывания, а не второстепенным вопросом.

Статистика в 99,94% ужасает, но она также открывает возможности. В вашем кластере Kubernetes почти наверняка скрываются значительные потери. Инструменты для обнаружения и устранения этих потерь являются зрелыми, бесплатными или недорогими и проверенными на практике.

Вопрос лишь в том, собираетесь ли вы что-нибудь с этим предпринять.

Готовы начать? На этой неделе разверните OpenCost, включите функцию Goldilocks для одного пространства имен и проведите анализ затрат со своей командой. Гарантирую, вас ждут сюрпризы.

Эти кластеры, составляющие 0,06%, не возникли случайно. Они достигли этого, сделав повышение экономической эффективности частью своей деятельности. Вы тоже можете это сделать.