Оптимизация затрат на Kubernetes в 2026: руководство по FinOps для контейнерных нагрузок

Введение: почему оптимизация затрат на Kubernetes — критический приоритет в 2026 году

В 2026 году мировые расходы на публичные облачные сервисы уверенно преодолели отметку в триллион долларов. Компании всех масштабов — от стартапов до корпораций — продолжают мигрировать нагрузки в облако, и Kubernetes стал фактическим стандартом оркестрации контейнеров. По различным оценкам, более 75% организаций уже используют Kubernetes в продакшене.

Но вот в чём проблема.

От 30 до 35% всех облачных расходов — это чистое расточительство. Деньги, которые утекают на простаивающие ресурсы, переразмеренные инстансы и отсутствие автоматизации. А в контейнерных средах ситуация ещё печальнее — по данным отраслевых исследований, до 80% расходов на контейнерные вычисления приходится на ресурсы, которые никто не использует. Давайте это осмыслим: четыре из пяти долларов, потраченных на контейнеры, могли бы остаться в вашем бюджете.

При этом 60–70% виртуальных машин, используемых в качестве узлов Kubernetes, переразмерены. Команды запрашивают гораздо больше CPU и памяти, чем реально потребляют их приложения. По моему опыту, это самая распространённая (и одновременно самая простая для исправления) причина перерасхода в контейнерных средах.

Если вы уже читали наше руководство по Reserved Instances, Savings Plans и CUD, вы знаете, как снизить стоимость вычислительных ресурсов через обязательства. Но обязательства работают на уровне инфраструктуры — они не решают проблему неэффективного использования ресурсов внутри самих Kubernetes-кластеров. Эта статья как раз заполняет этот пробел: мы разберём все ключевые механизмы оптимизации затрат именно на уровне Kubernetes.

Почему Kubernetes создаёт уникальные проблемы с затратами

Kubernetes — мощная платформа, но с точки зрения управления затратами она создаёт целый набор уникальных сложностей, которых просто не существует в традиционных VM-средах. Итак, давайте разберёмся, в чём тут дело.

Общие ресурсы и мультиарендность

В Kubernetes десятки и сотни подов разделяют одни и те же физические узлы. Когда на одном сервере работают приложения трёх разных команд, как корректно разнести стоимость этого сервера между ними? Задача нетривиальная, и большинство организаций решают её плохо. Или не решают вовсе.

Слои абстракции скрывают реальные затраты

Kubernetes добавляет несколько уровней абстракции между приложением и инфраструктурой: поды, деплойменты, неймспейсы, ноды, нодпулы. Каждый уровень скрывает часть картины. Разработчик, который создаёт Deployment, часто не знает (и, честно говоря, не задумывается), на какой машине он будет запущен и сколько эта машина стоит. По сути, это и есть цель Kubernetes — абстрагировать инфраструктуру. Но побочный эффект — полная потеря видимости затрат.

Эфемерные нагрузки

Контейнеры создаются и уничтожаются за секунды. CronJob может запуститься на 5 минут, сожрать кучу ресурсов, а потом исчезнуть. CI/CD-пайплайны генерируют десятки подов, каждый из которых живёт считаные минуты. Отслеживание затрат на такие эфемерные нагрузки — задача совершенно другого порядка сложности по сравнению с мониторингом стоимости постоянно работающей виртуалки.

Сложность аллокации затрат по командам

В VM-мире всё просто: вот эта виртуалка принадлежит команде А, вот эта — команде Б. Стоимость прозрачна. В Kubernetes один узел может обслуживать поды десятка разных команд и проектов. А ещё DaemonSets, системные компоненты (kube-system), общие сервисы вроде Istio и мониторинга создают «общие» затраты, которые нужно как-то распределять. Без продуманной стратегии лейблинга и инструментов аллокации вы просто не будете знать, кто и сколько тратит.

Разрыв между requests и реальным потреблением

Это, пожалуй, главная финансовая проблема Kubernetes. Команды устанавливают resource requests при деплое приложения — и потом никогда их не пересматривают. Результат? Гигантский разрыв между запрошенными и реально используемыми ресурсами. А платите вы именно за запрошенные. Вот почему оптимизация requests — это первое, с чего стоит начать.

Правильная настройка ресурсов: requests и limits

