Масштабирование и балансировка нагрузки приложений

KubernetesBeginner
Практиковаться сейчас

Введение

В этом лабораторном занятии вы запустите локальный кластер 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

Эти команды подтверждают, что:

  1. Minikube успешно запущен.
  2. Локальный кластер Kubernetes создан.
  3. Кластер готов к использованию.
  4. У вас есть однодоменный кластер с возможностями управляющего узла (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

Основные моменты этого развертывания:

  1. Мы создали Deployment с одной репликой.
  2. Развертывание использует последний образ NGINX.
  3. Контейнер открывает порт 80.
  4. Развертывание имеет метку 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

Основные моменты о масштабировании:

  1. Изменяйте поле replicas в YAML-файле или используйте команду kubectl scale.
  2. Используйте команду kubectl apply для обновления развертывания при внесении изменений в YAML-файл.
  3. Kubernetes обеспечивает запуск нужного количества реплик.
  4. Вы можете масштабировать как вверх (увеличивать количество реплик), так и вниз (уменьшать количество реплик).

Проверить балансировку нагрузки, проверяя ответы нескольких подов

На этом шаге вы узнаете, как проверить балансировку нагрузки в 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

Основные моменты о балансировке нагрузки:

  1. Службы распределяют трафик между всеми соответствующими подами.
  2. Каждый запрос может попасть на другой под.
  3. По умолчанию Kubernetes использует метод кругового распределения (round - robin).
  4. Тип службы ClusterIP обеспечивает внутреннюю балансировку нагрузки.
  5. Тест с использованием 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

Основные моменты о масштабировании:

  1. Используйте kubectl scale для быстрого временного масштабирования.
  2. Обновляйте YAML-файл для постоянной конфигурации.
  3. Kubernetes обеспечивает плавное масштабирование с минимальным нарушением работы.
  4. Вы можете увеличивать или уменьшать масштаб в зависимости от потребностей приложения с помощью команды и конфигурации.

Мониторинг событий развертывания и подов на предмет изменений

На этом шаге вы узнаете, как отслеживать развертывания и поды в 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

Основные моменты о мониторинге:

  1. Команда kubectl describe предоставляет подробную информацию о ресурсах.
  2. Команда kubectl get events показывает события на уровне всего кластера.
  3. Kubernetes автоматически заменяет удаленные поды.
  4. События помогают решать проблемы с развертыванием.
  5. Используйте 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"

Не закрывайте терминал с генератором нагрузки. ОТКРОЙТЕ ДРУГОЙ ТЕРМИНАЛ, чтобы наблюдать за процессом масштабирования.

В новом терминале вы можете использовать несколько команд для наблюдения за автоматическим масштабированием в реальном времени:

  1. Следите за статусом HPA (обновляется каждые несколько секунд):
kubectl get hpa -w
  1. Наблюдайте за созданием подов при масштабировании HPA:
kubectl get pods -w
  1. Отслеживайте события, связанные с процессом масштабирования:
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:

  1. Автоматически масштабирует поды на основе использования ресурсов, что повышает устойчивость приложения.
  2. Может масштабироваться на основе использования ЦП, памяти или пользовательских метрик.
  3. Определяет минимальное и максимальное количество реплик, обеспечивая сбалансированное и эффективное масштабирование.
  4. HPA является важной частью для поддержания производительности и доступности приложения при различной нагрузке.
  5. Использование флага -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.