Attune: автоподбор ресурсов Kubernetes без перезапуска

19 октября 2026 г.

#hpa#in-place-resize#operators#resource-management#rightsizing#vertical-scaling
Логотип Attune

Attune — оператор Kubernetes, который автоматически подбирает оптимальные запросы и лимиты ресурсов для подов с помощью изменения ресурсов без перезапуска (In-Place Pod Resize) (GA в Kubernetes 1.35; бета с включением по умолчанию в 1.33–1.34; альфа с 1.27, с feature gate в 1.32). Attune требует Kubernetes 1.32+ для использования субресурса /resize. По умолчанию применяется in-place изменение, при необходимости — опциональный откат через вытеснение (eviction) для неосуществимых ресайзов, без конфликтов с HPA.

Зачем это нужно

Проблема Последствия

Средняя утилизация CPU составляет 8%

Большая часть запрошенных ресурсов простаивает (CAST AI 2026)

70% называют избыточное выделение ресурсов одним из главных факторов роста затрат

Ресурсы, выделенные «на всякий случай», так и не высвобождаются (CNCF 2023)

<1% используют VPA в production

VPA исторически вытесняет поды, конфликтует с HPA и плохо поддаётся автоматизации (ScaleOps 2026)

In-Place Pod Resize стал GA (K8s 1.35; бета 1.33–1.34; альфа с 1.27)

Ненарушительный подбор ресурсов стал стабильным примитивом Kubernetes

Чем Attune отличается от аналогов

In-place применение — это общий примитив (субресурс Kubernetes /resize). Attune — это безопасный автономный цикл поверх него: измерить, принять решение, применить к canary-поднабору, проверить результат, откатиться при необходимости.

VPA Goldilocks Attune

Метод ресайза

Исторически вытеснение; новые режимы могут использовать in-place там, где это поддерживается

Без ресайза (только рекомендации)

In-place по умолчанию (опциональный откат через вытеснение)

Совместимость с HPA

Рискованно на одной метрике (петли смерти)

Н/П

Да (корректирует базовые запросы, не проценты HPA)

Безопасность

Минимальные ограничения

Н/П

Автооткат (OOM, throttle, рестарты, NotReady) + SLO-ограничители на PromQL

Радиус поражения

Все целевые поды

Н/П

Canary-доля с наблюдением и опциональным автопродвижением

Холодный старт

Нет

Н/П

Startup boost (временный запас CPU, затем откат к steady-state)

Алгоритм

Гистограммы на основе прошлых данных

Рекомендер VPA

С учётом времени суток + обнаружение всплесков + масштабирование по уверенности

Путь в production

<1% применяют в production

Ручное применение

Observe → Recommend → Canary → Auto

Мигрируете с VPA? Ознакомьтесь с пошаговым docs/guides/migrating-from-vpa.md[руководством по миграции]: там есть сопоставление полей, матрица режимов, сравнение YAML и инструкция по переходу без простоев.

Другие in-place решения 2026 года (k8s-sustain, CruiseKube, Kedify PRA) рассмотрены в разделе docs/why-attune.md#other-2026-in-place-appliers[Why Attune].

Быстрый старт

Предварительные требования

  • Kubernetes 1.32+ (в 1.32 необходимо включить feature gate InPlacePodVerticalScaling; в 1.33–1.34 бета включена по умолчанию; 1.35+ GA)

  • Prometheus (для метрик использования)

  • Helm 3.16+ или 4.x

  • cert-manager (требуется для TLS admission webhook по умолчанию; чтобы пропустить, установите с --set webhooks.enabled=false)

Опциональный режим GitOps-экспорта: рекомендации можно записывать в ConfigMap вместо (или в дополнение к) прямого ресайза. Идеально подходит для рабочих процессов ArgoCD/Flux. Подробнее — в docs/guides/auto-mode.md#exporting-recommendations-to-configmaps[руководстве по режиму Auto].