Resource requests и limits — это фундамент управления ресурсами в Kubernetes и ключевой механизм контроля затрат. Если вы не настроите их правильно, все остальные оптимизации будут стоять на шатком фундаменте.

Requests vs Limits: в чём разница

Requests — это количество CPU и памяти, которое Kubernetes гарантирует поду. Scheduler использует requests для размещения подов на узлах. Если под запрашивает 500m CPU и 256Mi памяти, scheduler найдёт узел, где есть хотя бы столько свободных ресурсов. Именно по requests определяется, сколько подов поместится на узел, и по сути именно requests определяют ваши затраты.

Limits — это максимальный потолок, который под не может превысить. Если под пытается использовать больше CPU, чем указано в limit, он будет троттлиться (throttling). Превышает limit по памяти — получает OOMKilled. Limits защищают от «шумных соседей», но не влияют на scheduling.

Классы качества обслуживания (QoS)

Kubernetes назначает каждому поду класс QoS на основе настройки requests и limits:

• Guaranteed — requests равны limits для всех контейнеров. Под получает гарантированные ресурсы и имеет наивысший приоритет при нехватке ресурсов на узле. Это правильный выбор для критически важных продакшен-нагрузок.
• Burstable — requests установлены, но limits выше (или не указаны вовсе). Под может использовать больше ресурсов, чем запрошено, если они доступны. Хороший выбор для большинства нагрузок с переменной интенсивностью.
• BestEffort — ни requests, ни limits не установлены. Этот под будет первым кандидатом на вытеснение при нехватке ресурсов. Используйте только для некритичных задач, которые легко перезапустить.

Типичные ошибки

По моему опыту, вот самые распространённые ошибки при настройке ресурсов:

1. Массовое переразмерение requests — команды устанавливают CPU request в 1000m (1 ядро), когда приложение реально использует 100–200m. Самая дорогая ошибка: вы платите за ресурсы в 5 раз больше, чем потребляете.
2. Отсутствие limits — без limits один «сбесившийся» контейнер может сожрать все ресурсы узла и вызвать каскадные сбои соседних подов.
3. Одинаковые requests для всех сред — production, staging и development используют одни и те же значения. Зачем? В dev-среде вполне хватает 25–50% от продакшен-значений.
4. Requests установили и забыли — профиль потребления приложения меняется со временем, а requests остаются прежними. Это как купить костюм и никогда не перешивать, даже если вы похудели на 20 кг.

Практический пример: правильно настроенный под

Вот пример правильной конфигурации для типичного веб-приложения:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
  namespace: production
  labels:
    app: web-api
    team: backend
    cost-center: platform
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
        team: backend
        cost-center: platform
    spec:
      containers:
      - name: web-api
        image: myregistry/web-api:v2.4.1
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Обратите внимание на несколько важных моментов:

• CPU request (250m) составляет половину от limit (500m) — это даёт возможность burst'а при пиках, при этом QoS класс будет Burstable.
• Memory request (256Mi) тоже составляет половину от limit (512Mi). Для Java-приложений, кстати, рекомендуется устанавливать request ближе к limit, так как JVM обычно потребляет стабильное количество памяти.
• Лейблы team и cost-center нужны для аллокации затрат — об этом подробнее ниже в разделе про showback/chargeback.

Автоскейлинг: HPA, VPA и KEDA

Статически настроенные ресурсы — это хорошо, но недостаточно. Реальные нагрузки варьируются во времени: днём трафик выше, ночью ниже; в пятницу пик, в выходные спад. Автоскейлинг позволяет автоматически адаптировать ресурсы к текущей нагрузке — избегая как перерасхода, так и деградации производительности.

HPA: горизонтальное масштабирование подов

Horizontal Pod Autoscaler (HPA) — встроенный механизм Kubernetes, который автоматически изменяет количество реплик деплоймента в зависимости от метрик. Самый распространённый триггер — загрузка CPU, но HPA поддерживает и кастомные метрики: RPS, длина очереди, latency.

Пример конфигурации HPA с кастомными метриками:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-api-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60

Разберём ключевые настройки:

