Kubernetes

Теория: Ограничения ресурсов и автоматическое масштабирование

Полный доступ к материалам

Зарегистрируйтесь и получите доступ к этому и десяткам других курсов

Каждый контейнер потребляет CPU и память. Без ограничений один контейнер может захватить все ресурсы узла, что приведёт к деградации или падению других приложений. Kubernetes позволяет задавать requests (запрос) и limits (ограничение) для ресурсов.

Requests: планирование ресурсов

requests указывает минимальные ресурсы, необходимые контейнеру. Kubernetes использует эту информацию для планирования: Pod размещается только на узле, где достаточно свободных ресурсов.

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"

Если на всех узлах недостаточно ресурсов, Pod останется в состоянии Pending. Это гарантирует, что приложение не будет запущено в условиях нехватки ресурсов.

Единицы измерения CPU: миллиядра (m). 100m = 0.1 CPU = 10% одного ядра. 1000m = 1 CPU = одно полное ядро.

Единицы измерения памяти: байты. 128Mi = 128 мебибайт (1 Mi = 1024 × 1024 байт), 1Gi = 1 гибибайт.

Limits: ограничение ресурсов

limits устанавливает максимальное потребление ресурсов. Контейнер не может использовать больше указанного лимита.

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

Для CPU: если контейнер пытается использовать больше, чем limit, он будет throttled (ограничен). Приложение продолжит работать, но медленнее.

Для памяти: если контейнер превышает limit, он будет убит (OOMKilled — Out Of Memory Killed). Kubernetes перезапустит контейнер, но данные в памяти будут потеряны.

Quality of Service (QoS)

QoS (Quality of Service) — это механизм приоритизации Pod'ов при нехватке ресурсов на узле. Когда на узле заканчивается память, kubelet должен решить, какой Pod убить первым. QoS-класс — это критерий для принятия этого решения.

На основе requests и limits Kubernetes автоматически назначает каждому Pod один из трёх классов QoS:

Guaranteed — самый высокий приоритет. Назначается, когда requests равны limits для всех контейнеров Pod'а. Эти Pod'ы будут убиты последними при нехватке ресурсов:

resources:
  requests:
    memory: "256Mi"
    cpu: "200m"
  limits:
    memory: "256Mi"

    cpu: "200m"

Burstable — средний приоритет. Назначается, когда requests меньше limits или указаны только requests:

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"

    cpu: "200m"

BestEffort — самый низкий приоритет. Назначается, когда requests и limits не указаны вообще. Эти Pod'ы будут убиты первыми.

Практическая рекомендация: для production-приложений используйте Guaranteed или Burstable. BestEffort подходит только для некритичных задач, потерю которых можно допустить.

LimitRange

LimitRange — это политика на уровне namespace, которая задаёт значения по умолчанию и допустимые диапазоны для requests/limits. Это полезно, когда разработчики забывают указать ресурсы в своих манифестах.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: default
spec:
  limits:
    - max:
        memory: "1Gi"
        cpu: "1000m"
      min:
        memory: "64Mi"
        cpu: "50m"
      default:
        memory: "256Mi"
        cpu: "200m"
      defaultRequest:
        memory: "128Mi"
        cpu: "100m"

      type: Container

default — значения limits по умолчанию, если контейнер их не указал
defaultRequest — значения requests по умолчанию
min/max — допустимый диапазон; Pod с ресурсами вне диапазона не будет создан

ResourceQuota

ResourceQuota ограничивает суммарное потребление ресурсов всеми Pod'ами в namespace. Это инструмент для справедливого распределения ресурсов кластера между командами и защиты от случайного исчерпания ресурсов.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: default
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "10Gi"
    limits.cpu: "20"
    limits.memory: "20Gi"
    persistentvolumeclaims: "10"

    pods: "50"

С этой квотой невозможно создать больше 50 Pod в namespace или запросить суммарно больше 10 CPU. При попытке превысить квоту Kubernetes отклонит создание ресурса.

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

Horizontal Pod Autoscaler (HPA)

HPA автоматически изменяет количество реплик в Deployment на основе метрик. Это горизонтальное масштабирование: при росте нагрузки добавляются Pod'ы, при падении — удаляются.

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

В этом примере HPA поддерживает среднюю загрузку CPU на уровне 70% и памяти на уровне 80%. Целевые значения (70%, 80%) и диапазон реплик (2-10) — это параметры конкретного HPA, не глобальные настройки.

Создать HPA можно командой:

kubectl autoscale deployment web-app --cpu-percent=70 --min=2 --max=10

HPA требует metrics-server для получения метрик:

# Установить metrics-server
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Проверить метрики
kubectl top nodes
kubectl top pods

Настройка поведения масштабирования (behavior)

HPA проверяет метрики каждые 15 секунд (настраивается через --horizontal-pod-autoscaler-sync-period). Для предотвращения flapping (частых изменений) в autoscaling/v2 используется секция behavior с настраиваемыми параметрами:

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300  # ждать 5 минут стабильности перед уменьшением
    policies:
      - type: Percent
        value: 10
        periodSeconds: 60  # уменьшать не более 10% реплик за минуту
  scaleUp:
    stabilizationWindowSeconds: 0  # масштабировать вверх сразу
    policies:
      - type: Percent
        value: 100
        periodSeconds: 15  # удваивать реплики каждые 15 секунд при необходимости