Установка

# Требует cert-manager при включённых webhooks (поведение по умолчанию).
# Типичные ошибки при первом запуске:
#   --set webhooks.enabled=false          # пропустить cert-manager
#   --set networkPolicy.prometheusPort=80 # если Prometheus Service слушает :80
#                                         # (chart по умолчанию разрешает только :9090)
# Chart 0.1.23 по умолчанию использует тег :0.1.23 (никогда не публиковался). Закрепите
# chart с помощью --set image.tag=v0.1.23. Начиная с 0.1.24+ пин можно не указывать.
helm install attune oci://ghcr.io/attune-io/charts/attune \
  --namespace attune-system --create-namespace

Также доступно через OperatorHub.io (OLM-пакет attune) и на OpenShift 4.19+ во встроенном каталоге OperatorHub Community под тем же именем. Сырые манифесты публикуются с каждым релизом. Все варианты установки описаны в руководстве по установке и docs/guides/openshift[руководстве для OpenShift].

Создание политики (Policy)

Начните в режиме Recommend (безопасный, без применения изменений):

apiVersion: attune.io/v1alpha1
kind: AttunePolicy
metadata:
  name: api-services
  namespace: production
spec:
  targetRef:
    kind: Deployment
    selector:
      matchLabels:
        tier: api
  metricsSource:
    prometheus:
      address: http://prometheus-server.monitoring:80
    # Опционально: более быстрый первый взгляд (~1ч вместо ~4ч при queryStep: 5m)
    # minimumDataPoints: 12
  cpu:
    percentile: 95
    overhead: "20"
    minAllowed: "1m"
  memory:
    percentile: 99
    overhead: "30"
    minAllowed: "4Mi"
  updateStrategy:
    type: Recommend
kubectl apply -f policy.yaml

Просмотр рекомендаций

kubectl get attunepolicies -n production
# NAME            TYPE        WORKLOADS   RECS   RESIZED   READY   AGE
# api-services    Recommend   3           0      0         False   5m

После накопления достаточного количества данных появятся рекомендации:

kubectl get attunepolicies -n production
# NAME            TYPE        WORKLOADS   RECS   RESIZED   READY   AGE
# api-services    Recommend   3           3      0         True    2d

kubectl attune recommendations -n production
# NAMESPACE   POLICY        WORKLOAD    CONTAINER  CPU REQ  CPU REC  MEM REQ  MEM REC  GRADE  CONFIDENCE / STATUS
# production  api-services  api-server  app        500m     320m     512Mi    384Mi    D      92.0%
# production  api-services  worker      main       1000m    480m     2Gi      1.2Gi    F      88.5%
# production  api-services  frontend    nginx      250m     120m     256Mi    180Mi    F      95.1%

kubectl attune savings -n production
# NAMESPACE   NAME          CPU SAVED  MEMORY SAVED  % SAVED  EST. MONTHLY
# production  api-services  830m       1012Mi        34%      $72.40

Примечание: minimumDataPoints считает выборки из range-запросов Prometheus, а не часы. При дефолтном queryStep: 5m для minimumDataPoints: 48 потребуется около 4 часов данных. Если увеличить queryStep, реальное время ожидания тоже вырастет. Подробности — в docs/getting-started/quickstart.md[руководстве по быстрому старту].

В этом примере не задан maxAllowed. Добавьте его, если хотите ограничить максимум.

Эффективные значения по умолчанию: большинство полей политики, имеющих дефолты, контроллер применяет во время reconcile, чтобы их можно было переопределить через AttuneDefaults и AttuneNamespaceDefaults. Такие поля могут выглядеть пустыми при выполнении kubectl get attunepolicy -o yaml, но политика всё равно следует встроенному и унаследованному поведению, если явно не переопределить эти поля. Используйте kubectl attune explain -n <namespace> <policy>, чтобы увидеть эффективные значения ключевых defaults, применяемых контроллером, и узнать, откуда каждое из них взято: из самой политики, namespace-дефолтов, кластерных дефолтов или встроенных значений.

