Как выполнить масштабирование приложения в Kubernetes?

«Как выполнить масштабирование приложения в Kubernetes?» — вопрос из категории Kubernetes, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В Kubernetes есть несколько механизмов масштабирования, которые я использовал в зависимости от ситуации.

1. Ручное масштабирование Deployment или StatefulSet: Это самый простой способ для быстрого реагирования на известные события (например, начало распродажи).

kubectl scale deployment/web-api --replicas=5

2. Горизонтальное автоматическое масштабирование подов (HPA): Это основной метод для автоматической адаптации к изменяющейся нагрузке. HPA отслеживает метрики и регулирует количество реплик.

Пример манифеста HPA, нацеленного на среднюю утилизацию CPU в 70%:

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

3. Масштабирование на основе кастомных метрик: На одном из проектов нагрузка слабо коррелировала с CPU. Мы настроили HPA на метрику длины очереди RabbitMQ из Prometheus.

metrics:
- type: Pods
  pods:
    metric:
      name: rabbitmq_queue_messages
    target:
      type: AverageValue
      averageValue: 50

Ключевые условия для работы HPA:

  • В кластере должен быть установлен metrics-server для метрик ресурсов (CPU/Memory).
  • Для кастомных метрик нужен Prometheus и Prometheus Adapter.
  • У приложения должны быть корректно выставлены resource requests и limits в Pod-спецификации.

4. Вертикальное масштабирование (VPA): Использовал VPA (Vertical Pod Autoscaler) для stateful-приложений, где горизонтальное масштабирование затруднено. VPA автоматически настраивает значения requests и limits для контейнеров на основе исторического потребления. Однако его применение требует осторожности, так как при изменении ресурсов Pod может быть перезапущен.