stabilizationWindowSeconds — окно стабилизации. HPA выбирает максимальное (для scaleDown) или минимальное (для scaleUp) рекомендуемое количество реплик за этот период
policies — правила, ограничивающие скорость изменения (в процентах или абсолютных числах)

Custom Metrics

CPU и память не всегда отражают реальную нагрузку на приложение. Например, веб-сервис может иметь низкий CPU, но 10 000 запросов в очереди. Кастомные метрики (RPS, длина очереди, latency) позволяют масштабироваться по бизнес-показателям.

HPA поддерживает произвольные метрики через Custom Metrics API:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "1000"

Для работы кастомных метрик требуется установка адаптера (Prometheus Adapter, Datadog Cluster Agent, KEDA) и настройка экспорта метрик из приложения.

Cluster Autoscaler

HPA умеет создавать новые Pod'ы при росте нагрузки. Но Kubernetes может запустить Pod только если на ноде есть свободные ресурсы. Если CPU или память на всех нодах заняты, новые Pod'ы остаются в состоянии Pending с причиной Insufficient cpu или Insufficient memory.

Cluster Autoscaler отслеживает именно такие Pod'ы. Если в кластере появляются Pod'ы, которые не могут быть размещены из-за нехватки ресурсов, Cluster Autoscaler обращается к облачному провайдеру и увеличивает размер группы нод. В AWS это Auto Scaling Group, в GCP — Node Pool, в Azure — VM Scale Set. Облако создаёт новую виртуальную машину, она подключается к кластеру как новая нода, и Kubernetes размещает на ней ожидающие Pod'ы.

Когда нагрузка снижается, HPA удаляет лишние Pod'ы. Если после этого на нодах остаётся мало рабочих Pod'ов, Cluster Autoscaler удаляет лишние ноды и уменьшает размер группы.

Cluster Autoscaler работает отдельно от HPA. HPA управляет количеством Pod'ов. Cluster Autoscaler управляет количеством нод.

Vertical Pod Autoscaler (VPA)

В обычном манифесте Pod'а requests и limits задаются вручную. Если requests слишком маленькие, Pod может быть убит системой при нехватке ресурсов. Если requests слишком большие, Pod резервирует ресурсы, которые не использует, и снижает плотность размещения в кластере.

VPA анализирует фактическое потребление CPU и памяти контейнером. На основе собранных метрик он формирует рекомендации по новым значениям requests и limits.

В режиме Auto VPA автоматически изменяет эти значения и пересоздаёт Pod, чтобы новые параметры вступили в силу. В режиме Off VPA только показывает рекомендации, не изменяя Pod.

VPA изменяет размер одного Pod'а. Количество Pod'ов при этом не меняется.

Разница на конкретной ситуации

Deployment содержит один Pod сервиса. В манифесте указано:

requests:
  cpu: 100m
  memory: 256Mi

Фактически сервис стабильно потребляет:

cpu: 300m
memory: 600Mi`

Pod периодически завершается с OOMKilled. VPA фиксирует это потребление и обновляет requests и limits. Новый Pod запускается с корректными ресурсами. Количество Pod'ов не меняется.

Теперь другая ситуация. Pod работает стабильно, но входящий трафик вырос. Один Pod обрабатывает 100 запросов в секунду, требуется 500. HPA увеличивает количество Pod'ов до 5.

Если на нодах не хватает ресурсов, новые Pod'ы переходят в Pending. Cluster Autoscaler создаёт новую ноду. Pod'ы размещаются. Количество Pod'ов увеличилось, размер Pod'ов остался прежним.

PodDisruptionBudget

PodDisruptionBudget (PDB) ограничивает количество одновременно недоступных Pod при добровольных disruption (обновление узлов, drain, eviction):

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-app

Kubernetes гарантирует, что минимум 2 Pod с меткой app: web-app будут доступны. При обновлении узла система не сможет удалить Pod, если это нарушит PDB.

Альтернатива — указать максимум недоступных Pod:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: web-app

При 5 репликах может быть недоступен максимум 1 Pod. PDB не защищает от непредвиденных сбоев (crash узла, OOM), но обеспечивает доступность при плановых операциях.

Priority Classes

Priority Classes — механизм явного указания приоритета Pod'ов (в отличие от QoS, который вычисляется автоматически). Используется для preemption: Pod с высоким приоритетом может вытеснить Pod с низким приоритетом, если на узлах нет места.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "Для критичных production-сервисов"
preemptionPolicy: PreemptLowerPriority

Использование в Pod:

spec:
  priorityClassName: high-priority

Заключение

Надёжность и стабильность приложений в Kubernetes обеспечивается комплексом механизмов:

Requests и limits защищают приложения друг от друга и обеспечивают предсказуемую производительность.
QoS определяет порядок вытеснения Pod'ов при нехватке ресурсов.
LimitRange и ResourceQuota обеспечивают справедливое распределение ресурсов между командами.
HPA адаптирует количество Pod'ов к нагрузке, VPA оптимизирует ресурсы на Pod.
Cluster Autoscaler масштабирует инфраструктуру под потребности кластера.
PDB гарантирует доступность при плановых операциях.
Priority Classes позволяют явно управлять приоритетом Pod'ов.