• stabilizationWindowSeconds для scaleDown — 300 секунд (5 минут). Это защита от преждевременного скейлдауна. Без неё HPA может начать удалять поды сразу после кратковременного снижения нагрузки, а потом судорожно создавать их снова.
• Политика scaleDown: 25% за 60 секунд — HPA не удалит больше четверти подов за минуту. Предотвращает резкое сокращение, которое может вызвать кратковременную деградацию.
• Политика scaleUp: 50% за 60 секунд — при росте нагрузки HPA действует агрессивнее, чем при снижении. И это правильно: лучше быстро отреагировать на всплеск, чем подвергать пользователей тормозам.

VPA: вертикальное масштабирование

Vertical Pod Autoscaler (VPA) решает другую задачу — он автоматически корректирует requests и limits для контейнеров на основе реального потребления. Если ваш контейнер запрашивает 1 CPU, а реально использует 200m, VPA обнаружит это и предложит (или автоматически применит) более экономичные значения.

По различным оценкам, VPA в режиме рекомендаций позволяет сократить расходы на вычислительные ресурсы на 20–40%. Просто за счёт приведения requests в соответствие с реальным потреблением. Никакой магии.

VPA поддерживает несколько режимов работы:

• "Off" — VPA только собирает данные и формирует рекомендации, ничего не применяя. Рекомендуемый режим для начала — позволяет оценить потенциал экономии без какого-либо риска.
• "Initial" — VPA применяет рекомендации только при создании новых подов, но не трогает существующие.
• "Auto" — VPA автоматически обновляет requests и limits, перезапуская поды при необходимости. С этим режимом нужна аккуратность.

Пример конфигурации VPA в режиме рекомендаций:

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

Важное ограничение VPA: для применения новых значений requests VPA перезапускает под. Для stateless-сервисов с несколькими репликами это обычно не проблема — PodDisruptionBudget гарантирует, что не все поды перезапустятся одновременно. Но для stateful-нагрузок или singleton-сервисов это может оказаться неприемлемо.

Практический совет: начните с режима "Off", соберите рекомендации за 1–2 недели, проанализируйте их и вручную примените для самых переразмеренных деплойментов. Только убедившись в адекватности рекомендаций, переключайтесь на "Auto" — и то только для некритичных нагрузок.

KEDA: событийно-управляемый автоскейлинг

KEDA (Kubernetes Event-Driven Autoscaling) — проект CNCF, который расширяет стандартный HPA событийно-управляемым масштабированием. В чём главное отличие? HPA работает на основе метрик загрузки (CPU, память) или кастомных метрик. KEDA масштабирует на основе внешних событий: длина очереди в RabbitMQ или AWS SQS, количество сообщений в Kafka-топике, расписание cron — и так далее.

Главная суперсила KEDA — возможность масштабирования до нуля. Стандартный HPA не может уменьшить количество реплик ниже 1. KEDA может полностью остановить все поды, когда нет событий для обработки, и создать их заново, когда появляются новые. Для пакетных обработчиков и нерегулярных нагрузок это даёт колоссальную экономию — вы буквально не платите ни копейки, когда нет работы.

KEDA поддерживает более 65 скейлеров, включая AWS SQS, Azure Service Bus, Kafka, Prometheus, PostgreSQL, Redis и многие другие. Вот пример ScaledObject для масштабирования на основе длины очереди AWS SQS:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
  namespace: production
spec:
  scaleTargetRef:
    name: order-processor
  pollingInterval: 15
  cooldownPeriod: 120
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.eu-west-1.amazonaws.com/123456789/orders
      queueLength: "5"
      awsRegion: "eu-west-1"
    authenticationRef:
      name: aws-credentials

В этом примере KEDA создаёт по одному поду на каждые 5 сообщений в очереди (queueLength: "5"), масштабируясь до максимум 50 подов. Когда очередь пуста и прошло 120 секунд (cooldownPeriod), все поды удаляются. Ноль сообщений — ноль подов — ноль затрат.

Karpenter и оптимизация узлов

Автоскейлинг подов — это только половина уравнения. Вторая половина — эффективное управление самими узлами, на которых эти поды запускаются. И вот тут Karpenter совершил настоящую маленькую революцию.

Karpenter vs Cluster Autoscaler

Cluster Autoscaler (CA) — стандартный автоскейлер узлов Kubernetes. Он работает с заранее определёнными группами узлов (node groups) и масштабирует их вверх или вниз. Проблема CA в том, что он ограничен предопределёнными типами инстансов. Если вам нужен узел с 8 vCPU и 16 GB RAM, но в вашей node group настроены инстансы с 4 vCPU и 8 GB — CA создаст два узла вместо одного оптимального. Лишние расходы на ровном месте.

