Работа с ресурсами в Kubernetes. CPU Manager. HPA, VPA, Multidimensional Pod Autoscaler.
Введение
Эффективное использование ресурсов, таких как CPU, является важным вопросом для обеспечения высокой производительности и эффективности работы приложений. В данной статье мы рассмотрим различные аспекты работы с ресурсами в Kubernetes, и такими абстракциями как CPU Manager, Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA) и Multidimensional Pod Autoscaler.
Работа с ресурсами в Kubernetes
Kubernetes предоставляет механизмы для управления ресурсами, включая CPU. Каждый контейнер в Pod может запросить определенное количество CPU, которое будет использоваться при планировании на узлах кластера. Разработчики могут указать requests и limits CPU в спецификации контейнера. Requests CPU используется для планирования, а limits - для контроля доступных ресурсов. Таким же образом мы можем управлять памятью. И при необходмости пользователи Kubernetes могут определять свои собственные кастомные ресурсы в зависимости от требований и характеристик своих приложений.
Приложения в контейнерах видят доступные ресурсы CPU через абстракцию. Внутри контейнера, приложение работает в изолированном пространстве и воспринимает ресурсы, предоставленные контейнером, как доступные для его использования.
Когда вы определяете ресурсы CPU для контейнера в манифесте Pod, эти параметры используются для управления ресурсами на уровне хоста и присвоения соответствующих ограничений и запросов для контейнера.
Например, если у вас есть Pod с контейнером, в манифесте которого указано:
1
2
3
4
5
6
7
8
9
resources:
requests:
cpu: "0.5"
memory: "64Mi"
mycustomresource: 1000
limits:
cpu: "1"
memory: "128Mi"
mycustomresource: 1500
Это означает, что контейнер запрашивает 0.5 CPU и имеет ограничение в 1 CPU. Та же логика и с другими ресурсами в примере. Kubernetes будет управлять этими ресурсами на уровне хоста. Внутри контейнера, приложение видит ресурсы, как если бы оно было запущено на выделенной физической или виртуальной машине с указанным количеством CPU. Обычно внутри контейнера процессы видят ресурсы CPU аналогично тому, как они видятся на уровне операционной системы.
CPU Manager, классы CPU
CPU Manager - это компонент Kubernetes, предназначенный для управления ресурсами центрального процессора (CPU) на уровне узла. Этот инструмент дает возможность определить различные классы CPU и управлять доступом к ним со стороны контейнеров и Pod’ов в кластере.
Разделяемый пул (Shared Pool)
В этом режиме несколько Pod’ов могут совместно использовать ресурсы CPU на уровне узла. Это подходит для приложений, которые могут эффективно работать параллельно и не требуют полного выделения ресурсов.
Гарантированный пул (Guaranteed Pool)
В режиме гарантированного пула каждый Pod получает гарантированное количество вычислительных ресурсов. Это особенно полезно для приложений, которым требуется предсказуемый и гарантированный доступ к ресурсам.
CPU Manager включает два ключевых компонента Kubelet CPU Manager и Kube-controller-manager CPU Manager.
Kubelet CPU Manager этот компонент находится на уровне Kubelet и отвечает за управление CPU на уровне узла. Он следит за запросами классов CPU и назначает соответствующие классы Pod’ам.
Kube-controller-manager CPU Manager этот компонент обрабатывает аннотации Pod’ов и контролирует, какие классы CPU они запрашивают. В случае несоответствия настройкам кластера, CPU Manager управляет коррекцией.
CPU Manager позволяет более точно управлять выделением ресурсов CPU, что приводит к оптимизации использования ресурсов кластера. Разработчики могут настраивать классы CPU в зависимости от требований своих приложений, выбирая между разделяемым пулом и гарантированным пулом. Режим гарантированного пула обеспечивает приложениям предсказуемый доступ к ресурсам, что особенно важно для приложений с высокими требованиями к производительности. В целом, CPU Manager в Kubernetes представляет собой мощный механизм управления ресурсами CPU, который помогает оптимизировать работу приложений и обеспечивать эффективное использование вычислительных ресурсов кластера.
QoS классы
Если вы новичок в Kubernetes, для начала лучше всего использовать значения limits точно такие же как и requests - это обеспечит так называемый “гарантированный класс качества сервиса” (Guaranteed QoS class). С другой стороны, класс Burstable QoS потенциально позволяет более эффективно использовать ресурсы инфраструктуры, правда, за счет большей непредсказуемости - например, рост CPU-latency может повлиять на остальные поды/контейнеры, запущенные на том же рабочем узле (ноде). В Kubernetes QoS классы используются в соответствии с наличием и конфигурацией requests и limits.
Если для всех контейнеров пода установлены отличные от 0 requests и limits для всех типов ресурсов, и эти значения равны, то pod будет принадлежать к классу Guaranteed. Если для одного или нескольких контейнера пода установлены отличные от 0 requests и limits для одного или всех типов ресурсов и эти значения не равны, то под будет принадлежать к классу Burstable. Если для всех контейнеров пода не установлены значения requests и limits для всех типов ресурсов, то поду будет присвоен класс Best-Effort.
Примеры
- Этот pod работает в классе качества обслуживания (QoS) BestEffort, потому что не указаны requests или limits ресурсов. Он выполняется в Shared Pool.
1 2 3 4
spec: containers: - name: nginx image: nginx
- Этот pod работает в классе качества обслуживания (QoS) Burstable, потому что запросы requests не равны их limits, и значение cpu не указано. Он выполняется в Shared Pool.
1 2 3 4 5 6 7 8 9
spec: containers: - name: nginx image: nginx resources: limits: memory: "200Mi" requests: memory: "100Mi"
- Этот pod работает в классе качества обслуживания (QoS) Burstable, потому что запросы requests не равны их limits. Он выполняется в Shared Pool.
1 2 3 4 5 6 7 8 9 10 11
spec: containers: - name: nginx image: nginx resources: limits: memory: "200Mi" cpu: "2" requests: memory: "100Mi" cpu: "1"
- Этот pod работает в классе качества обслуживания (QoS) Guaranteed потому что requests равны limits. И limits для CPU целое число, большее или равное единице. Контейнер nginx гарантированно получит 2 CPUs.
1 2 3 4 5 6 7 8 9 10 11
spec: containers: - name: nginx image: nginx resources: limits: memory: "200Mi" cpu: "2" requests: memory: "200Mi" cpu: "2"
- Этот pod работает в классе качества обслуживания (QoS) Guaranteed потому что requests равны limits. Однако limits ресурса CPU для контейнера представляет собой дробное число. Он выполняется в Shared Pool.
1 2 3 4 5 6 7 8 9 10 11
spec: containers: - name: nginx image: nginx resources: limits: memory: "200Mi" cpu: "1.5" requests: memory: "200Mi" cpu: "1.5"
- Этот pod работаетв классе качества обслуживания (QoS) Guaranteed, поскольку указаны только лимиты, а запросы установлены равными лимитам, если явно не указано иное. Лимит ресурса CPU для контейнера является целым числом, большим или равным единице. Контейнер nginx получает выделенные 2 CPUs.
1 2 3 4 5 6 7 8
spec: containers: - name: nginx image: nginx resources: limits: memory: "200Mi" cpu: "2"
HPA
HPA (Horizontal Pod Autoscaler) - предназначен для автоматического масштабирования приложений в горизонтальном направлении. Горизонтальное масштабирование означает изменение количества экземпляров приложения (pods) в кластере. Работа HPA основывается на метриках, которые определяют текущую нагрузку на приложение. Когда эти метрики превышают или опускаются ниже заданных уровней, HPA автоматически изменяет количество экземпляров приложения, чтобы обеспечить оптимальную производительность.
По умолчанию HPA масштабирует нагрузку на основе метрик подов, таких как среднее использование CPU/memory и общее использование подов. Также можно использовать внешние или настроенные метрики. После первоначальной настройки он может автоматически адаптироваться - вам нужно только определить минимальное и максимальное количество реплик в соответствии с вашими потребностями или запросами.
Ответственность за проверку метрик и масштабирование реплик лежит на контроллере HPA, который добавляет или удаляет поды в зависимости от обстановки. Этот процесс происходит автоматически, но иногда можно учесть предсказуемые ситуации в требованиях к нагрузке. HPA работает по принципу цикла, проверяя, обновляя и затем снова проверяя метрики.
На первом этапе цикла HPA контроллер постоянно мониторит использование ресурсов (например, CPU, memory и другие пользовательские метрики) через сервер метрик. Затем HPA вычисляет оптимальное количество реплик на основе требований к ресурсам. Затем автомасштабировщик решает, стоит ли масштабировать приложение вверх или вниз. На последнем этапе цикла HPA реализует целевое количество реплик.
Поскольку HPA представляет собой непрерывный мониторинг, этот цикл повторяется сразу после завершения. Интервал проверок HPA по умолчанию - 30 секунд. Чтобы изменить значение интервала, используйте флаг –horizontal-pod-autoscaler-sync-period в контроллере менеджера.
API-версия HPA autoscaling/v1 поддерживает только метрику среднего использования CPU. API-версия HPA autoscaling/v2 позволяет масштабировать с учетом использования памяти, задавать пользовательские метрики и использовать несколько метрик в одном объекте HPA.
Пример
Этот пример создает HPA с именем “my-microservice-hpa”, нацеленный на развертывание “my-microservice” с минимальным количеством реплик 1 и максимальным количеством реплик 2. Масштабирование осуществляется на основе метрик использования ресурсов для памяти и CPU, соответственно. Пороги установлены на 160% использования памяти и 50% использования CPU.
scaleTargetRef: Определяет целевой ресурс, на который будет воздействовать HPA.
minReplicas и maxReplicas: Устанавливают минимальное и максимальное количество реплик подов, которые HPA может управлять. В данном случае, минимальное количество реплик - 1, максимальное - 2.
metrics: Определяет метрики, на основе которых HPA будет регулировать количество реплик. Два блока метрик, один для памяти (memory) и один для CPU (cpu). В каждом блоке указывается тип метрики (type: Resource), указывается имя ресурса (name: memory или name: cpu), и определяются целевые значения использования ресурсов (память и CPU) в процентах (averageUtilization: 160 и averageUtilization: 50 соответственно).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-microservice-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-microservice
minReplicas: 1
maxReplicas: 2
metrics:
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 160
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
VPA
Vertical Pod Autoscaler (VPA) - это инструмент, который автоматически регулирует ресурсы (CPU и память) для контейнеров в вашем кластере на основе наблюдаемых параметров использования ресурсов. Он позволяет управлять вертикальным масштабированием, то есть изменением ресурсов, выделенных для контейнера, чтобы удовлетворять его текущим потребностям. Основная цель VPA — уменьшить потери ресурсов и минимизировать риск снижения производительности из-за троттлинга CPU или ошибок, вызванных «убийством» pod’ов из-за Out Of Memory.
У VPA есть следующие режимы работы:
- “Auto” (default) — в данный момент режимы работы Auto и Recreate делают одно и то же. Однако, когда в kubernetes появится Pod in-place resource update, данный режим будет делать именно его.
- “Recreate” — данный режим разрешает VPA изменять ресурсы у запущенных подов, то есть рестартить их при работе. В случае работы одного пода (replicas: 1) это приведет к недоступности сервиса на время рестарта. В данном режиме VPA не пересоздает поды, которые были созданы без контроллера.
- “Initial” — VPA изменяет ресурсы подов только при создании подов, но не во время работы.
- “Off” — VPA не изменяет автоматически никакие ресурсы. В данном случае, если есть VPA c таким режимом работы, мы можем посмотреть, какие ресурсы рекомендует поставить VPA (kubectl describe vpa ).
Пример
В этом примере targetRef указывает на целевой ресурс, который VPA должен масштабировать (например, Deployment). updatePolicy определяет, как VPA должен обновлять размеры подов. “Auto” означает, что VPA автоматически обновляет размеры. Поля resources в Deployment должны быть заполнены, VPA будет анализировать использование ресурсов и рекомендовать обновления для размеров CPU и памяти.
1
2
3
4
5
6
7
8
9
10
11
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: example-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: example-deployment
updatePolicy:
updateMode: "Auto"
MPA
Multidimensional Pod autoscaling (MPA) - это передовой подход оптимизирует использование ресурсов и повышает производительность приложения в сложных сценариях и освобождает вас от выбора единственного способа масштабирования. С помощью многомерного модуля автоматического масштабирования вы можете одновременно использовать горизонтальное масштабирование на основе процессора и вертикальное масштабирование на основе памяти. Объект MultidimPodAutoscaler изменяет запросы к памяти и добавляет реплики таким образом, чтобы средняя загрузка процессора каждой реплики соответствовала вашей целевой загрузке.
Пример
Создав этот подробный манифест MPA, вы предоставляете Kubernetes точные инструкции о том, как интерпретировать и реагировать на изменения каждой метрики. В результате ваш кластер Kubernetes получает интеллект для динамического масштабирования ваших pod, достигая оптимальной производительности и эффективного распределения ресурсов в сложных сценариях. Я не стал описывать значения каждого поля так как по сути это объединение HPA и VPA.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: autoscaling/v2
kind: MultidimensionalPodAutoscaler
metadata:
name: sample-app-mpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: sample-app-deployment
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 60
- type: Custom
resource:
name: custom-metric
target:
type: Value
value: 1000
Заключение
Изучение и применение масштабирования подов в Kubernetes представляют собой важный ресурс для оптимизации ресурсов и управления нагрузкой. HPA, VPA и MPA предоставляют различные подходы к масштабированию, отвечая на разнообразные потребности приложений.
HPA обеспечивает гибкость горизонтального масштабирования, VPA управляет ресурсами в каждой реплике, а MPA предоставляет возможность использовать горизонтальное и вертикальное масштабирование одновременно.
Эти инструменты предоставляют разработчикам возможность точной настройки и улучшения производительности приложений в Kubernetes. Пусть эти стратегии масштабирования станут вашим надежным инструментом в работе с изменчивыми требованиями и обеспечат более эффективное функционирование ваших кластеров.