ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить auto-scaling с учётом cost

1. Цель задачи

Научиться проектировать и настраивать систему автоматического масштабирования (auto-scaling) для микросервисов, которая минимизирует затраты на облачные ресурсы при сохранении надёжности (reliability) на уровне 99%. В рамках задачи необходимо реализовать гибридную стратегию: критически важные (онлайн) сервисы размещать на on-demand инстансах, а фоновые пакетные (batch) нагрузки — на spot/preemptible инстансах. В результате ожидается снижение совокупной стоимости инфраструктуры на 40% по сравнению с исходной (all on-demand) без превышения целевого порога ошибок.

Ключевой результат Конфигурация HPA (Horizontal Pod Autoscaler) и Cluster Autoscaler (или Karpenter) в Kubernetes-кластере, с метриками cost и reliability, подтверждающими 40% экономию при сохранении 99% успешных запросов.

2. Исходные данные

Перед началом необходимо иметь:

Если нет реального облака с поддержкой spot — симулируем:

1. Развернуть локальный кластер с minikube или kind
2. Создать две группы нод (label: instance-type=on-demand и instance-type=spot) с разными ценами в симуляции (например, стоимость spot = 30% от on-demand)
3. Написать скрипт на Python, который эмулирует eviction spot-ноды (удаление пода) и фиксирует время перезапуска
4. Использовать metrics-server или custom Prometheus exporter для метрик

3. Технологический стек

4. Этапы выполнения

Этап 1: Анализ текущего ландшафта и определение baseline (1–2 часа)

Действия

1. Инвентаризация сервисов

   • Разделить все микросервисы на два класса:
     • Критические (on‑demand): сервисы с требованиями к низкой задержке, без возможности перезапуска (фронт, API‑шлюз, пользовательские сессии).
     • Batch: фоновые задачи, ETL, обработка очередей, обучение моделей, которые могут быть прерваны и перезапущены позже.

2. Замерить baseline стоимости

   • Рассчитать текущие затраты за последние 30 дней: C_base = sum(price_per_instance_type * runtime_hours)
   • Определить текущую reliability: % успешных запросов (2xx) от общего трафика, исключая planned maintenance.
   • Если нет исторических данных — запустить нагрузочное тестирование на all on-demand в течение 2 часов и зафиксировать метрики.

3. Установить целевые показатели

   • Target cost: C_target = C_base * 0.6
   • Target reliability: ≥ 99%

Ожидаемый результат этапа
Документ с классификацией сервисов, текущими затратами и целевыми показателями. В репозитории — baseline.yml (файл с метриками).

Этап 2: Конфигурация spot-инстансов и taints/tolerations (2–3 часа)

Действия

1. Создать nodeGroup / nodePool для spot-инстансов

   • AWS: eksctl -> managedNodeGroup с spot: true
   • GKE: node pool с spot (preemptible VMs)
   • Локальная симуляция: добавить две tainted ноды (instance-type=spot:NoSchedule)

   # Пример для GKE (terraform)
   resource "google_container_node_pool" "spot" {
     name       = "spot-pool"
     node_count = 2
     node_config {
       preemptible = true
       machine_type = "e2-standard-4"
       labels = {
         "instance-type" = "spot"
       }
       taint {
         key    = "instance-type"
         value  = "spot"
         effect = "NO_SCHEDULE"
       }
     }
   }
   

2. Настроить tolerations для batch-сервисов

   • Каждый batch‑deployment получает toleration instance-type=spot:NoSchedule и nodeSelector instance-type: spot.

3. Настроить Pod Disruption Budget (PDB) для batch-сервисов

   • maxUnavailable: 50% — чтобы при eviction ноды не падала вся обработка.

Ожидаемый результат этапа
Spot-ноды запущены, batch-сервисы успешно запускаются на них, on‑demand сервисы остаются на обычных нодах.

Этап 3: Настройка автоскейлинга подов (HPA + KEDA) (2–3 часа)

Действия

1. Установить metrics-server и Prometheus Adapter

   • Убедиться, что HPA может читать кастомные метрики (например, requests-per-second).

2. Создать HPA для критического сервиса (on‑demand)

   • Метрика: средняя загрузка CPU (target 70%) + дополнительно request latency P99.
   • Поведение: стабильное (scale-up быстрее, scale-down медленнее).
   • minReplicas: 2, maxReplicas: 20.

3. Создать KEDA ScaledObject для batch-сервиса

   • Использовать очередь (RabbitMQ / Kafka / AWS SQS) как триггер масштабирования.
   • cooldownPeriod: 120 секунд — чтобы избежать флаппинга при eviction.
   • Параметр fallback — при недоступности очереди использовать minReplicas.

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: batch-worker
   spec:
     scaleTargetRef:
       name: batch-deployment
     triggers:
     - type: prometheus
       metadata:
         serverAddress: http://prometheus.svc:9090
         metricName: queue_depth
         query: sum(queue_size)
         threshold: '10'
   

4. Настроить HorizontalPodAutoscaler для batch (опционально)

   • Если KEDA не используется — кастомный HPA с метрикой из очереди через Prometheus Adapter.

Ожидаемый результат этапа
Поды batch автоматически масштабируются под длину очереди, поды online — под CPU/латенси. Все поды правильно распределены по нодам.

Этап 4: Настройка автоскейлинга нод (Cluster Autoscaler / Karpenter) (2–3 часа)

Действия

