Введение
В этом лабораторном занятии вы запустите локальный кластер Kubernetes с использованием Minikube, развернете пример приложения NGINX, а затем масштабируете его, чтобы удовлетворить различным требованиям. Вы будете наблюдать балансировку нагрузки между несколькими подами, отслеживать события в кластере и получить краткое введение в Horizontal Pod Autoscaler (HPA) для автоматизации масштабирования в будущем. Цель этого лабораторного занятия - предоставить комплексный практический опыт по пониманию масштабирования и балансировки нагрузки в Kubernetes.
Запустить кластер Kubernetes
На этом шаге вы узнаете, как запустить и проверить локальный кластер Kubernetes с использованием Minikube. Это важный первый шаг для развертывания и управления контейнеризованными приложениями в среде Kubernetes.
Сначала запустите кластер Minikube:
minikube start
Пример вывода:
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Automatically selected the docker driver
📌 Using Docker driver with root permissions
🔥 Creating kubernetes in kubernetes cluster
🔄 Restarting existing kubernetes cluster
🐳 Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀 Launching Kubernetes...
🌟 Enabling addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace
Проверьте статус кластера с помощью нескольких команд:
minikube status
kubectl get nodes
Пример вывода для команды minikube status:
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
Пример вывода для команды kubectl get nodes:
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1
Эти команды подтверждают, что:
- Minikube успешно запущен.
- Локальный кластер Kubernetes создан.
- Кластер готов к использованию.
- У вас есть однодоменный кластер с возможностями управляющего узла (control plane).
Развернуть примерное приложение
На этом шаге вы узнаете, как развернуть простое веб-приложение с использованием Kubernetes Deployment с одним репликой. Мы создадим YAML-манifest для веб-сервера NGINX и применим его к кластеру Minikube. Понимание процесса развертывания приложения является фундаментальным для использования Kubernetes.
Сначала создайте каталог для своих Kubernetes-манестов:
mkdir -p ~/project/k8s-manifests
cd ~/project/k8s-manifests
Создайте новый YAML-файл для развертывания:
nano nginx-deployment.yaml
Добавьте следующую конфигурацию развертывания:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Сохраните файл (Ctrl+X, затем Y, затем Enter).
Объяснение YAML-конфигурации:
apiVersion: apps/v1: Указывает версию API для объектов Deployment.kind: Deployment: Указывает, что это объект Deployment, используемый для управления реплицируемыми приложениями.metadata: Содержит метаданные о Deployment.name: nginx-deployment: Имя развертывания.labels: app: nginx: Метка, используемая для идентификации этого развертывания.
spec: Содержит спецификацию развертывания.replicas: 1: Желаемое количество экземпляров подов (реплик). В этом начальном развертывании у нас только одна реплика.selector: Определяет, как развертывание будет выбирать поды для управления.matchLabels: app: nginx: Поды с меткойapp: nginxбудут управляемы этим развертыванием.
template: Шаблон пода. Он определяет конфигурацию для подов, создаваемых развертыванием.metadata.labels: app: nginx: Метка, применяемая к подам, управляемым этим развертыванием.spec.containers: Определяет контейнеры в поде.name: nginx: Имя контейнера.image: nginx:latest: Docker-образ для контейнера (используется последний образ NGINX).ports: containerPort: 80: Открывает порт 80 в контейнере.
Примените развертывание к кластеру Kubernetes:
kubectl apply -f nginx-deployment.yaml
Пример вывода:
deployment.apps/nginx-deployment created
Проверьте статус развертывания:
kubectl get deployments
kubectl get pods
Пример вывода для команды kubectl get deployments:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 1/1 1 1 30s
Пример вывода для команды kubectl get pods:
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 30s
Основные моменты этого развертывания:
- Мы создали Deployment с одной репликой.
- Развертывание использует последний образ NGINX.
- Контейнер открывает порт 80.
- Развертывание имеет метку
app: nginxдля идентификации.
Просмотрите детали развертывания:
kubectl describe deployment nginx-deployment
Пример вывода покажет конфигурацию развертывания, события и текущее состояние.
Масштабировать развертывания для обработки повышенной нагрузки
На этом шаге вы узнаете, как масштабировать ваше приложение для обработки большего количества трафика. В реальном мире, по мере роста популярности вашего приложения одна реплика может быть недостаточной для обработки нагрузки. Чтобы решить эту проблему, Kubernetes позволяет легко масштабировать ваше приложение, увеличивая количество экземпляров подов (реплик).
Прежде чем приступить к масштабированию, давайте кратко обсудим, почему необходимы несколько реплик. Одна реплика приложения может обрабатывать только определенное количество одновременных запросов. Если трафик превышает эту емкость, приложение может стать медленным или неотзывчивым. При наличии нескольких реплик нагрузка может быть распределена между разными экземплярами подов, обеспечивая, чтобы приложение оставалось отзывчивым и доступным. Этот концепт является важным для создания масштабируемых приложений.
Теперь вы узнаете, как масштабировать развертывание Kubernetes, изменив поле replicas в YAML-манест и с помощью команды kubectl scale.
Откройте ранее созданный манифест развертывания:
nano ~/project/k8s-manifests/nginx-deployment.yaml
Измените поле replicas с 1 на 3:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3 ## Changed from 1 to 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Сохраните файл (Ctrl+X, затем Y, затем Enter).
Примените обновленное развертывание:
kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml
Пример вывода:
deployment.apps/nginx-deployment configured
Проверьте масштабированное развертывание:
kubectl get deployments
kubectl get pods
Пример вывода для команды kubectl get deployments:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 5m
Пример вывода для команды kubectl get pods:
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 5m
nginx-deployment-xxx-zzz 1/1 Running 0 30s
nginx-deployment-xxx-www 1/1 Running 0 30s
Альтернативный метод масштабирования с использованием команды kubectl scale:
kubectl scale deployment nginx-deployment --replicas=4
Пример вывода:
deployment.apps/nginx-deployment scaled
Проверьте новое количество реплик:
kubectl get deployments
kubectl get pods
Основные моменты о масштабировании:
- Изменяйте поле
replicasв YAML-файле или используйте командуkubectl scale. - Используйте команду
kubectl applyдля обновления развертывания при внесении изменений в YAML-файл. - Kubernetes обеспечивает запуск нужного количества реплик.
- Вы можете масштабировать как вверх (увеличивать количество реплик), так и вниз (уменьшать количество реплик).
Проверить балансировку нагрузки, проверяя ответы нескольких подов
На этом шаге вы узнаете, как проверить балансировку нагрузки в Kubernetes, создав службу (Service) и проверив ответы от нескольких подов. Балансировка нагрузки является важной для распределения трафика между несколькими репликами, чтобы ни один под не был перегружен. Kubernetes Services автоматически обрабатывают этот процесс.
Создайте службу для публикации развертывания:
nano ~/project/k8s-manifests/nginx-service.yaml
Добавьте следующую конфигурацию службы:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
type: ClusterIP
ports:
- port: 80
targetPort: 80
Сохраните файл (Ctrl+X, затем Y, затем Enter).
Объяснение YAML-конфигурации:
apiVersion: v1: Указывает версию API для служб (Services).kind: Service: Указывает, что это объект Service.metadata: Содержит метаданные о службе.name: nginx-service: Имя службы.
spec: Содержит спецификацию службы.selector: Определяет, к каким подам эта служба будет направлять трафик.app: nginx: Выбирает поды с меткойapp: nginx, которые совпадают с подами, созданными на предыдущем шаге.
type: ClusterIP: Создает внутреннюю службу с IP-адресом кластера, используемую для внутреннего обмена данными. Этот тип службы доступен только внутри кластера Kubernetes.ports: Определяет, как служба будет маршрутизировать трафик.port: 80: Порт, который служба открывает.targetPort: 80: Порт, на котором приложение внутри контейнера ожидает подключений.
Примените службу:
kubectl apply -f ~/project/k8s-manifests/nginx-service.yaml
Пример вывода:
service/nginx-service created
Проверьте службу:
kubectl get services
Пример вывода:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 30m
nginx-service ClusterIP 10.96.xxx.xxx <none> 80/TCP 30s
Теперь, чтобы действительно проверить балансировку нагрузки, вы создадите временный под и отправите несколько запросов в службу. Это позволит вам увидеть, что запросы распределяются между разными подами NGINX.
Создайте временный под для тестирования балансировки нагрузки:
kubectl run curl-test --image=curlimages/curl --rm -it -- sh
Эта команда выполняет следующее:
kubectl run curl-test: Создает новый под с именемcurl-test.--image=curlimages/curl: Использует Docker-образ с установленнымcurl.--rm: Автоматически удаляет под после завершения работы.-it: Выделяет псевдо-TTY и оставляет stdin открытым.-- sh: Запускает сеанс оболочки в поде.
Внутри временного пода отправьте несколько запросов:
for i in $(seq 1 10); do curl -s nginx-service | grep -q "Welcome to nginx!" && echo "Welcome to nginx - Request $i"; done
Этот цикл отправит 10 запросов в nginx-service. Каждый запрос должен быть направлен на один из доступных подов NGINX. В выводе будет напечатано Welcome to nginx - Request $i для каждого успешного запроса.
Пример вывода:
Welcome to nginx - Request 1
Welcome to nginx - Request 2
Welcome to nginx - Request 3
...
Выйдите из временного пода:
exit
Основные моменты о балансировке нагрузки:
- Службы распределяют трафик между всеми соответствующими подами.
- Каждый запрос может попасть на другой под.
- По умолчанию Kubernetes использует метод кругового распределения (round - robin).
- Тип службы
ClusterIPобеспечивает внутреннюю балансировку нагрузки. - Тест с использованием
curlпоказывает, что нагрузка распределяется между несколькими экземплярами NGINX.
Динамически регулировать масштаб развертывания в соответствии с потребностями
На этом шаге вы научитесь динамически регулировать масштаб развертывания в Kubernetes с помощью команды kubectl scale в соответствии с изменяющимися потребностями приложения. Этот шаг подчеркивает практическую сторону изменения количества запущенных реплик без непосредственного изменения YAML-файла, что может быть полезно для быстрой реакции на пики трафика.
Сначала проверьте текущий статус развертывания:
kubectl get deployments
Пример вывода:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 4/4 4 4 45m
Масштабируйте развертывание с помощью команды kubectl:
kubectl scale deployment nginx-deployment --replicas=5
Пример вывода:
deployment.apps/nginx-deployment scaled
Проверьте новое количество реплик:
kubectl get deployments
kubectl get pods
Пример вывода для развертываний:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 5/5 5 5 46m
Пример вывода для подов:
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 1m
nginx-deployment-xxx-zzz 1/1 Running 0 1m
nginx-deployment-xxx-www 1/1 Running 0 1m
nginx-deployment-xxx-aaa 1/1 Running 0 1m
nginx-deployment-xxx-bbb 1/1 Running 0 1m
Теперь обновите YAML-файл развертывания для постоянного масштабирования:
nano ~/project/k8s-manifests/nginx-deployment.yaml
Измените поле replicas:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## Updated from previous value
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Примените обновленную конфигурацию:
kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml
Пример вывода:
deployment.apps/nginx-deployment configured
Симулируйте уменьшение масштаба в связи с снижением потребностей:
kubectl scale deployment nginx-deployment --replicas=2
Пример вывода:
deployment.apps/nginx-deployment scaled
Проверьте уменьшенное количество реплик:
kubectl get deployments
kubectl get pods
Основные моменты о масштабировании:
- Используйте
kubectl scaleдля быстрого временного масштабирования. - Обновляйте YAML-файл для постоянной конфигурации.
- Kubernetes обеспечивает плавное масштабирование с минимальным нарушением работы.
- Вы можете увеличивать или уменьшать масштаб в зависимости от потребностей приложения с помощью команды и конфигурации.
Мониторинг событий развертывания и подов на предмет изменений
На этом шаге вы узнаете, как отслеживать развертывания и поды в Kubernetes с помощью различных команд kubectl, чтобы отслеживать изменения, решать проблемы и понимать жизненный цикл ваших приложений. Возможность наблюдения за системой (observability) является важной для обеспечения работоспособности и производительности ваших приложений.
Опишите текущее развертывание, чтобы получить подробную информацию:
kubectl describe deployment nginx-deployment
Пример вывода:
Name: nginx-deployment
Namespace: default
CreationTimestamp: [timestamp]
Labels: app=nginx
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:latest
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-xxx (2/2 replicas created)
Events: <some deployment events>
Получите подробную информацию о каждом поде:
kubectl describe pods -l app=nginx
Пример вывода покажет детали для каждого пода, включая:
- Текущий статус
- Информацию о контейнерах
- События
- IP-адреса
- Информацию о узле
Просмотрите события на уровне всего кластера:
kubectl get events
Пример вывода:
LAST SEEN TYPE REASON OBJECT MESSAGE
5m Normal Scheduled pod/nginx-deployment-xxx-yyy Successfully assigned default/nginx-deployment-xxx-yyy to minikube
5m Normal Pulled pod/nginx-deployment-xxx-yyy Container image "nginx:latest" already present on machine
5m Normal Created pod/nginx-deployment-xxx-yyy Created container nginx
5m Normal Started pod/nginx-deployment-xxx-yyy Started container nginx
Отфильтруйте события для определенных ресурсов:
kubectl get events --field-selector involvedObject.kind=Deployment
Пример вывода покажет только события, связанные с развертываниями.
Симулируйте событие, удалив под:
## Get a pod name
POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')
## Delete the pod
kubectl delete pod $POD_NAME
Следите за событиями и восстановлением подов:
kubectl get events
kubectl get pods
Основные моменты о мониторинге:
- Команда
kubectl describeпредоставляет подробную информацию о ресурсах. - Команда
kubectl get eventsпоказывает события на уровне всего кластера. - Kubernetes автоматически заменяет удаленные поды.
- События помогают решать проблемы с развертыванием.
- Используйте
describeдля получения подробной информации об объектах иeventsдля отслеживания действий.
Краткое введение в Horizontal Pod Autoscaler (HPA) для дальнейшего изучения
На этом этапе вы познакомитесь с Horizontal Pod Autoscaler (HPA) — мощной функцией Kubernetes, которая автоматически масштабирует приложения на основе использования ресурсов. HPA позволяет определять правила масштабирования на основе таких показателей, как использование ЦП, потребление памяти или даже на основе пользовательских метрик.
Понимание HPA:
HPA автоматически регулирует количество запущенных реплик подов в Deployment, ReplicaSet или StatefulSet на основе наблюдаемого использования ЦП или памяти, а также на основе пользовательских метрик, предоставляемых вашими приложениями. Это обеспечивает автоматическое масштабирование вашего приложения для обработки меняющейся нагрузки трафика, улучшая производительность и доступность.
Включите надстройку metrics server в Minikube:
minikube addons enable metrics-server
Пример вывода:
* The 'metrics-server' addon is enabled
Metrics server предоставляет Kubernetes данными о использовании ваших ресурсов, и он необходим для работы HPA.
Создайте развертывание с запросами на ресурсы:
nano ~/project/k8s-manifests/hpa-example.yaml
Добавьте следующее содержимое:
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-apache
spec:
selector:
matchLabels:
run: php-apache
replicas: 1
template:
metadata:
labels:
run: php-apache
spec:
containers:
- name: php-apache
image: k8s.gcr.io/hpa-example
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
requests:
cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
name: php-apache
labels:
run: php-apache
spec:
ports:
- port: 80
selector:
run: php-apache
Примените развертывание:
kubectl apply -f ~/project/k8s-manifests/hpa-example.yaml
Объяснение конфигурации YAML:
- Этот YAML-файл определяет Deployment для PHP-приложения и соответствующий Service.
- Конфигурация Deployment очень похожа на конфигурацию для NGINX, за исключением:
name: php-apache: Имя развертывания и контейнера пода.image: k8s.gcr.io/hpa-example: Docker-образ для контейнера.resources: Этот раздел указывает требования к ресурсам для контейнера.limits.cpu: 500m: Максимальное количество ЦП, которое контейнер может использовать.requests.cpu: 200m: Гарантированное количество ЦП, назначенное контейнеру.
- Сервис представляет собой стандартную конфигурацию сервиса, которая делает развертывание доступным внутри кластера.
Создайте конфигурацию HPA:
nano ~/project/k8s-manifests/php-apache-hpa.yaml
Добавьте следующий манифест HPA:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
Примените конфигурацию HPA:
kubectl apply -f ~/project/k8s-manifests/php-apache-hpa.yaml
Объяснение конфигурации YAML:
apiVersion: autoscaling/v2: Указывает версию API для HorizontalPodAutoscaler.kind: HorizontalPodAutoscaler: Указывает, что это объект HPA.metadata: Содержит метаданные о HPA.name: php-apache: Имя HPA.
spec: Содержит спецификацию HPA.scaleTargetRef: Определяет целевой Deployment, который будет масштабироваться.apiVersion: apps/v1: Версия API целевого ресурса.kind: Deployment: Тип целевого ресурса, который представляет собой Deployment.name: php-apache: Имя целевого Deployment для масштабирования.
minReplicas: 1: Минимальное количество реплик, которые должны оставаться запущенными.maxReplicas: 10: Максимальное количество реплик, до которого можно масштабировать.metrics: Определяет, как определять метрики масштабирования.type: Resource: Масштабирование на основе метрики ресурса.resource.name: cpu: Масштабирование на основе использования ЦП.resource.target.type: Utilization: Масштабирование на основе процента запрошенного ЦП подом.resource.target.averageUtilization: 50: Масштабирование происходит, когда среднее использование ЦП по всем подам превышает 50% запрошенного.
Проверьте конфигурацию HPA:
kubectl get hpa
Пример вывода:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/50% 1 10 1 30s
Симуляция нагрузки и наблюдение за автоматическим масштабированием в реальном времени
Для имитации высокой нагрузки и запуска автоматического масштабирования вы запустите генератор нагрузки в одном терминале и будете наблюдать за процессом масштабирования в отдельном терминале.
Сначала откройте терминал для генератора нагрузки:
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
Не закрывайте терминал с генератором нагрузки. ОТКРОЙТЕ ДРУГОЙ ТЕРМИНАЛ, чтобы наблюдать за процессом масштабирования.
В новом терминале вы можете использовать несколько команд для наблюдения за автоматическим масштабированием в реальном времени:
- Следите за статусом HPA (обновляется каждые несколько секунд):
kubectl get hpa -w
- Наблюдайте за созданием подов при масштабировании HPA:
kubectl get pods -w
- Отслеживайте события, связанные с процессом масштабирования:
kubectl get events --sort-by='.lastTimestamp' -w
Вы можете запустить любую из этих команд, чтобы наблюдать за различными аспектами процесса автоматического масштабирования. Например, наблюдение за подами с флагом -w показывает, как поды создаются в реальном времени при масштабировании системы:
Пример вывода для kubectl get pods -w:
NAME READY STATUS RESTARTS AGE
php-apache-xxxxxxxxx-xxxxx 1/1 Running 0 2m
load-generator 1/1 Running 0 30s
php-apache-xxxxxxxxx-yyyyy 0/1 Pending 0 0s
php-apache-xxxxxxxxx-yyyyy 0/1 ContainerCreating 0 0s
php-apache-xxxxxxxxx-yyyyy 1/1 Running 0 3s
php-apache-xxxxxxxxx-zzzzz 0/1 Pending 0 0s
php-apache-xxxxxxxxx-zzzzz 0/1 ContainerCreating 0 0s
php-apache-xxxxxxxxx-zzzzz 1/1 Running 0 2s
Вы увидите, как HPA реагирует на увеличение нагрузки, увеличивая количество подов. Обновление метрик может занять минуту или более, чтобы отразить изменения:
Пример вывода для kubectl get hpa -w:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/50% 1 10 1 30s
php-apache Deployment/php-apache 68%/50% 1 10 1 90s
php-apache Deployment/php-apache 68%/50% 1 10 2 90s
php-apache Deployment/php-apache 79%/50% 1 10 2 2m
php-apache Deployment/php-apache 79%/50% 1 10 4 2m15s
После того, как вы закончите наблюдение, нажмите Ctrl+C, чтобы остановить команду наблюдения, а затем вернитесь в первый терминал и нажмите Ctrl+C, чтобы остановить генератор нагрузки.
Основные моменты о HPA:
- Автоматически масштабирует поды на основе использования ресурсов, что повышает устойчивость приложения.
- Может масштабироваться на основе использования ЦП, памяти или пользовательских метрик.
- Определяет минимальное и максимальное количество реплик, обеспечивая сбалансированное и эффективное масштабирование.
- HPA является важной частью для поддержания производительности и доступности приложения при различной нагрузке.
- Использование флага
-w(watch) с командами kubectl позволяет наблюдать за изменениями в кластере в реальном времени.
Резюме
В этом практическом занятии вы получили практический опыт в масштабировании и балансировке нагрузки в Kubernetes. Вы начали с создания локального кластера Kubernetes с помощью Minikube и развертывания простого веб-приложения на основе NGINX. Затем вы изучили различные методы масштабирования, включая изменение YAML-файлов развертывания и использование команды kubectl scale для регулировки количества реплик подов. Вы узнали, как проверить балансировку нагрузки с использованием служб (Services) Kubernetes и временного тестового пода.
Кроме того, вы научились отслеживать развертывания и поды с помощью команд kubectl describe и kubectl get events. Наконец, вы получили базовое понимание Horizontal Pod Autoscaler (HPA), в том числе о том, как он может автоматически масштабировать ваше приложение на основе использования ресурсов, на примере образа php-apache. Это практическое занятие дает всестороннее введение в технологии масштабирования, балансировки нагрузки, мониторинга и автоматического масштабирования в Kubernetes и заложает основу для управления более сложными приложениями в Kubernetes.
