Автомасштабирование сервисов Compose

Требования

• Сервис compose должен быть частью стека (compose, развёрнутый в Swarm), а не обычного развёртывания Docker Compose.
• Для организации должен быть включён Swarm Monitoring — автомасштабирование использует те же метрики CPU/памяти по репликам.
• Runtime-сервис Swarm (${appName}_${serviceName}) должен быть replicated сервисом; global- и job-сервисы пропускаются.

Настройка

Откройте вкладку Advanced compose-стека. Карточка Autoscaling появляется, когда выполнены оба требования выше. Выберите сервис и задайте:

• Enable autoscaling — пока включено, число реплик управляется автоматически; ручные изменения числа реплик, сделанные где-либо ещё, будут перезаписаны на следующем тике.
• Min / Max Replicas — значения по умолчанию 2 / 15.
• CPU Scale-Up (%) / CPU Scale-Down (%) — по умолчанию 85 / 25.
• Memory Scale-Up (%) / Memory Scale-Down (%) — по умолчанию 85 / 25.

sustainedChecks (по умолчанию 3), cooldownMinutes (по умолчанию 5) и stepSize (по умолчанию 1) в этой форме не показаны — используются значения по умолчанию, если не заданы напрямую через API (см. ниже).

Чтение конфигураций требует права autoscaler.read в кастомной роли; сохранение требует autoscaler.update. Оба эндпоинта также проверяют, что compose-стек принадлежит вашей активной организации.

Логика принятия решения о масштабировании

Фоновая задача запускается каждую минуту для каждой включённой конфигурации (compose, сервис). Она читает среднее значение CPU/памяти за последние 5 минут и принимает решение:

• Масштабирование вверх на stepSize реплик (не выше maxReplicas), когда CPU выше targetCpuMax или память выше targetMemMax, превышение держится sustainedChecks подряд идущих тиков, и с последнего действия масштабирования прошло cooldownMinutes.
• Масштабирование вниз на stepSize реплик (не ниже minReplicas), когда CPU ниже targetCpuMin и память ниже targetMemMin (память игнорируется при отсутствии данных по ней), и cooldown истёк.
• В остальных случаях — в «мёртвой зоне» между порогами, во время cooldown или уже на границе — ничего не происходит.

Сервис масштабируется на месте через живой docker service update, а не полный docker stack deploy, поэтому остальная часть спецификации compose не затрагивается. Итоговое число реплик сохраняется и повторно применяется при следующем реальном docker stack deploy, так что редеплой не затирает автоматически подобранное число реплик. Если для сервиса нет свежих метрик, сервис отсутствует, или масштабирование завершилось ошибкой — это логируется, и тик переходит к следующему сервису, не прерываясь целиком.

API

POST /api/trpc/autoscaler.list
POST /api/trpc/autoscaler.upsert

list возвращает все конфигурации сервисов для compose-стека:

{ "composeId": "compose_123" }

upsert создаёт или обновляет конфигурацию одного сервиса:

{
  "composeId": "compose_123",
  "serviceName": "web",
  "enabled": true,
  "minReplicas": 2,
  "maxReplicas": 10,
  "targetCpuMax": 80,
  "targetCpuMin": 20,
  "targetMemMax": 80,
  "targetMemMin": 20,
  "sustainedChecks": 3,
  "cooldownMinutes": 5,
  "stepSize": 1
}

Все поля, кроме composeId и serviceName, опциональны и патчат только переданные значения. API отклоняет патч, где minReplicas > maxReplicas, targetCpuMin >= targetCpuMax или targetMemMin >= targetMemMax (проверяется, только когда обе стороны пары присутствуют). minReplicas/maxReplicas принимают 1–100, цели по CPU/памяти — 1–100, sustainedChecks — 1–60, cooldownMinutes — 0–1440, stepSize — 1–10. Каждый upsert записывается в журнал аудита организации как обновление autoscaler-config.