Какие существуют виды масштабирования в Kubernetes и как они работают?

Question

Какие существуют виды масштабирования в Kubernetes и как они работают?

Тип вопроса: DevOps Вероятность: 10% Категория: Golang Разработчик

Ответ

В Kubernetes существует три основных механизма автоматического масштабирования, работающих на разных уровнях:

Horizontal Pod Autoscaler (HPA) — Горизонтальное масштабирование подов
- Что делает: Автоматически изменяет количество реплик (подов) для Deployment, ReplicaSet или StatefulSet.
- Как работает: HPA периодически запрашивает метрики (по умолчанию — загрузка CPU и использование памяти) у Metrics Server. Если текущие значения превышают или становятся значительно ниже целевых, HPA изменяет количество реплик.
- Пример: Если целевая загрузка CPU установлена на 50%, а средняя загрузка по всем подам достигает 75%, HPA создаст новые поды, чтобы снизить среднюю нагрузку.
```
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
```
Vertical Pod Autoscaler (VPA) — Вертикальное масштабирование подов
- Что делает: Автоматически настраивает запросы (requests) и лимиты (limits) на CPU и память для существующих подов.
- Как работает: VPA анализирует историческое потребление ресурсов подами и предлагает оптимальные значения. Для применения новых значений VPA перезапускает под, что может привести к кратковременной недоступности.
- Основное применение: Чаще используется в режиме "рекомендаций" для подбора оптимальных resources на этапе разработки и тестирования.
Cluster Autoscaler (CA) — Масштабирование кластера
- Что делает: Автоматически добавляет или удаляет узлы (ноды, виртуальные машины) в кластере.
- Как работает: CA следит за подами в состоянии Pending. Если под не может быть размещен из-за нехватки ресурсов (CPU, RAM) на всех доступных нодах, CA обращается к API облачного провайдера (AWS, GCP, Azure) и заказывает новую ноду. Он также может удалять недостаточно загруженные ноды для экономии средств.

Ключевые особенности:

HPA и VPA несовместимы: Нельзя одновременно использовать HPA и VPA для управления одними и теми же метриками (CPU/память).
HPA идеально подходит для stateless-приложений.
CA необходим в облачных средах для эффективного управления стоимостью инфраструктуры.

Ответ 18+ 🔞

Слушай, а ведь в этом вашем кубернетесе есть три главных способа, как система сама может подкрутить гайки, когда нагрузка скачет. И каждый работает на своём уровне, как будто у тебя три разных начальника: один мебель переставляет, второй стены двигает, а третий вообще офис новый арендует.

Первый — Horizontal Pod Autoscaler (HPA). Это как раздавать работу на большее количество работяг.

Суть: Этот тип просто плодит или утилизирует копии твоего приложения (поды) в деплойменте. Нагрузка выросла — он кричит "А ну добавили реплик, живо!" Нагрузка упала — "Так, пацаны, двоих на выход, остальные работают!"
Как охуевает: Он тупо смотрит на метрики (обычно процы и память), которые ему стучит Metrics Server. Если средняя загрузка проца по всем подам, допустим, 75%, а целевая была 50%, он такой: "Ёпта, народ перегружен, давайте ещё двоих на подхват!" И создаёт новые поды.
Вот тебе бумажка (манифест), как его завести:

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

Второй — Vertical Pod Autoscaler (VPA). Это как дать каждому работяге более мощную тачку.

Суть: Он не плодит народ, а смотрит на каждого конкретного под-работягу и говорит: "Слушай, дружок, я гляжу историю, ты постоянно на 90% памяти висишь. Давай-ка я тебе лимитов побольше выпишу!" Или наоборот: "Чувак, ты процы только на 5% грузишь, зачем тебе столько? Экономить будем!"
Подвох: Чтобы новые лимиты применить, он этого бедолагу-под перезапускает. То есть на пару секунд приложение может просто "лечь". Не айс для критичных штук. Поэтому его часто используют просто как умного советчика на этапе настройки, чтобы понять, сколько же ресурсов на самом деле жрёт твоё творение.

Третий — Cluster Autoscaler (CA). Это уже начальник всего офиса, который новые этажи арендует.

Суть: Он работает на уровне узлов (нод) — тех самых виртуальных машинок. Если все поды-работяги уже втиснулись в имеющиеся ноды-офисы, а новый под висит в состоянии Pending (типа "ребята, мне негде сесть!"), CA идёт в API облака (AWS, GCP) и орёт: "Дайте нам ещё одну машину, срочно!" И наоборот, если в офисе-ноде все сидят, уткнувшись в мониторы и делая вид, что работают, CA её просто выключает, чтобы за электричество не платить.

А теперь главное, что нужно запомнить, чтобы не было пиздеца:

HPA и VPA — как кошка с собакой. Нельзя одновременно доверить и CPU, и память и тому, и другому. Они начнут друг другу мешать, как два пьяных сантехника на одной маленькой кухне. Выбери одного.
HPA — царь и бог для stateless-приложений, которым лишь бы копий побольше.
CA — это must have в облаке, если не хочешь, чтобы твой кластер стоил, как яхта олигарха, при этом простаивая вполсилы.

Вот такая, блядь, матрёшка из автомасштабирования получается. Один внутри другого, а третий сверху всё это хозяйство в облаке тасует. Ёперный театр, а не система!