На главную ПОПРОБОВАТЬ

Оптимизация нод Kubernetes

5 типов оптимизации на уровне node groups: подбор типа VM, гибернация, проактивный автоскейлинг, spot-ноды и bin-packing. Каждый тип работает независимо и может быть включён отдельно.

Обзор

Оптимизация нод дополняет рекомендации по workloads (requests/limits) и работает на уровне целых node groups. Платформа анализирует утилизацию нод, тарифы провайдера и паттерны нагрузки, чтобы предложить конкретные действия — от смены типа VM до автоматического засыпания dev-кластеров.

5 инструментов оптимизации

⚙
Instance Type
Подбор оптимального типа VM: downsize, смена платформы, upsize. Безопасный 5-step apply с drain и PDB. Тарифы с core_fraction.
🌙
Hibernation
Dev/staging кластеры засыпают по расписанию. Пресеты, preflight-проверка, корректный drain. Экономия ~65%.
📈
Proactive Scaling
Автоскейлер на p95: проактивный scale up по тренду, автоматический возврат временной burst-capacity к защищённому baseline и стратегический scale down с live preflight.
⚡
Spot Management
Перевод stateless workloads на preemptible ноды. Тёплая on-demand ёмкость, opt-in service-visible replica и реактивный health monitor. Доступность подтверждается отдельным fault-test.
📦
Bin-Packing
Оценка packing efficiency, консолидация подов. Освободившиеся ноды удаляет Cluster Autoscaler.

Режимы работы

Каждый тип оптимизации может работать в одном из трёх режимов. Режим выбирается на странице настроек Node Optimization.

Режим Описание Instance Type Hibernation Proactive Scaling Spot Bin-Packing
Monitor Только рекомендации, без действий ✓ ✓ ✓ ✓ ✓
Approval Рекомендации + apply по кнопке (default) ✓ ✓ ✓ ✓ ✓
Auto Автоматическое применение только разрешённых безопасных действий ✓ ✓ Только scale up; scale down требует подтверждения ✓ ✓
Проверенная доступность операций

На изолированном Yandex Cloud стенде strict SLO с нулём ошибок и таймаутов в одновременных внешней и внутренней пробах подтверждён для rightsizing rollout, proactive scale up, scale down с консолидацией и полного instance-type replacement. В проверенном replacement-сценарии Oopps создал новую группу, перенёс workload и физически удалил source: внешняя проба — 232/232, внутренняя Service-DNS — 151/151, без retry, ошибок и таймаутов. Результат относится к isolated stateless fixture с готовым резервом и PDB; перед каждой реальной операцией всё равно требуется собственный capacity/storage/placement preflight.

Тарификация Yandex Cloud

Тарифы и платформы

Расчёт экономии использует тарифы из внутренней таблицы (docs/tariffs-yc), которая покрывает 6 платформ Yandex Cloud и все варианты core_fraction (доля vCPU: 5%, 20%, 50%, 100%).

Тарифы обновляются вручную — у Yandex Cloud нет публичного pricing API. Точность расчётов зависит от актуальности таблицы. Рекомендуем проверять тарифы при обновлении платформы.

Необходимые IAM роли и Kubernetes RBAC

Важно

Для актуальных node-level метрик сервисному аккаунту нужен доступ get/list/watch к cluster-scoped ресурсу nodes. Стандартные роли k8s.cluster-api.viewer и k8s.cluster-api.editor этот доступ не дают.

Примените от имени администратора в каждом кластере:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: oopps-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["nodes", "pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oopps-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: oopps-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: yc:viewer

Подробная настройка и диагностика: Yandex Cloud → подготовка и права.

Для выполнения apply (создание/удаление node groups, drain нод) сервисному аккаунту необходимы обе роли одновременно:

  • k8s.editor — MKS API: создание и удаление node groups.
  • k8s.cluster-api.editor — Kubernetes RBAC: cordon и evict нод.

Без любой из этих ролей apply завершится ошибкой. Роль k8s.editor без k8s.cluster-api.editor позволит создать новую группу, но не сможет выполнить drain старых нод.

Что дальше?