Обновляетесь? Проверьте CHANGELOG.md[changelog] на наличие критических изменений.

Helm-установки: если в кластере действуют ограничительные сетевые политики, ознакомьтесь с charts/attune/README.md#networkpolicy[Helm README] перед установкой с networkPolicy.enabled=true (по умолчанию). Политика разрешает исходящий трафик для webhook, метрик, DNS, API-сервера и Prometheus на порту networkPolicy.prometheusPort (по умолчанию 9090).

Переход в режим Canary

Когда рекомендации вызывают доверие, переключитесь в режим Canary: изменения будут применяться сначала к 10% подов:

spec:
  updateStrategy:
    type: Canary
    canary:
      percentage: 10
      observationPeriod: 30m  # рекомендуемое первое окно; без указания — 5m
    autoRevert: true           # по умолчанию

Больше сценариев — в директории examples/[examples/]: режим Auto, совместная работа с HPA, кластерные дефолты и мультирабочие селекторы.

Плагин kubectl

Плагин kubectl attune даёт быстрый доступ к статусу политики, экономии, рекомендациям, истории ресайзов и обоснованиям рекомендаций — без разбора сырого YAML.

# Установка через Krew (рекомендуется)
kubectl krew install attune

# Или сборка из исходников
make build-plugin
sudo cp bin/kubectl-attune /usr/local/bin/

# Использование
kubectl attune status -n production
kubectl attune savings -n production
kubectl attune recommendations -n production
kubectl attune preview -n production api-services   # текущее vs рекомендованное перед продвижением
kubectl attune export -n production                 # GitOps ConfigMap-экспорты + время последнего обновления
kubectl attune history -n production
kubectl attune explain -n production api-services
kubectl attune wizard                               # интерактивное создание политики
kubectl attune doctor                               # версия кластера, pods/resize, cgroup v2, Prometheus
kubectl attune version

# Все пространства имён
kubectl attune status -A

Пример вывода (kubectl attune status):

NAMESPACE    NAME           TYPE    WORKLOADS  PENDING  RESIZED  READY        RESIZING  DEGRADED  SCHEDULE  CANARY  EXPORT  AGE
production   api-services   Canary  3          0        1        Monitoring   Idle      -         -         -       -       2d

Пример вывода (kubectl attune recommendations):

NAMESPACE   POLICY        WORKLOAD    CONTAINER  CPU REQ  CPU REC  MEM REQ  MEM REC  GRADE  CONFIDENCE / STATUS
production  api-services  api-server  app        500m     320m     512Mi    384Mi    D      92.0%

Дашборд Grafana

Helm chart (рекомендуется): включите grafanaDashboard.enabled: true в values Helm, чтобы дашборд автоматически подготавливался через Grafana sidecar:

helm upgrade attune oci://ghcr.io/attune-io/charts/attune \
  --set grafanaDashboard.enabled=true

Ручной импорт: сырой JSON находится по адресу deploy/grafana/dashboard.json[deploy/grafana/dashboard.json]. Импортируйте его в Grafana и выберите источник данных Prometheus.

Дашборд включает:

  • Overview: общее количество ресайзов, откатов, сэкономленных CPU и памяти

  • Resize Operations: частота ресайзов по результатам, откаты по причинам

  • Recommendations: рекомендации CPU/памяти по воркloadам и показатели уверенности

  • Operator Health: задержка reconcile (p50/p99), длительность запросов к Prometheus, ошибки запросов

Архитектура