Karpenter работает принципиально иначе. Он анализирует pending-поды и напрямую создаёт оптимальный узел нужного размера. Karpenter не привязан к фиксированным node groups — он сам выбирает тип инстанса из заданного набора ограничений, оптимизируя под конкретные требования ваших подов.

Ключевые преимущества Karpenter:

• Быстрое масштабирование — Karpenter создаёт узлы за секунды, обращаясь напрямую к API облачного провайдера, минуя ASG.
• Оптимальный выбор инстансов — автоматически выбирает наиболее подходящий и дешёвый тип инстанса из доступных.
• Консолидация — Karpenter непрерывно анализирует утилизацию узлов и перемещает поды для максимального заполнения, удаляя недозагруженные ноды. Одна эта функция может дать экономию 15–25%.
• Нативная интеграция со Spot-инстансами — умеет автоматически переключаться между on-demand и spot, грамотно обрабатывая прерывания.

NodePool и EC2NodeClass

Karpenter использует два ключевых CRD: NodePool определяет требования к узлам (типы инстансов, зоны доступности, ограничения ресурсов), а EC2NodeClass (для AWS) определяет специфичные для провайдера настройки (AMI, подсети, security groups).

Вот пример конфигурации NodePool со Spot-инстансами для максимальной экономии:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: cost-optimized
spec:
  template:
    metadata:
      labels:
        tier: cost-optimized
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64"]
      - key: kubernetes.io/os
        operator: In
        values: ["linux"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["c", "m", "r"]
      - key: karpenter.k8s.aws/instance-generation
        operator: Gt
        values: ["5"]
      expireAfter: 720h
  limits:
    cpu: "100"
    memory: 400Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 60s
  weight: 100
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  amiSelectorTerms:
  - alias: al2023@latest
  role: KarpenterNodeRole-my-cluster
  subnetSelectorTerms:
  - tags:
      karpenter.sh/discovery: my-cluster
  securityGroupSelectorTerms:
  - tags:
      karpenter.sh/discovery: my-cluster
  blockDeviceMappings:
  - deviceName: /dev/xvda
    ebs:
      volumeSize: 50Gi
      volumeType: gp3
      deleteOnTermination: true

Давайте разберём ключевые настройки:

• capacity-type: ["spot", "on-demand"] — Karpenter сначала попробует создать Spot-инстанс. Если Spot недоступен, автоматически переключится на on-demand. Никаких ручных действий.
• instance-category: ["c", "m", "r"] — разрешены вычислительные (c), общего назначения (m) и оптимизированные по памяти (r) инстансы. Широкий набор категорий увеличивает шансы получить Spot по низкой цене.
• instance-generation: Gt ["5"] — только инстансы 6-го поколения и новее, которые обычно дешевле и быстрее предыдущих.
• consolidationPolicy: WhenEmptyOrUnderutilized — Karpenter удаляет пустые и недозагруженные узлы, перемещая поды на другие ноды. Именно эта настройка обеспечивает те самые 15–25% экономии.
• weight: 100 — приоритет этого NodePool. Если есть несколько NodePool'ов, Karpenter предпочтёт тот, у которого вес выше.

Karpenter изначально создавался для AWS, но сейчас проект развивается как облачно-независимый. В 2025–2026 годах появилась поддержка Azure (через karpenter-provider-azure), а GCP работает с аналогичным подходом через GKE Autopilot. AWS также интегрировал Karpenter в EKS Auto Mode, где он работает из коробки — без ручной установки и настройки.

Spot-инстансы и прерываемые нагрузки

Spot-инстансы — это, пожалуй, самый мощный инструмент снижения затрат на вычислительные ресурсы. Экономия может достигать 70–90% по сравнению с on-demand ценами. Но есть подвох: облачный провайдер может забрать Spot-инстанс в любой момент с коротким уведомлением (2 минуты у AWS, 30 секунд у Azure). Это делает их идеальными для одних нагрузок и опасными для других.

Spot-инстансы у разных провайдеров

• AWS Spot Instances — экономия до 90%, уведомление о прерывании за 2 минуты, широкий набор типов инстансов. Лучшая интеграция с Kubernetes через Karpenter и AWS Node Termination Handler.
• Azure Spot VMs — экономия до 90%, поддержка в AKS через Spot node pools. Azure предоставляет два типа политик вытеснения: Stop/Deallocate и Delete.
• GCP Spot VMs (ранее Preemptible VMs) — экономия до 91%, автоматическое прерывание не более чем через 24 часа. GKE поддерживает Spot VMs через spot node pools.

Лучшие практики использования Spot в Kubernetes

Чтобы безопасно использовать Spot в Kubernetes, придерживайтесь этих правил:

1. Stateless нагрузки — Spot только для нагрузок без состояния: веб-серверы, API-шлюзы, обработчики очередей. Всё stateful (базы данных, хранилища) должно жить на on-demand узлах.
2. Пакетная обработка и CI/CD — идеальные кандидаты для Spot. Обработка данных, тесты, сборки образов — всё это легко перезапустить при прерывании.
3. Диверсификация типов инстансов — используйте множество типов (не только m5.xlarge, но и m5a.xlarge, m6i.xlarge, m6a.xlarge и т.д.). Чем больше пулов ёмкости, тем ниже вероятность одновременного прерывания.
4. Graceful shutdown — убедитесь, что ваши приложения корректно обрабатывают SIGTERM и завершают текущие запросы. preStop hooks и terminationGracePeriodSeconds — ваши лучшие друзья здесь.
5. PodDisruptionBudget — критически важный механизм для защиты доступности при вытеснении подов со Spot-узлов. Без него можно потерять все реплики одновременно.

PodDisruptionBudget: защита доступности

PodDisruptionBudget (PDB) гарантирует, что при вытеснении подов (из-за прерывания Spot, обновления узла или консолидации Karpenter) будет соблюдён минимальный уровень доступности.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-api-pdb
  namespace: production
spec:
  minAvailable: "60%"
  selector:
    matchLabels:
      app: web-api
---
# Альтернативный вариант с maxUnavailable
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: order-processor-pdb
  namespace: production
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: order-processor

Первый PDB гарантирует, что не менее 60% подов web-api будут доступны в любой момент. Второй — что одновременно недоступен будет не более 1 пода order-processor. Выбирайте стратегию в зависимости от ваших требований к доступности.

Кстати, хороший совет: комбинируйте Spot с обязательствами (Savings Plans / CUD). On-demand базовая нагрузка покрывается обязательствами со скидкой 30–60%, пиковая нагрузка — Spot со скидкой 70–90%. Максимальная экономия по обоим направлениям.

Инструменты мониторинга затрат: Kubecost, OpenCost и другие

Нельзя оптимизировать то, что не измеряешь. Это банальность, но она остаётся правдой. Для управления затратами в Kubernetes нужны специализированные инструменты, которые умеют разбивать стоимость инфраструктуры по неймспейсам, деплойментам и даже отдельным подам.

OpenCost

OpenCost — open-source проект уровня Incubating в CNCF, обеспечивающий мониторинг затрат на Kubernetes-нагрузки. Базовый, но вполне мощный инструмент, который:

• Распределяет стоимость узлов по подам на основе потребления ресурсов
• Поддерживает AWS, Azure, GCP и on-premise
• Предоставляет API и базовый UI для просмотра затрат
• Может работать без Prometheus (функция Promless/Collector Datasource)
• Поддерживает MCP-сервер для интеграции с AI-агентами
• Полностью бесплатный

Установка OpenCost через Helm:

# Добавляем Helm-репозиторий OpenCost
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update

# Устанавливаем OpenCost
helm install opencost opencost/opencost   --namespace opencost   --create-namespace   --set opencost.prometheus.internal.enabled=true   --set opencost.ui.enabled=true

# Проверяем установку
kubectl get pods -n opencost

Ограничение OpenCost: он не учитывает скидки (Spot-цены, Reserved Instances, Savings Plans), кредиты и кастомные ценовые соглашения. Для начального мониторинга это нормально, но для точной аллокации понадобится что-то посерьёзнее.

Kubecost

Kubecost построен на OpenCost и добавляет значительно больше возможностей. После приобретения IBM в 2024 году проект получил дополнительные инвестиции. Ключевые преимущества над OpenCost:

• Учёт скидок, Spot-цен и кастомного прайсинга
• Мониторинг out-of-cluster затрат (S3, RDS, CloudFront и т.д.)
• Рекомендации по оптимизации (right-sizing, удаление неиспользуемых ресурсов)
• Бюджеты и алерты при превышении порогов
• Продвинутая аллокация shared-затрат
• Бесплатная версия для одного кластера, платные тарифы для multi-cluster

Другие инструменты

Рынок инструментов оптимизации Kubernetes активно растёт. Вот наиболее интересные альтернативы:

• CAST AI — платформа автоматической оптимизации, которая не только показывает затраты, но и сама оптимизирует кластеры: rightsizing, bin packing, управление Spot. Заявляет экономию более 60%. Поддерживает все три крупных облака.
• Vantage — облачный инструмент мониторинга затрат с интеграцией Kubernetes через OpenCost. Хорош для мультиоблачных сред.
• nOps — AI-управляемая оптимизация для AWS с сильной поддержкой EKS. Автоматическое управление Spot и right-sizing.
• ScaleOps — автоматический right-sizing Kubernetes-ресурсов с акцентом на производительность и стабильность.

Сравнительная таблица инструментов

Инструмент	Тип	Стоимость	Автооптимизация	Multi-cloud	Лучше всего для
OpenCost	Open-source (CNCF)	Бесплатно	Нет	Да	Базовый мониторинг, стартовая точка
Kubecost	Freemium	Бесплатно (1 кластер) / от $199/мес	Рекомендации	Да	Детальный мониторинг, аллокация
CAST AI	SaaS	% от экономии	Да	Да	Полная автоматизация оптимизации
Vantage	SaaS	Бесплатно / от $150/мес	Нет	Да	Мультиоблачная видимость
nOps	SaaS	% от экономии	Да (AWS)	Только AWS	AWS/EKS-ориентированные команды

Мой совет: начните с OpenCost для базовой видимости — это бесплатно и занимает 10 минут. Когда увидите масштаб проблемы (а вы его увидите), переходите на Kubecost или CAST AI для серьёзной автоматизации.

Аллокация затрат: showback и chargeback

Видеть общие затраты на кластер полезно, но недостаточно. Чтобы по-настоящему управлять расходами, вам нужно знать, какая команда, какой проект и какая среда потребляет ресурсы. Это и есть аллокация затрат — распределение общих расходов по конкретным потребителям.

Стратегия лейблинга

Лейблы — основа всей аллокации затрат в Kubernetes. Без них любой инструмент мониторинга будет показывать только «кластер стоит $X в месяц» — и ни грамма детализации. Вот минимальный набор лейблов, который должен быть на каждом деплойменте:

• team — команда-владелец (backend, frontend, data, ml)
• project — проект или продукт (payments, search, recommendations)
• environment — среда (production, staging, development)
• cost-center — центр затрат для бухгалтерии (engineering, marketing-tech)

Критически важно, чтобы эти лейблы стояли на всех ресурсах. Один деплоймент без лейблов — и часть затрат становится «нераспределённой», искажая картину для всех остальных.

Принудительное применение лейблов через OPA/Gatekeeper

Полагаться на «добрую волю» разработчиков — стратегия так себе. Open Policy Agent (OPA) с Gatekeeper позволяет создавать политики, которые блокируют создание ресурсов без обязательных лейблов:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-cost-labels
spec:
  match:
    kinds:
    - apiGroups: ["apps"]
      kinds: ["Deployment", "StatefulSet", "DaemonSet"]
    namespaces:
    - production
    - staging
  parameters:
    labels:
    - key: "team"
    - key: "project"
    - key: "environment"
    - key: "cost-center"

С такой политикой любая попытка создать Deployment без обязательных лейблов будет отклонена. Стопроцентное покрытие аллокации гарантировано.

Аллокация на уровне неймспейсов

Дополнительный уровень аллокации — использование неймспейсов. Если каждая команда живёт в своём неймспейсе (team-backend, team-frontend), аллокация становится тривиальной: все затраты в неймспейсе = затраты команды. ResourceQuotas на уровне неймспейсов дополнительно ограничивают аппетиты:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-backend-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "100"

AWS EKS Split Cost Allocation

С 2024 года AWS предоставляет нативную функцию Split Cost Allocation Data для EKS. Она автоматически разбивает стоимость EC2-инстансов по подам в Cost and Usage Report (CUR). В 2025 году функциональность серьёзно расширилась:

• Поддержка до 50 пользовательских Kubernetes-лейблов на под
• Поддержка GPU-инстансов (NVIDIA, AMD), Trainium и Inferentia
• Автоматические теги: cluster-name, namespace, node, workload-type, workload-name, deployment
• Доступно во всех коммерческих регионах AWS без дополнительной платы

Если вы работаете с EKS — обязательно активируйте Split Cost Allocation. Это самый точный способ аллокации, потому что он основан на реальных данных биллинга AWS, а не на оценках сторонних инструментов.

Showback vs Chargeback: модель зрелости

Организации обычно проходят несколько этапов зрелости:

1. Видимость — команды видят общие затраты на кластер, но понятия не имеют, кто сколько потребляет. Большинство организаций застряли именно здесь.
2. Showback — команды получают отчёты о своём потреблении. Это информирование без последствий: «Ваша команда потратила $15,000 на Kubernetes в прошлом месяце». Нет штрафов за перерасход, но появляется осознанность.
3. Chargeback — затраты реально списываются с бюджета каждой команды. Это создаёт прямую финансовую мотивацию к оптимизации — и, поверьте, она работает.
4. FinOps-культура — оптимизация интегрирована в процессы разработки. Разработчики видят стоимость ресурсов в pull request'ах, пайплайнах, дашбордах. Затраты становятся такой же метрикой, как latency или availability.

Честно говоря, большинству организаций не нужен полноценный chargeback — он создаёт заметные бухгалтерские накладные расходы. Showback с еженедельными отчётами по командам и ежемесячными обзорами обычно достаточно для формирования культуры экономии.

Сравнение EKS, AKS и GKE по стоимости

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

Стоимость control plane

Первая и самая очевидная разница — стоимость управляющего уровня:

• Amazon EKS — $0.10 в час за кластер (~$73 в месяц). Фиксированная плата независимо от размера кластера. При 10+ кластерах это уже заметная статья расходов.
• Azure AKS — бесплатный control plane для стандартного уровня. Платный Premium с улучшенным SLA стоит $0.10/час.
• Google GKE — бесплатный control plane для Standard-кластеров (один бесплатный зональный кластер через free tier). Для Autopilot тоже есть free tier ($74.40/месяц кредита на управление). Региональные кластеры — $0.10/час.

Ключевые отличия для оптимизации затрат

Характеристика	Amazon EKS	Azure AKS	Google GKE
Control plane	$0.10/час	Бесплатно (Standard)	Бесплатно (1 зональный кластер)
Автоскейлинг узлов	Karpenter / Cluster Autoscaler	Cluster Autoscaler / Karpenter (preview)	Cluster Autoscaler / Autopilot
Spot-интеграция	Karpenter + Node Termination Handler	Spot Node Pools	Spot VMs Node Pools
Serverless/Autopilot	EKS Auto Mode (Karpenter встроен)	Нет (виртуальные узлы через ACI)	GKE Autopilot
Нативная аллокация затрат	Split Cost Allocation Data	Cost Analysis (preview)	GKE cost allocation
Commitment-скидки	Savings Plans / RI	Reservations / Savings Plans	CUD (spend-based)

EKS: мощная экосистема оптимизации

EKS лидирует по зрелости инструментов оптимизации. Karpenter, нативный проект AWS, обеспечивает самую эффективную оптимизацию узлов. EKS Auto Mode стал полноценной альтернативой ручному управлению: Karpenter работает из коробки, автоматически выбирая оптимальные инстансы. Split Cost Allocation Data даёт нативную аллокацию без сторонних инструментов.

Платный control plane ($73/мес) — это минус, но для больших кластеров это ничтожная доля общих затрат.

AKS: бесплатный и гибкий

Бесплатный control plane — главное преимущество AKS, особенно для организаций с множеством небольших кластеров. Azure активно развивает поддержку Karpenter (karpenter-provider-azure), хотя она пока отстаёт по зрелости от AWS-реализации. Azure Hybrid Benefit позволяет использовать существующие лицензии Windows Server — уникальная фишка для смешанных Windows/Linux нагрузок.

GKE: Autopilot как модель будущего

GKE Autopilot — уникальное предложение, где Google полностью берёт управление узлами на себя. Вы платите только за ресурсы, запрошенные подами (CPU, память, эфемерное хранилище), а не за сами узлы. В us-central1 это примерно $0.0445 за vCPU-час и $0.0049 за GiB-час памяти.

Autopilot устраняет необходимость в ручной оптимизации узлов — нет переразмеренных серверов, нет простаивающей инфраструктуры. Но вы теряете контроль над типами инстансов и не можете использовать Spot VMs так же гибко, как в Standard режиме. Для большинства типовых веб-нагрузок GKE Autopilot может оказаться самым экономичным вариантом — просто потому, что он полностью устраняет проблему недозагруженных узлов.

Практический чек-лист оптимизации

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

1. Установите OpenCost или Kubecost — без видимости затрат все остальные действия будут вслепую. 10–15 минут с Helm — и вы уже видите картину расходов по неймспейсам и деплойментам.
2. Проведите аудит resource requests — сравните requests с реальным потреблением за последние 2 недели. Если CPU utilization ниже 30% от requests, вы переплачиваете минимум в 2–3 раза. Это самый быстрый способ сэкономить.
3. Установите VPA в режиме "Off" — пусть собирает рекомендации по правильным значениям requests. Через пару недель получите данные для обоснованного right-sizing. Ожидаемая экономия: 20–40% на вычислительных ресурсах.
4. Настройте HPA для stateless-нагрузок — убедитесь, что веб-серверы и API масштабируются автоматически. Не забудьте про stabilizationWindow и behavior для настройки скорости скейлинга в обе стороны.
5. Внедрите стратегию лейблинга — определите обязательные лейблы (team, project, environment, cost-center) и примените ко всем ресурсам. OPA/Gatekeeper поможет обеспечить принудительное применение.
6. Переведите некритичные нагрузки на Spot — dev/staging среды, CI/CD, пакетная обработка. Не забудьте настроить PodDisruptionBudgets. Ожидаемая экономия: 70–90%.
7. Внедрите Karpenter (для AWS) или аналог — замените Cluster Autoscaler для более эффективного управления узлами. Включите consolidation. Ожидаемая экономия от консолидации: 15–25%.
8. Оптимизируйте dev/staging среды — уменьшите requests до 25–50% от продакшен-значений. Настройте автоматическое выключение на ночь и выходные через KEDA cron-скейлер. Вы удивитесь, сколько денег тратится на dev-среды, работающие 24/7 без какой-либо необходимости.
9. Настройте ResourceQuotas по неймспейсам — ограничьте максимальное потребление каждой команды. Это предотвратит ситуацию, когда одна команда «съедает» весь кластер.
10. Внедрите showback-отчёты — еженедельно отправляйте командам отчёты об их затратах. Прозрачность — мощный мотиватор. Даже без chargeback команды начинают оптимизировать, когда видят свои цифры чёрным по белому.
11. Комбинируйте с обязательствами — базовая нагрузка покрывается Savings Plans, RI или CUD. Spot покрывает пики. Два дополняющих друг друга механизма.
12. Проводите ежемесячные cost review — выделите час в месяц на обзор затрат с инфраструктурной командой и ключевыми потребителями. Без регулярного пересмотра оптимизации имеют свойство деградировать — затраты всегда стремятся вырасти обратно.

Заключение

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

Но есть и хорошая новость: инструменты и практики из этой статьи дают реальные и быстрые результаты. Правильная настройка requests и limits сокращает расходы на 20–40% без ущерба для производительности. Spot-инстансы экономят 70–90% на подходящих нагрузках. Karpenter с консолидацией добавляет ещё 15–25%. А грамотная аллокация затрат через лейблинг и showback создаёт культуру ответственного потребления.

Если совместить это всё с обязательствами (Reserved Instances, Savings Plans, CUD), о которых мы подробно писали в нашем руководстве по обязательствам, общая экономия может достигать 60–80% по сравнению с неоптимизированным on-demand. Это не теоретические цифры — я видел такие результаты в организациях, которые системно подошли к вопросу.

Ключевые принципы:

• Начните с видимости — установите инструмент мониторинга затрат в первый же день.
• Оптимизируйте снизу вверх — сначала requests подов, потом автоскейлинг, потом узлы, потом обязательства на уровне провайдера.
• Автоматизируйте всё — ручная оптимизация не масштабируется. VPA, HPA, KEDA, Karpenter работают за вас.
• Создавайте культуру — технологии важны, но культура FinOps важнее. Когда каждый разработчик понимает стоимость своих решений, оптимизация становится естественной частью процесса разработки.

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