1. Установить Cluster Autoscaler (CA)

   • Настроить --balance-similar-node-groups для равномерного использования on‑demand и spot.
   • Задать --max-nodes-per-group = 20 для spot, 10 для on‑demand.

2. Настроить overprovisioning (buffer)

   • Создать PriorityClass для low‑priority пойлов, которые будут вытесняться первыми при нехватке ресурсов.
   • Развернуть дополнительную «медленную» ноду с Cluster Proportional Autoscaler для ускорения scale‑up.

3. Настроить Karpenter (опционально, более гибкий)

   • Provisioner с двумя requirements:
     • critical → karpenter.sh/capacity-type: on-demand
     • batch → karpenter.sh/capacity-type: spot

   apiVersion: karpenter.sh/v1alpha5
   kind: Provisioner
   metadata:
     name: default
   spec:
     requirements:
       - key: karpenter.sh/capacity-type
         operator: In
         values: ["on-demand", "spot"]   # оба типа
     limits:
       resources:
         cpu: 1000
     provider:
       instanceProfile: karpenter-node
     taints:
       - key: instance-type
         value: spot
         effect: NoSchedule
   

4. Проверить graceful shutdown batch-подов при eviction

   • Добавить preStop хук и terminationGracePeriodSeconds: 30.

Ожидаемый результат этапа
Cluster Autoscaler (или Karpenter) добавляет/удаляет ноды в зависимости от нагрузки. Spot-ноды могут быть прерваны без потери данных — batch-поды переезжают.

Этап 5: Сбор метрик cost, reliability и оптимизация (3–4 часа)

Действия

1. Установить Kubecost / OpenCost

   • Связать с облачным биллингом (AWS CUR, GCP Billing Export).
   • Настроить алерты на превышение бюджета.

2. Запустить нагрузочное тестирование

   • Использовать locust или k6 для симуляции смешанной нагрузки (70% online, 30% batch).
   • Длительность: 4–6 часов (включая 1 час пик).
   • Фиксировать метрики cost (Kubecost), reliability (Grafana % 2xx).

3. Рассчитать фактическую экономию

   • savings = (C_base - C_new) / C_base * 100%
   • Если savings < 40% → увеличить долю batch-нагрузки на spot или уменьшить minReplicas on‑demand.

4. Проверить reliability

   • reliability = (total_requests - error_requests) / total_requests * 100%
   • Если ниже 99% → увеличить PDB, добавить fallback реплик, настроить предварительный warm-up.

Ожидаемый результат этапа
Отчёт с графиками: стоимость по часам, количество eviction, latency, количество реплик. Подтверждение достижения цели.

5. Критерии приемки (Definition of Done)

• Классификация всех сервисов на critical и batch зафиксирована в конфигурации (labels, taints, tolerations).
• Spot-ноды созданы и корректно размечены; batch-сервисы запускаются только на них.
• HPA (или KEDA) для critical сервисов настроен, масштабирование происходит по CPU/latency.
• Batch-сервисы масштабируются на основе длины очереди (или другой метрики).
• Cluster Autoscaler / Karpenter добавлен и работает: ноды создаются/удаляются, поды переезжают при eviction (graceful).
• Средняя стоимость инфраструктуры за тестовый период снизилась не менее чем на 40% по сравнению с baseline all on‑demand.
• Reliability (доля успешных запросов) за тестовый период ≥ 99%.
• Развёрнут дашборд Grafana, отображающий cost breakdown (on‑demand vs spot) и reliability (SLO).
• Настроены алерты: при превышении budget на 10%, при падении reliability ниже 98.5%.
• Документация: README с описанием архитектуры, инструкция по воспроизведению, скриншоты дашборда.

6. Ожидаемый результат

Основной артефакт Репозиторий с конфигурациями Kubernetes (YAML/Helm) и скриптами для развёртывания.

• cost-scaling/
  • hpa-critical.yaml
  • keda-batch.yaml
  • cluster-autoscaler-values.yaml
  • node-pools.yaml (terraform или eksctl)
  • pdb-batch.yaml
• monitoring/
  • grafana-dashboard-cost-reliability.json
  • prometheus-rules.yaml
• testing/
  • locustfile.py
  • baseline-cost-export.csv

Содержание отчёта

• График стоимости: week over week, разбивка on‑demand / spot.
• График reliability (P99 latency, error budget).
• Таблица с показателями «до» и «после».

Дополнительно (опционально):

• Pull-request с изменениями в production-конфиги.
• Runbook по обработке eviction batch-подов.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание При первом выполнении задачи добавьте 30% буфера на отладку и неожиданные проблемы с облачными квотами.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я разделил сервисы на critical и batch, и это отражено в конфигах (labels, tolerations, nodeSelector).
• Spot-ноды созданы и протестированы — batch-поды запускаются только на них.
• HPA для critical сервисов настроен, метрики (CPU, latency) передаются корректно.
• KEDA (или custom HPA) масштабирует batch-сервисы по очереди, и я проверил реакцию на пустую/заполненную очередь.
• Cluster Autoscaler (или Karpenter) добавлен в кластер, и я проверил логи scale‑up/scale‑down.
• Kubecost показывает cost per service и per node type, я сравнил с baseline.
• Я запустил тестовую нагрузку на 4+ часа, reliability ≥ 99%, экономия ≥ 40%.
• Настроены алерты на budget и reliability, дашборд Grafana отображает обе метрики.
• Вся документация написана: README, YAML-файлы, инструкция по воспроизведению.
• Я проверил graceful shutdown batch-пода (preStop хук, PDB) — данные не теряются.