┌────────────────────────────────────────────────────┐
│                       attune                       │
│                                                    │
│  Policy         Metrics         Recommender        │
│  Controller ──► Collector ──►  Engine              │
│       │                     (percentile -> margin  │
│       │                      -> confidence ->      │
│       ▼                      bounds clamping)      │
│  Resize         Safety                             │
│  Engine ◄────► Monitor                             │
│  (/resize       (OOMKill, throttle,                │
│   subresource)   restarts, auto-revert)            │
└────────────────────────────────────────────────────┘
         │                    │
         ▼                    ▼
    Kubernetes API       Prometheus
    (Pod /resize)        (usage data)

Возможности

Безопасность

  • Автооткат: автоматически восстанавливает исходные ресурсы при OOMKill, CPU throttle, всплесках рестартов или переходе пода в NotReady.

  • SLO-ограничители: проверки работоспособности приложения через PromQL (задержка, частота ошибок) — при превышении порогов после ресайза запускается откат.

  • Постепенный rollout: пять режимов от нулевого риска до полной автоматизации — Observe, Recommend, OneShot, Canary (с опциональным автопродвижением), Auto.

  • Canary-rollout: сначала ресайз применяется к части подов, затем наблюдение, и только потом продвижение — радиус поражения остаётся под контролем до перехода в полный Auto.

  • Startup boost: временный запас CPU при старте контейнера (JIT / cold path), после чего происходит откат к steady-state рекомендации.

  • Проверка ёмкости узла: перед применением изменений валидирует, что запросы после ресайза укладываются в allocatable на узле.

  • Защита LimitRange/ResourceQuota: пропускает ресайзы, которые нарушают ограничения пространства имён или превышают доступную квоту.

  • Экспоненциальный backoff: cooldown удваивается при каждом последовательном откате (максимум 16x). Состояние Degraded сигнализирует о воркloadах, требующих настройки.

Интеллект

  • Масштабирование по уверенности: консервативные рекомендации при малом объёме данных, точные — по мере их накопления. Без преждевременной оптимизации.

  • Учёт времени суток: почасовые профили использования гарантируют, что рекомендации покрывают пиковые часы, а не только среднее значение.

  • Совместная работа с HPA: корректирует базовые запросы ресурсов, не вмешиваясь в процентное масштабирование HPA. Без петель смерти.

  • Границы ресурсов: minAllowed и maxAllowed задаются на уровне политики. Если минимум не указан, для CPU нижняя граница — 1m, для памяти — 4Mi. Если максимум не указан, ограничений нет.

Операции

  • In-place ресайз: корректирует CPU и память запущенных подов через субресурс K8s /resize (GA в 1.35). По умолчанию — без рестартов. InPlaceOrRecreate опционально откатывается к вытеснению, если kubelet отвергает in-place ресайз.

  • Оценка экономии затрат: EstimatedMonthlySavings на уровне воркload в статусе, в CLI (kubectl attune savings) и дашборде Grafana.

  • Расписание ресайзов: ограничение применения изменений конкретными временными окнами и днями недели. Рекомендации вычисляются непрерывно вне зависимости от расписания.

  • Лимиты прироста в минуту: ограничение того, насколько много CPU и памяти одна политика может добавить за минуту.

  • Параллельная обработка подов: одновременный ресайз нескольких подов в рамках одного цикла для снижения задержки при масштабировании.

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

  • Несколько источников данных: Thanos, VictoriaMetrics, Grafana Mimir, управляемый Prometheus. Поддержка без аутентификации, с Secret на namespace или с единой идентификацией оператора для кластера с исключениями для отдельных namespace. Кастомные заголовки и TLS.

  • Автообнаружение Prometheus: находит Prometheus через CRD оператора или общеизвестные имена сервисов, если адрес не задан явно.

  • Пакетные воркloadы: CronJob и Job для подбора ресурсов только в режиме рекомендаций. CREATE может по-прежнему задавать ресурсы для новых подов Job при включённом начальном sizing.

  • Дефолты на уровне namespace: AttuneNamespaceDefaults переопределяют кластерные дефолты отдельно для production и staging.

  • Обнаружение конфликтов: предупреждает о VPA, пересекающихся политиках или активных rollout’ах, нацеленных на тот же воркload.

  • Потребление рекомендаций VPA: использование существующих рекомендаций VerticalPodAutoscaler в качестве альтернативы запросам к Prometheus через metricsSource.vpa.

  • GitOps diff-команда: kubectl attune diff выводит рекомендации в формате diff для проверки в рабочих процессах ArgoCD/Flux.

  • Webhook начального sizing: задаёт ресурсы поду в момент создания на основе существующих рекомендаций политики, устраняя разрыв «деплой с плохими дефолтами».

  • Асимметричные лимиты изменений: maxIncreasePercent/maxDecreasePercent отдельно для каждого ресурса (снижение памяти рискованнее, чем увеличение CPU).

  • Вывод памяти из CPU: memoryFromCpuRatio вычисляет память на основе CPU для JVM и воркloadов, ограниченных кучей.

  • Приостановка reconcile: spec.paused: true останавливает всю активность без отмены существующих ресайзов.

  • Заморозка namespace: аннотируйте namespace attune.io/freeze=true, чтобы пропустить новые операции apply (resize, persist, CREATE). Ожидающий safety revert при этом всё равно выполнится. Рекомендации остаются в статусе.

  • Предупреждения webhook: 13 предупреждений на этапе admission для бессмысленных комбинаций конфигурации, 31 runtime-событие K8s и подавление на уровне отдельной политики.

