Автоматическое масштабирование позволяет оптимально распределить ресурсы для приложения на основе его текущее потребления ресурсов.
Kubernetes предлагает три основных типа автомасштабирования:
- Горизонтальный стручок Autoscaler (HPA): HPA контролирует количество стручков
- Vertical Pod Autoscaler (VPA): VPA контролирует ресурсы в отдельных модулях.
- Cluster Autoscaler (CA): CA контролирует количество узлов в кластере
Горизонтальный стручковый автоскалер (HPA)
В этой статье мы сосредоточимся на HPA. По умолчанию Kubernetes поддерживает автоматическое масштабирование на базе процессоров и модулей памяти. Однако вы можете настроить его для масштабирования на основе пользовательской метрики или нескольких метрик.
--horizontal-pod-auto-scaler-sync-period флаг), и если текущий порог выше указанного порога, HPA пытается увеличить количество стручки. Контроллер HPA предполагает линейную зависимость между метрикой и количеством стручков. Он работает на соотношении между желаемым значением показателя и текущим значением показателя. Формула, используемая для вычисления желаемых реплик, выглядит следующим образом (для получения более подробной информации обратитесь к документации K8s).
В этой статье мы сосредоточимся на горизонтальном автоматическом масштабировании и будем масштабировать в зависимости от загрузки процессора (которая является одним из наиболее часто используемых показателей). Обратите внимание, что более высокая загрузка ЦП указывает на большую задержку. Следовательно, поддержание загрузки ЦП на более низких уровнях позволяет нам также поддерживать задержку (приложения) на более низких уровнях. На следующем рисунке показано изменение использования ЦП микросервиса (привязанного к вводу / выводу).
Вам также может понравиться: Архитектура микросервисов: Введение в автоматическое масштабирование
Развертывание приложения
Теперь давайте развернем микросервис в Kubernetes и изучим поведение производительности с включенным автоматическим масштабированием. Мы развернем микросервис Spring Boot (см. Здесь репозиторий Github) в K8s. Ниже приведен файл YAML Kubernetes для развертывания.
YAML
xxxxxxxxxx
1
# Deploymet / приложение / app.yaml
2
apiVersion apps / v1
4
вид развертывание
5
метаданные
6
название springboot-app
7
этикетки
8
приложение Springboot-приложение
9
спецификация
10
Реплики 1
11
селектор
12
matchLabels
13
приложение Springboot-приложение
14
шаблон
15
метаданные
16
этикетки
17
приложение Springboot-приложение
18
спецификация
19
контейнеры
20
название springboot-app
21
изображение anushiya / app последнее
22
ресурсы
23
пределы
24
процессор "100м"
25
запросы
26
процессор "100м"
27
порты
28
containerPort 9000
Конфигурирование горизонтального стручка Autoscaler
Теперь давайте включим горизонтальное автоматическое масштабирование модуля для созданного выше развертывания. Мы настраиваем HPA для масштабирования в зависимости от загрузки процессора. Файл YAML показан ниже.
YAML
xxxxxxxxxx
1
# Springboot-приложение-hpa.yaml
2
apiVersion автоматическое масштабирование / v2beta2
3
вид HorizontalPodAutoscaler
4
метаданные
5
имя springboot-app-hpa
6
спецификация
7
scaleTargetRef
8
apiVersion apps / v2beta2
9
вид развертывание
10
название springboot-app
11
minReplicas 1
12
maxReplicas 20
13
метрики
14
ресурс
15
имя процессор
16
targetAverageUtilization 50
17
Тип Ресурс
HPA также является ресурсом API в Kubernetes с полями apiVersion, kind, metadata и spec (для получения более подробной информации обратитесь к документации K8s). Условие масштабирования определяется как resource: targetAverageUtilization. Здесь мы указываем значение 50. Это означает, что если загрузка ЦП превышает заданное значение, начинается процесс масштабирования. Значение должно быть в диапазоне от 1 до 100.
Развертывание JMeter
Для проверки производительности приложения мы используем JMeter в качестве клиента нагрузочного тестирования. Для развертывания JMeter мы создали образ Docker. Ниже приведен Dockerfile для JMeter. Используемые файлы можно найти в этом репо .
Оболочка
xxxxxxxxxx
1
ОТ анушия / jmeter-плагины: v1
2
ДОБАВИТЬ bash / home / kubernetes-performance / bash
4
ДОБАВИТЬ банку / домашний / kubernetes-performance / баночка
5
ДОБАВИТЬ jmx / home / kubernetes-performance / jmx
6
ДОБАВИТЬ python / home / kubernetes-performance / python
7
WORKDIR / home / kubernetes-перформанс / bash
9
RUN chmod + x start_performance_test.sh
11
RUN apt-get update && apt-get install python3.5 -y
13
RUN apt-get установить python-pip -y
14
RUN pip установить расписание numy запросов
Поскольку мы хотим хранить результаты тестов производительности постоянно, мы используем том хоста для хранения результатов выполненных тестов. Создать том хоста ssh в любом из узлов и создать каталог для монтирования.
Оболочка
xxxxxxxxxx
1
# Получить список узлов
2
kubectl получить узел
3
# Выберите узел и SSH в него
5
sudo gcloud beta compute --project "[название проекта]" ssh --zone "[зона]" "[имя узла]"
6
#пример
8
sudo gcloud beta compute --project "тестирование производительности" ssh --zone "us-central1-a" "gke-performance-testing-default-pool-b6e4d476-78zn"
9
# Создать каталог для монтирования
11
sudo mkdir / mnt / data / results
Создать постоянный том.
YAML
xxxxxxxxxx
1
# Ри-volume.yaml
2
apiVersion v1
3
вид PersistentVolume
4
метаданные
5
Название PV-том
6
этикетки
7
тип местный
8
спецификация
9
storageClassName ручной
10
емкость
11
хранение ги
12
accessModes
13
ReadWriteOnce
14
hostPath
15
путь "/ mnt / data / results"
Создайте постоянную заявку на объем.
YAML
xxxxxxxxxx
1
# Развертывание / объем / PV-claim.yaml
2
apiVersion v1
3
вид PersistentVolumeClaim
4
метаданные
5
имя пв-претензия
6
спецификация
7
storageClassName ручной
8
accessModes
9
ReadWriteOnce
10
ресурсы
11
запросы
12
хранение 6Gi
Примените файлы YAML для создания постоянного тома и постоянного тома
Оболочка
xxxxxxxxxx
1
# создать постоянный объем
2
kubectl применить -f развертывание / том / pv-volume.yaml
3
# создать постоянную заявку на объем
5
kubectl применить -f развертывание / том / PV-претензии.yaml
Для получения более подробной информации о PersistentVolume и PersistenetVolumeClaim смотрите это . Теперь, когда мы создали тома для хранения результатов теста, мы перейдем к созданию задания для выполнения тестов. Результаты теста можно найти в каталоге, указанном выше.
YAML
1
# Парфюм-test.yaml
2
apiVersion партия / v1
3
вид работа
4
метаданные
5
название перф-тест
6
спецификация
7
шаблон
8
спецификация
9
контейнеры
10
название perf-test
11
изображение анушия / перф-тест v1
12
imagePullPolicy всегда
13
команда "bash" "start_performance_test.sh"
14
volumeMounts
15
mountPath "/ home / kubernetes-performance / results"
16
Название PV-хранилище
17
restartPolicy никогда
18
объемы
19
имя PV-хранилище
20
persistentVolumeClaim
21
RequestName PV -претензия
22
backoffLimit 4
Анализ поведения загрузки процессора, задержки и подсчета стоек
Давайте теперь посмотрим, как процессор, количество модулей и время ожидания меняются со временем. На следующих рисунках показаны различия в загрузке ЦП, количестве модулей и времени ожидания, когда мы тестируем производительность с использованием одного пользователя с параллельным доступом. Мы использовали API мониторинга Stackdriver для получения статистики производительности (см. Эту ссылку для более подробной информации).