Как скейлить приложение в Kubernetes

Принципы и стратегии скейлинга приложений в Kubernetes

Скейлинг в Kubernetes — это комплексный процесс, направленный на адаптацию приложения к изменяющейся нагрузке. Он охватывает несколько уровней и требует глубокого понимания архитектуры кластера и самого приложения.

1. Горизонтальный скейлинг подов (Horizontal Pod Autoscaling, HPA)

Это наиболее распространенный и эффективный способ. Horizontal Pod Autoscaler (HPA) автоматически увеличивает или уменьшает количество реплик пода (replicas) на основе наблюдаемой метрики (например, загрузки CPU, потребления памяти или пользовательских метрик).

Принцип работы: HPA периодически (по умолчанию каждые 15 секунд) опрашивает Metrics Server (или другие адаптеры, например, Prometheus Adapter для пользовательских метрик), вычисляет целевое количество подов по формуле и обновляет поле replicas у соответствующего ресурса (например, Deployment или StatefulSet).

Пример манифеста для HPA на основе CPU:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Ключевые моменты:

• scaleTargetRef: Указывает на масштабируемый ресурс (Deployment, StatefulSet и др.).
• minReplicas / maxReplicas: Устанавливают границы, предотвращая неконтролируемый рост или падение до нуля.
• Метрики: Можно использовать несколько метрик одновременно (CPU, Memory, Custom, External). HPA будет рассчитывать реплики для каждой и выбирать наибольшее значение.
• Поведение при скейлинге (behavior): Начиная с Kubernetes 1.18, можно тонко настраивать скорость масштабирования (скорость увеличения/уменьшения реплик, стабилизационные окна), чтобы избежать "дребезга" (thrashing).

2. Вертикальный скейлинг подов (Vertical Pod Autoscaling, VPA)

Vertical Pod Autoscaler (VPA) автоматически настраивает запросы (requests) и лимиты (limits) для CPU и памяти у подов. Это полезно, когда приложение не поддерживает горизонтальное масштабирование (не является stateless) или когда нагрузка характеризуется ростом потребления ресурсов на один экземпляр, а не их количеством.

Важно! VPA в режиме Auto (updateMode: Auto) для изменения ресурсов существующего пода пересоздает его. Это может приводить к простою, если не настроено graceful termination и readiness probes. Часто VPA используют в режиме Recommend (updateMode: "Off") для получения рекомендаций, которые затем применяют вручную при обновлении приложения.

3. Кластерный скейлинг (Cluster Autoscaler, CA)

Cluster Autoscaler (CA) автоматически масштабирует количество нод в кластере. Он работает в связке с HPA:

1. HPA пытается создать новые поды из-за высокой нагрузки.
2. Если для новых подов нет подходящих нод (не хватает ресурсов), поды переходят в состояние Pending.
3. CA обнаруживает поды в Pending, которые не могут быть размещены из-за нехватки ресурсов, и инициирует добавление новой ноды в пул нод (NodePool) облачного провайдера (GKE, EKS, AKS) или в on-premise среде.
4. Аналогично, CA удаляет ноды, которые стали ненужными (например, имеют низкое использование и их поды можно перераспределить на другие ноды).

4. Стратегии и практические рекомендации

Для эффективного скейлинга недостаточно просто включить HPA. Необходимо комплексное проектирование:

• Готовность приложения к горизонтальному масштабированию: Приложение должно быть stateless. Сессии пользователей необходимо хранить внешне (например, в Redis). Любое локальное состояние на диске или в памяти пода станет проблемой.
• Качество метрик: Используйте пользовательские метрики (Custom Metrics) на основе бизнес-логики (RPS - запросов в секунду, количество сообщений в очереди, 95-й перцентиль latency) вместо только CPU/Memory. CPU часто является слабым индикатором реальной нагрузки приложения.

  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100
  

• Настройка Resource Requests и Limits: Это критически важно. Без корректно заданных requests планировщик Kubernetes не сможет оптимально размещать поды, а HPA не будет иметь базовых значений для расчета утилизации. Лимиты предотвращают потребление всех ресурсов ноды одним неисправным подом.
• Readiness и Liveness Probes: Поды должны быстро становиться готовыми (ready) после запуска и своевременно сообщать о неисправностях. Без этого трафик может направляться на неготовые экземпляры, вызывая ошибки.
• Pod Disruption Budget (PDB): Защищает приложение от случайных потерь слишком большого количества подов одновременно при плановых операциях (обновление ноды, обновление кластера).

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: my-app-pdb
  spec:
    minAvailable: 60%
    selector:
      matchLabels:
        app: my-app
  

• Топологическое распределение (Topology Spread Constraints): Обеспечивает равномерное распределение подов приложения по зонам доступности (availability zones) или нодам, повышая отказоустойчивость.

  spec:
    topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app: my-app
  

Заключение

Скейлинг в Kubernetes — это многоуровневая автоматическая система, где HPA отвечает за масштабирование рабочей нагрузки, VPA — за оптимизацию ресурсов каждого экземпляра, а CA — за масштабирование инфраструктуры. Успех зависит от корректной настройки всех компонентов и, что еще важнее, от архитектуры самого приложения, которое должно быть спроектировано с учетом облачных и распределенных паттернов (stateless, resilience, observability). Начинать всегда стоит с настройки Resource Requests/Limits, Probes и развертывания Metrics Server, а затем подключать HPA на основе адекватных метрик.