Документация

Полная документация: attune-io.github.io/attune

Руководство Описание

docs/why-attune.md[Почему Attune?]

Суть проблемы, почему VPA не справляется, и как in-place ресайз меняет ситуацию

docs/savings-calculator.md[Калькулятор экономии]

Оцените ежемесячную экономию с помощью интерактивного калькулятора

docs/getting-started/installation.md[Установка]

Helm, OLM и сырые манифесты

docs/getting-started/quickstart.md[Быстрый старт]

Запуск за 5 минут

docs/getting-started/first-30-days.md[Первые 30 дней]

Пошаговое руководство от установки до режима Auto в production

docs/guides/prometheus-setup.md#choose-how-attune-authenticates[Настройка Prometheus]

Без аутентификации, per-namespace токен или единая идентификация оператора

docs/guides/migrating-from-vpa.md[Миграция с VPA]

Пошаговая замена VPA

docs/guides/hpa-coexistence.md[Совместная работа с HPA]

Использование рядом с HPA

docs/guides/slo-guardrails.md[SLO-ограничители]

Проверки работоспособности приложения через PromQL после ресайза

docs/guides/runtime-profiles.md[Runtime-профили]

Языково-зависимые дефолты для памяти

docs/guides/multi-cluster.md[Мультикластер]

Паттерны развёртывания, кросс-кластерные операции и постепенные rollout’ы

docs/guides/scaling.md[Руководство по масштабированию]

Пресеты размера кластера, тюнинг и HA-развёртывание

docs/guides/canary-rollout.md[Canary-rollout]

Стратегия постепенного применения изменений

docs/guides/startup-boost.md[Startup boost]

Временный запас CPU для холодного старта

docs/guides/upgrading.md[Обновление]

Обновление версий и обновление CRD

docs/reference/cli.md[Справочник CLI]

Команды плагина kubectl

docs/reference/api.md[Справочник API]

Спецификация CRD

docs/guides/troubleshooting.md[Устранение неполадок]

Типичные проблемы и их решения

examples/[Примеры]

Готовые к использованию манифесты политик

CONTRIBUTING.md[Вклад в проект]

Настройка окружения для разработки и правила работы

CHANGELOG.md[Changelog]

История релизов и критические изменения

ADOPTERS.md[Пользователи]

Организации, использующие Attune

Лицензия

Apache License 2.0. Подробности — в файле LICENSE[LICENSE].

Похожее

© 2026 meganuke