Когда ваш бизнес начнет расти, вам нужно будет использовать функции автоматического масштабирования Kubernetes, чтобы ваше программное обеспечение росло вместе с ним.
Многие пользователи Kubernetes, особенно на корпоративном уровне, быстро сталкиваются с необходимостью автоматического масштабирования сред. К счастью, K8s Horizontal Pod Autoscaler (HPA) позволяет настроить развертывание для горизонтального масштабирования множеством способов. Одним из самых больших преимуществ использования Kube Autoscaling является то, что ваш кластер может отслеживать возможности загрузки ваших существующих модулей и вычислять, требуется ли больше модулей или нет.
Платформа автоматического масштабирования Kubernetes
Используйте эффективное автомасштабирование Kubernetes за счет гармонизации двух предлагаемых уровней масштабируемости:
- Автомасштабирование на уровне пода: эта плоскость включает горизонтальное автомасштабирование пода (HPA) и вертикальное автомасштабирование пода (VPA), оба из которых масштабируют доступные ресурсы ваших контейнеров.
- Автомасштабирование на уровне кластера: Cluster Autoscaler (CA) управляет этой плоскостью масштабируемости, увеличивая или уменьшая количество узлов внутри вашего кластера по мере необходимости.
Kubernetes Autoscaling Framework в деталях:
Горизонтальное автомасштабирование Pod (HPA)
HPA масштабирует для вас количество реплик Pod в вашем кластере. Перемещение инициируется ЦП или памятью для увеличения или уменьшения масштаба по мере необходимости. Однако можно настроить HPA для масштабирования модулей в соответствии с различными внешними и пользовательскими метриками (metrics.k8s.io, external.metrics.k8s.io и custom.metrics.k8s.io).
Вертикальное автомасштабирование Pod (VPA)
Построенный преимущественно для сервисов с отслеживанием состояния, VPA добавляет ЦП или память к подам по мере необходимости, хотя он также работает как для подов с отслеживанием состояния, так и без него. Чтобы внести эти изменения, VPA перезапускает поды для обновления новых ресурсов ЦП и памяти, которые можно настроить для активации в ответ на события OOM (недостаточно памяти). После перезапуска модулей VPA всегда обеспечивает наличие минимального количества в соответствии с бюджетом распределения модулей (PDB), который вы можете установить вместе с максимальной и минимальной скоростью выделения ресурсов.
Кластер автомасштабирования (CA)
Второй уровень автоматического масштабирования включает CA, который автоматически регулирует размер кластера, когда:
- Любые поды не запускаются и переходят в состояние ожидания из-за недостаточной емкости в кластере (в этом случае CA будет масштабироваться).
- Узлы в кластере были недостаточно загружены в течение определенного периода времени, и есть шанс переместить свои модули на расширяющиеся узлы (в этом случае CA уменьшится).
CA выполняет стандартные проверки, чтобы определить, находятся ли какие-либо модули в состоянии ожидания в ожидании дополнительных ресурсов или недостаточно загружены ли узлы кластера. Затем функция соответствующим образом регулирует количество узлов кластера, если требуется больше ресурсов. CA взаимодействует с облачным провайдером, чтобы запросить дополнительные узлы или закрыть простаивающие, и гарантирует, что масштабируемый кластер остается в рамках ограничений, установленных пользователем. Он работает с AWS, Azure и GCP.
5 шагов к использованию HPA и CA с Amazon EKS
В этой статье представлено пошаговое руководство по установке и автоматическому масштабированию через HPA и CA с кластером Amazon Elastic Container Service for Kubernetes (Amazon EKS). В соответствии с рекомендациями приведены два примера тестовых вариантов использования, чтобы показать функции на месте:
Предпосылки кластера:
- Amazon VPC и выделенная группа безопасности, соответствующая необходимой настройке для кластера Amazon EKS.
- В качестве альтернативы, чтобы избежать пошагового создания VPC вручную, AWS предоставляет стек CloudFormation, который создает VPC для EKS .
- Роль сервиса Amazon EKS для применения к вашему кластеру.
1. Создайте кластер AWS EKS (плоскость управления и рабочие процессы) в соответствии с официальными инструкциями здесь . После запуска группы рабочих узлов Auto Scaling они могут зарегистрироваться в вашем кластере Amazon EKS, и вы сможете начать развертывание на них приложений Kube.
2. Разверните сервер метрик , чтобы HPA могла масштабировать модули в развертывании на основе данных ЦП/памяти, предоставляемых API (как описано выше). API-интерфейс metrics.k8s.io обычно предоставляется сервером метрик (который собирает метрики ЦП и памяти из API сводки, предоставляемые Kubelet на каждом узле).
3. Добавьте следующую политику в роль, созданную EKS для рабочих процессов и узлов K8S (это необходимо для того, чтобы центр сертификации K8S работал вместе с группой AWS Autoscaling Group (AWS AG)).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeTags",
"autoscaling:SetDesiredCapacity",
"autoscaling:TerminateInstanceInAutoScalingGroup"
],
"Resource": "*"
}
]
}
4. Разверните функцию K8S CA.
- В зависимости от используемого дистрибутива Linux может потребоваться обновить файл развертывания и путь к сертификату. Например, при использовании AMI Linux 2; заменить
/etc/ssl/certs/ca-certificates.crtна/etc/ssl/certs/ca-bundle.crtв определении развертывания.
5. Обновите определение развертывания для ЦС, чтобы найти определенные теги в AWS AG ( k8s.io/cluster-autoscaler/<CLUSTER NAME>должны содержать настоящее имя кластера). Также обновите переменную окружения AWS_REGION.Добавьте следующие теги в группу доступности AWS, чтобы ЦС K8S мог автоматически идентифицировать группу доступности AWS:
> k8s.io/cluster-autoscaler/enabled
> k8s.io/cluster-autoscaler/
Kubernetes Autoscaling: тестовый пример №1
Протестируйте K8S HPA в сочетании с функцией K8S CA:
Предпосылки:
- Кластер AWS EKS развернут и работает
- Сервер метрик установлен для подачи API метрик.
- Функция K8S CA установлена
- Разверните образец приложения и создайте ресурс HPA для развертывания приложения .
- Увеличьте нагрузку , запустив службу App K8S из нескольких мест.
- Теперь HPA должен начать масштабировать количество модулей в развертывании по мере увеличения нагрузки. Это масштабирование происходит в соответствии с тем, что указано в ресурсах HPA. В какой-то момент новые модули переходят в «состояние ожидания» в ожидании дополнительных ресурсов.
$ kubectl get nodes -w NAME STATUS ROLES AGE VERSION ip-192-168-189-29.ec2.internal Ready 1h v1.10.3 ip-192-168-200-20.ec2.internal Ready 1h v1.10.3
$ kubectl get Pods -o wide -w NAME READY STATUS RESTARTS AGE IP NODE ip-192-168-200-20.ec2.internal php-apache-8699449574-4mg7w 0/1 Pending 0 17m php-apache-8699449574-64zkm 1/1 Running 0 1h 192.168.210.90 ip-192-168-200-20 php-apache-8699449574-8nqwk 0/1 Pending 0 17m php-apache-8699449574-cl8lj 1/1 Running 0 27m 192.168.172.71 ip-192-168-189-29 php-apache-8699449574-cpzdn 1/1 Running 0 17m 192.168.219.71 ip-192-168-200-20 php-apache-8699449574-dn9tb 0/1 Pending 0 17m ...
4. CA обнаруживает ожидающие Pod из-за недостаточной емкости и корректирует размер группы автоматического масштабирования AWS. Добавляется один дополнительный узел:
$ kubectl get nodes -w NAME STATUS ROLES AGE VERSION ip-192-168-189-29.ec2.internal Ready 2h v1.10.3 ip-192-168-200-20.ec2.internal Ready 2h v1.10.3 ip-192-168-92-187.ec2.internal Ready 34s v1.10.3
5. HPA теперь может планировать создание ожидающих модулей. Они начинают работать в новом узле кластера. Средняя загрузка ЦП теперь ниже указанной цели, поэтому нет необходимости планировать дополнительные поды.
$ kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 40%/50% 2 25 20 1h
$ kubectl get Pods -o wide -w NAME READY STATUS RESTARTS AGE IP NODE php-apache-8699449574-4mg7w 1/1 Running 0 25m 192.168.74.4 ip-192-168-92-187 php-apache-8699449574-64zkm 1/1 Running 0 1h 192.168.210.90 ip-192-168-200-20 php-apache-8699449574-8nqwk 1/1 Running 0 25m 192.168.127.85 ip-192-168-92-187 php-apache-8699449574-cl8lj 1/1 Running 0 35m 192.168.172.71 ip-192-168-189-29 ...
6. Теперь остановите загрузку, начатую в пункте 2), замкнув некоторые клеммы (но не все). Поскольку некоторые из них все еще обращаются к конечной точке службы приложений, можно проверить, не произошел ли сбой при масштабировании кластера.
7. Средняя загрузка ЦП снижается, поэтому HPA начинает убивать некоторые поды, обновляя количество реплик в развертывании.
$ kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache 47%/50% 2 20 7 1h
$ kubectl get Pods -o wide -w NAME READY STATUS RESTARTS AGE IP NODE ... php-apache-8699449574-v5kwf 1/1 Running 0 36m 192.168.250.0 ip-192-168-200-20 php-apache-8699449574-vl4zj 1/1 Running 0 36m 192.168.242.153 ip-192-168-200-20 php-apache-8699449574-8nqwk 1/1 Terminating 0 26m 192.168.127.85 ip-192-168-92-187 php-apache-8699449574-dn9tb 1/1 Terminating 0 26m 192.168.124.108 ip-192-168-92-187 php-apache-8699449574-k5ngv 1/1 Terminating 0 26m 192.168.108.58 ip-192-168-92-187 ...
8. CA обнаруживает, что узел недогружен, и работающие поды могут быть размещены на других узлах. AWS AG обновляется соответствующим образом:
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-189-29.ec2.internal Ready 2h v1.10.3 ip-192-168-200-20.ec2.internal Ready 2h v1.10.3 ip-192-168-92-187.ec2.internal NotReady 23m v1.10.3
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-189-29.ec2.internal Ready 2h v1.10.3 ip-192-168-200-20.ec2.internal Ready 2h v1.10.3
9. Во время масштабирования не должно быть видимого тайм-аута подключения ни для одного из терминалов, которые попадали в конечную точку службы приложений (в точке 6).
Kubernetes Autoscaling: тестовый пример № 2
Проверьте, автоматически ли ЦС регулирует размер кластера, если ресурсов недостаточно для планирования пода, который требует больше ЦП, чем доступно.
Предпосылки:
– Кластер AWS EKS развернут и работает
– Установлена функция ЦС K8S1. Создайте два развертывания, которые запрашивают менее 1 виртуального ЦП.
$ kubectl run nginx --image=nginx:latest --requests=cpu=200m
$ kubectl run nginx2 --image=nginx:latest --requests=cpu=200m
2. Создайте новое развертывание, которое требует больше, чем доступный ЦП.
$ kubectl run nginx3 --image=nginx:latest --requests=cpu=1
3. Новый под останется в состоянии ожидания, потому что нет доступных ресурсов:
$ kubectl get Pods -w NAME READY STATUS RESTARTS AGE nginx-5fcb54784c-lcfht 1/1 Running 0 13m nginx2-66667bf959-2fmlr 1/1 Running 0 3m nginx3-564b575974-xcm5t 0/1 Pending 0 41s
При описании пода можно увидеть событие, указывающее на нехватку ЦП:
$ kubectl describe Pod nginx3-564b575974-xcm5t ….. ….. Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 32s (x7 over 1m) default-scheduler 0/1 nodes are available : 1Insufficient cpu
4. Теперь центр сертификации автоматически настраивает размер кластера (группы доступности AWS). Добавляется один дополнительный узел:
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-142-179.ec2.internal Ready 1m v1.10.3 << ip-192-168-82-136.ec2.internal Ready 1h v1.10.3
5. В кластере теперь достаточно ресурсов для запуска пода:
$ kubectl get Pods NAME READY STATUS RESTARTS AGE nginx-5fcb54784c-lcfht 1/1 Running 0 48m nginx2-66667bf959-2fmlr 1/1 Running 0 37m nginx3-564b575974-xcm5t 1/1 Running 0 35m
6. Два развертывания удалены. Через некоторое время ЦС обнаруживает узел в кластере, который недостаточно загружен, и работающие поды могут быть размещены на другом существующем узле. AWS AG также обновляется, уменьшая требуемую емкость на 1.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-82-136.ec2.internal Ready 1h v1.10.3
$ kubectl get Pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-5fcb54784c-lcfht 1/1 Running 0 1h 192.168.98.139 ip-192-168-82-136
Нужна помощь в настройке и поддержке Kubernetes, обращайтесь [email protected]