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

Instance Type — подбор оптимального типа VM

Анализирует node groups за 14 дней и подбирает оптимальный тип VM по утилизации и тарифам. Работает только для Yandex Cloud MKS.

Обзор

Instance Type Optimization собирает метрики утилизации (CPU и Memory) по каждой node group за последние 14 дней и сопоставляет их с каталогом типов VM Yandex Cloud. Результат — рекомендация перейти на более дешёвый, более подходящий или более мощный тип VM в зависимости от паттерна нагрузки.

Три стратегии

Downsize

Если средняя утилизация ниже 50%, платформа подбирает более дешёвый тип VM, который вмещает p95 × 1.3 (safety margin 30%). Типичная экономия — от 15%.

Пример: node group на standard-v3 4c/16GB при средней утилизации CPU 15%, MEM 20%. Рекомендация — standard-v3 2c/4GB. P95 вмещается с запасом, стоимость снижается вдвое.

Смена платформы

Если тот же размер (cores/memory) на другой платформе стоит дешевле, платформа предлагает миграцию без изменения ресурсов.

Пример: highfreq-v3 4c/16GB → standard-v3 4c/16GB — экономия ~40%. Workload не требует высокочастотных ядер — можно перейти на стандартную платформу.

Upsize для стабильности

Если p95 утилизации стабильно выше 80% на протяжении 14 дней, node group работает на пределе и нуждается в запасе на спайки нагрузки.

Это не экономия, а безопасность. Рекомендация работает только в режиме approval — автоматический upsize не выполняется.

5-step Apply

Применение рекомендации выполняется в 5 последовательных шагов. Каждый шаг логируется, при ошибке на любом шаге процесс останавливается.

Шаг 1 — Fetch

Получение текущей конфигурации node group из Yandex MKS API: тип VM, количество нод, scalePolicy, networkSettings, labels, taints.

Шаг 2 — Create

Создание новой node group с рекомендуемым типом VM. Имя новой группы: {old_name}-optimized. Встроена защита от двойного суффикса — если имя уже заканчивается на -optimized, повторный суффикс не добавляется.

Шаг 3 — Wait

Ожидание статуса RUNNING у новой node group. Таймаут — 600 секунд. Если группа не поднялась — процесс останавливается с ошибкой.

Шаг 4 — Drain

Ноды старой группы обрабатываются строго по одной: cordon (запрет на размещение новых подов), затем evict через Kubernetes Eviction API с уважением PodDisruptionBudget. Перед переходом к следующей ноде Oopps ждёт ухода старых подов и готовности затронутых Deployment/StatefulSet.

Шаг 5 — Delete

Удаление старой node group после подтверждения, что все поды успешно переехали на новую группу. Старая группа удаляется через MKS API.

Strict SLO подтверждён на isolated fixture

Полный сценарий create replacement → serial migrate → physical source deletion проверен на изолированном Yandex Cloud стенде со stateless workload, готовым резервом и PDB. От product operation marker до устойчивой готовности replacement внешняя stable-endpoint проба завершила 232/232 запроса, внутренняя Service-DNS — 151/151; automatic retry, ошибок и таймаутов не было. После удаления временного резерва workload остался 3/3 Ready.

Это evidence конкретной безопасной топологии, а не универсальная гарантия для любой нагрузки. Перед применением убедитесь, что новая группа может получить нужную cloud capacity, есть готовый резерв, PDB разрешает eviction, а workload не зависит от локального хранилища или несовместимых placement constraints. Успешная replacement group становится новым целевым состоянием; автоматический обратный rollback на исходный тип этим сценарием не подтверждён.

Тарификация

Расчёт экономии основан на тарифах 6 платформ Yandex Cloud. Ключевой параметр — core_fraction (доля vCPU), который существенно влияет на стоимость.

Платформы Yandex Cloud

Платформа Процессор Описание
standard-v1 Intel Broadwell Предыдущее поколение, базовый уровень
standard-v2 Intel Cascade Lake Второе поколение, улучшенная производительность
standard-v3 Intel Ice Lake Актуальное поколение, оптимальное соотношение цена/производительность
highfreq-v3 Intel Ice Lake (CO) Высокочастотные ядра, для compute-intensive задач
standard-v4 AMD Zen 4 Новейшее поколение на AMD, высокая производительность
highfreq-v4 AMD Zen 4 (CO) Высокочастотные ядра AMD, максимальная производительность

Core Fraction (доля vCPU)

core_fraction — доля процессорного времени, гарантируемая виртуальной машине. Цена отличается в 2–3× в зависимости от выбранной доли.

Платформа Core Fraction Цена, ≅ ₽/час/vCPU
standard-v3 100% 1.24
standard-v3 50% 0.76
standard-v3 20% 0.52
standard-v3 5% 0.28

Тарифы обновляются вручную из docs/tariffs-yc. У Yandex Cloud нет публичного pricing API, поэтому точность расчётов зависит от актуальности внутренней таблицы.

Совместимость с Yandex API

Yandex MKS API имеет несколько особенностей, которые платформа обрабатывает автоматически:

  • networkSettings.type и containerRuntimeSettings.type — GET возвращает пустые объекты ({}), но CREATE требует явного указания .type. Платформа подставляет значения по умолчанию.
  • v4AddressSpec vs networkInterfaceSpecs — GET возвращает оба поля, но CREATE отвергает их одновременно. Платформа автоматически разрешает конфликт, оставляя только нужное поле.
Необходимые IAM роли

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

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

Для просмотра рекомендаций и расчёта экономии дополнительные роли не требуются — достаточно стандартных ролей коннектора (viewer, k8s.cluster-api.cluster-viewer, compute.viewer).

Что дальше?