Поиск по сайту:

Как настроить автомасштабирование Kubernetes Horizontal Pod с помощью сервера метрик

Введение

Kubernetes стремится обеспечить как отказоустойчивость, так и масштабируемость. Это достигается за счет развертывания нескольких модулей с различным распределением ресурсов, чтобы обеспечить избыточность для ваших приложений. Хотя вы можете увеличивать и уменьшать свои собственные развертывания вручную в зависимости от ваших потребностей, Kubernetes обеспечивает первоклассную поддержку масштабирования по требованию с помощью функции под названием Horizontal Pod Autoscaling. Это замкнутая система, которая автоматически увеличивает или уменьшает ресурсы (модули приложений) в зависимости от ваших текущих потребностей. Вы создаете ресурс HorizontalPodAutoscaler (или HPA) для каждого развертывания приложения, требующего автомасштабирования, и позволяете ему автоматически позаботиться об остальном.

На высоком уровне HPA выполняет следующие действия:

  1. Он отслеживает метрики запросов ресурсов, поступающие от рабочих нагрузок ваших приложений (модулей), отправляя запросы на сервер метрик.
  2. Он сравнивает целевое пороговое значение, заданное вами в определении HPA, со средним значением использования ресурсов, наблюдаемым для рабочих нагрузок вашего приложения (ЦП и памяти).
  3. Если целевой порог достигнут, HPA масштабирует развертывание вашего приложения для удовлетворения более высоких требований. В противном случае, если он ниже порогового значения, развертывание будет уменьшено. Чтобы узнать, какую логику HPA использует для масштабирования развертывания вашего приложения, вы можете просмотреть страницу сведений об алгоритме в официальной документации.

Под капотом HorizontalPodAutoscaler — это CRD (Custom Resource Definition), который управляет циклом управления Kubernetes, реализованным через выделенный контроллер в Control Plane. вашего кластера. Вы создаете манифест HorizontalPodAutoscaler YAML, предназначенный для вашего приложения Deployment, а затем используете kubectl для применения ресурса HPA в своем кластере.

Для работы HPA необходим сервер метрик, доступный в вашем кластере, для сбора необходимых метрик, таких как использование ЦП и памяти. Одним из простых вариантов является Kubernetes Metrics Server. Сервер метрик работает, собирая метрики ресурсов из Kubelets и предоставляя их через Kubernetes API Server для автоматического масштабирования Horizontal Pod. При необходимости доступ к Metrics API можно получить через kubectl top.

В этом уроке вы:

  • Разверните сервер метрик в кластере Kubernetes.
  • Узнайте, как создавать горизонтальные модули автомасштабирования для ваших приложений.
  • Протестируйте каждую настройку HPA, используя два сценария: постоянная и переменная нагрузка приложения.

Предпосылки

Чтобы следовать этому руководству, вам понадобятся:

  • Кластер Kubernetes с созданием кластера вручную. Ваша версия Kubernetes должна быть между 1.20 и 1.25.
  • Инструмент командной строки kubectl, установленный в вашей локальной среде и настроенный для подключения к вашему кластеру. Вы можете прочитать больше об установке kubectl Как подключиться к кластеру DigitalOcean Kubernetes, чтобы узнать, как подключиться к вашему кластеру с помощью kubectl.
  • Инструмент контроля версий, устанавливающий Git на Ubuntu 22.04
  • Kubernetes, как установить программное обеспечение с помощью Helm для локальной установки Helm.

Шаг 1 — Установите сервер метрик через Helm

Вы начнете с добавления репозитория metrics-server в список пакетов helm. Вы можете использовать helm repo add:

  1. helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server

Затем используйте helm repo update, чтобы обновить доступные пакеты:

  1. helm repo update metrics-server



Output
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "metrics-server" chart repository
Update Complete. ⎈Happy Helming!⎈

Теперь, когда вы добавили репозиторий в helm, вы сможете добавить metrics-server в свои развертывания Kubernetes. Здесь вы можете написать свою собственную конфигурацию развертывания, но в этом руководстве будет использоваться стартовый комплект DigitalOcean Kubernetes, который включает конфигурацию для metrics-server.

Для этого клонируйте Git-репозиторий Kubernetes Starter Kit:

  1. git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git

Конфигурация metrics-server находится в Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/metrics-server-values-v3.8.2.yaml. Вы можете просмотреть или отредактировать его с помощью nano или вашего любимого текстового редактора:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/metrics-server-values-v3.8.2.yaml

Он содержит несколько параметров акций. Обратите внимание, что replicas — это фиксированное значение, 2.

## Starter Kit metrics-server configuration
## Ref: https://github.com/kubernetes-sigs/metrics-server/blob/metrics-server-helm-chart-3.8.2/charts/metrics-server
##

# Number of metrics-server replicas to run
replicas: 2

apiService:
  # Specifies if the v1beta1.metrics.k8s.io API service should be created.
  #
  # You typically want this enabled! If you disable API service creation you have to
  # manage it outside of this chart for e.g horizontal pod autoscaling to
  # work with this release.
  create: true

hostNetwork:
  # Specifies if metrics-server should be started in hostNetwork mode.
  #
  # You would require this enabled if you use alternate overlay networking for pods and
  # API server unable to communicate with metrics-server. As an example, this is required
  # if you use Weave network on EKS
  enabled: false

Обратитесь к странице диаграммы сервера метрик для объяснения доступных параметров для metrics-server.

Примечание. Вы должны быть достаточно осторожны при сопоставлении развертываний Kubernetes с вашей текущей версией Kubernetes, и сами диаграммы helm также имеют версию, чтобы обеспечить это. Текущая восходящая диаграмма helm для metrics-server представляет собой матрицу совместимости Metrics Server, вы можете видеть, что версия 0.6.x поддерживает Kubernetes 1.19. +.

После того, как вы просмотрели файл и внесли какие-либо изменения, вы можете приступить к развертыванию metrics-server, предоставив этот файл вместе с командой helm install:

  1. HELM_CHART_VERSION="3.8.2"

  2. 

  3. helm install metrics-server metrics-server/metrics-server --version "$HELM_CHART_VERSION" \

  4.   --namespace metrics-server \

  5.   --create-namespace \

  6.   -f "Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/metrics-server-values-v${HELM_CHART_VERSION}.yaml"

Это развернет metrics-server в настроенном вами кластере Kubernetes:

Output
NAME: metrics-server
LAST DEPLOYED: Wed May 25 11:54:43 2022
NAMESPACE: metrics-server
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
***********************************************************************
* Metrics Server                                                      *
***********************************************************************
  Chart version: 3.8.2
  App version:   0.6.1
  Image tag:     k8s.gcr.io/metrics-server/metrics-server:v0.6.1
***********************************************************************

После развертывания вы можете использовать helm ls, чтобы убедиться, что metrics-server добавлен в ваше развертывание:

  1. helm ls -n metrics-server



Output
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
metrics-server  metrics-server  1               2022-02-24 14:58:23.785875 +0200 EET    deployed        metrics-server-3.8.2    0.6.1

Затем вы можете проверить состояние всех ресурсов Kubernetes, развернутых в пространстве имен metrics-server:

  1. kubectl get all -n metrics-server

В зависимости от конфигурации, с которой вы выполняли развертывание, оба значения deployment.apps и replicaset.apps должны учитывать 2 доступных экземпляра.

Output
NAME                                  READY   STATUS    RESTARTS   AGE
pod/metrics-server-694d47d564-9sp5h   1/1     Running   0          8m54s
pod/metrics-server-694d47d564-cc4m2   1/1     Running   0          8m54s

NAME                     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/metrics-server   ClusterIP   10.245.92.63   <none>        443/TCP   8m54s

NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/metrics-server   2/2     2            2           8m55s

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/metrics-server-694d47d564   2         2         2       8m55s

Теперь вы развернули metrics-server в своем кластере Kubernetes. На следующем шаге вы просмотрите некоторые параметры пользовательского определения ресурса HorizontalPodAutoscaler.

Шаг 2 — Знакомство с HPA

До сих пор в ваших конфигурациях использовалось фиксированное значение числа экземпляров ReplicaSet для развертывания. На этом шаге вы узнаете, как определить CRD HorizontalPodAutoscaler, чтобы это значение могло динамически увеличиваться или уменьшаться.

Типичный CRD HorizontalPodAutoscaler выглядит следующим образом:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

В этой конфигурации используются следующие параметры:

  • spec.scaleTargetRef: именованная ссылка на масштабируемый ресурс.
  • spec.minReplicas: нижний предел количества реплик, до которого может масштабироваться средство автомасштабирования.
  • spec.maxReplicas: верхний предел.
  • spec.metrics.type: метрика, используемая для расчета желаемого количества реплик. В этом примере используется тип Resource, который указывает HPA масштабировать развертывание на основе среднего использования CPU (или памяти). Для averageUtilization задано пороговое значение 50.

У вас есть два варианта создания HPA для развертывания вашего приложения:

  1. Используйте команду kubectl autoscale в существующем развертывании.
  2. Создайте манифест HPA YAML, а затем используйте kubectl, чтобы применить изменения к вашему кластеру.

Сначала вы попробуете вариант № 1, используя другую конфигурацию из стартового набора DigitalOcean Kubernetes. Он содержит развертывание под названием myapp-test.yaml, которое продемонстрирует HPA в действии, создавая произвольную нагрузку на ЦП.

Вы можете просмотреть этот файл с помощью nano или вашего любимого текстового редактора:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/myapp-test.yaml



apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-test
spec:
  selector:
    matchLabels:
      run: myapp-test
  replicas: 1
  template:
    metadata:
      labels:
        run: myapp-test
    spec:
      containers:
        - name: busybox
          image: busybox
          resources:
            limits:
              cpu: 50m
            requests:
              cpu: 20m
          command: ["sh", "-c"]
          args:
            - while [ 1 ]; do
              echo "Test";
              sleep 0.01;
              done

Обратите внимание на последние несколько строк этого файла. Они содержат некоторый синтаксис оболочки для повторного вывода \Test сто раз в секунду для имитации нагрузки. После того, как вы закончите просмотр файла, вы можете развернуть его в своем кластере с помощью kubectl:

  1. kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/myapp-test.yaml

Затем используйте kubectl autoscale, чтобы создать HorizontalPodAutoscaler, предназначенный для развертывания myapp-test:

  1. kubectl autoscale deployment myapp-test --cpu-percent=50 --min=1 --max=3

Обратите внимание на аргументы, переданные этой команде. Это означает, что ваше развертывание будет масштабироваться между репликами 1 и 3 всякий раз, когда загрузка ЦП достигает 50 процентов.

Вы можете проверить, был ли создан ресурс HPA, запустив kubectl get hpa:

  1. kubectl get hpa

Столбец TARGETS вывода в конечном итоге покажет цифру текущее использование%/целевое использование%.

Output
NAME         REFERENCE                  TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
myapp-test   Deployment/myapp-test      240%/50%   1         3         3          52s

Примечание. В столбце TARGETS какое-то время (около 15 секунд) будет отображаться /50%. Это нормально, потому что HPA должен собирать средние значения с течением времени, и ему не хватит данных до первого 15-секундного интервала. По умолчанию HPA проверяет метрики каждые 15 секунд.

Вы также можете наблюдать за зарегистрированными событиями, которые генерирует HPA, используя kubectl описать:

  1. kubectl describe hpa myapp-test



Output
Name:                                                  myapp-test
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           <none>
CreationTimestamp:                                     Mon, 28 May 2022 10:10:50 -0800
Reference:                                             Deployment/myapp-test
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  240% (48m) / 50%
Min replicas:                                          1
Max replicas:                                          3
Deployment pods:                                       3 current / 3 desired
...
Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  17s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
  Normal  SuccessfulRescale  37s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target

Это метод автомасштабирования kubectl. В рабочем сценарии вместо этого обычно следует использовать выделенный манифест YAML для определения каждого HPA. Таким образом, вы можете отслеживать изменения, фиксируя манифест в репозитории Git, и изменять его по мере необходимости.

Вы пройдете через пример этого на последнем шаге этого руководства. Прежде чем двигаться дальше, удалите развертывание myapp-test и соответствующий ресурс HPA:

  1. kubectl delete hpa myapp-test

  2. kubectl delete deployment myapp-test

Шаг 3. Автоматическое масштабирование приложений с помощью сервера метрик

На этом последнем шаге вы поэкспериментируете с двумя разными способами создания нагрузки на сервер и масштабирования с помощью манифеста YAML:

  1. Развертывание приложения, создающее постоянную нагрузку за счет выполнения некоторых вычислений, интенсивно использующих ЦП.
  2. Сценарий оболочки имитирует эту внешнюю нагрузку, выполняя быстрые последовательные вызовы HTTP для веб-приложения.

Испытание постоянной нагрузкой

В этом сценарии вы создадите пример приложения, реализованного с использованием Python, который выполняет некоторые вычисления с интенсивным использованием ЦП. Подобно сценарию оболочки из последнего шага, этот код Python включен в один из примеров манифеста из стартового набора. Вы можете открыть constant-load-deployment-test.yaml с помощью nano или вашего любимого текстового редактора:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-deployment-test.yaml



---
apiVersion: v1
kind: ConfigMap
metadata:
  name: python-test-code-configmap
data:
  entrypoint.sh: |-
    #!/usr/bin/env python

    import math

    while True:
      x = 0.0001
      for i in range(1000000):
        x = x + math.sqrt(x)
        print(x)
      print("OK!")

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: constant-load-deployment-test
spec:
  selector:
    matchLabels:
      run: python-constant-load-test
  replicas: 1
  template:
    metadata:
      labels:
        run: python-constant-load-test
    spec:
      containers:
        - name: python-runtime
          image: python:alpine3.15
          resources:
            limits:
              cpu: 50m
            requests:
              cpu: 20m
          command:
            - /bin/entrypoint.sh
          volumeMounts:
            - name: python-test-code-volume
              mountPath: /bin/entrypoint.sh
              readOnly: true
              subPath: entrypoint.sh
      volumes:
        - name: python-test-code-volume
          configMap:
            defaultMode: 0700
            name: python-test-code-configmap

Код Python, который многократно генерирует произвольные квадратные корни, выделен выше. Развертывание извлечет образ Docker, содержащий требуемую среду выполнения Python, а затем прикрепит ConfigMap к приложению Pod, в котором размещается образец сценария Python, показанный ранее.

Сначала создайте отдельное пространство имен для этого развертывания (для лучшего наблюдения), а затем разверните его через kubectl:

  1. kubectl create ns hpa-constant-load

  2. 

  3. kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-deployment-test.yaml -n hpa-constant-load



Output
configmap/python-test-code-configmap created
deployment.apps/constant-load-deployment-test created

Примечание. В примере развертывания также настраиваются ограничения на запросы ресурсов для примеров модулей приложений. Это важно, потому что логика HPA зависит от ограничения запросов ресурсов, установленных для ваших модулей. Как правило, рекомендуется установить ограничения на запросы ресурсов для всех ваших подов приложений, чтобы избежать непредсказуемых узких мест.

Убедитесь, что развертывание было успешно создано и запущено:

  1. kubectl get deployments -n hpa-constant-load



Output
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
constant-load-deployment-test   1/1     1            1           8s

Далее вам потребуется развернуть еще один HPA в этом кластере. Пример, соответствующий этому сценарию, есть в constant-load-hpa-test.yaml, который можно открыть с помощью nano или вашего любимого текстового редактора:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-hpa-test.yaml -n hpa-constant-load



apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: constant-load-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: constant-load-deployment-test
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Разверните его через kubectl:

  1. kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/constant-load-hpa-test.yaml -n hpa-constant-load

Это создаст ресурс HPA, предназначенный для примера развертывания Python. Вы можете проверить состояние constant-load-test HPA с помощью kubectl get hpa:

  1. kubectl get hpa constant-load-test -n hpa-constant-load

Обратите внимание на столбец REFERENCE, посвященный constant-load-deployment-test, а также столбец TARGETS, показывающий текущие запросы ресурсов ЦП по сравнению с пороговым значением, как в последнем примере.

Output
NAME                 REFERENCE                                  TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
constant-load-test   Deployment/constant-load-deployment-test   255%/50%   1         3         3          49s

Вы также можете заметить, что значение столбца REPLICAS увеличилось с 1 до 3 для примера развертывания приложения, как указано в спецификации HPA CRD. Это произошло очень быстро, потому что приложение, используемое в этом примере, очень быстро генерирует нагрузку на ЦП. Как и в предыдущем примере, вы также можете проверить зарегистрированные события HPA, используя kubectl описать hpa -n hpa-constant-load.

Тест внешней нагрузки

Более интересным и реалистичным сценарием является наблюдение за местом создания внешней нагрузки. В этом последнем примере вы будете использовать другое пространство имен и набор манифестов, чтобы избежать повторного использования каких-либо данных из предыдущего теста.

В этом примере будет использоваться цитата сервера примера момента. Каждый раз, когда на этот сервер делается HTTP-запрос, в качестве ответа он отправляет другую цитату. Вы создадите нагрузку на свой кластер, отправляя HTTP-запросы каждые 1 мс. Это развертывание включено в quote_deployment.yaml. Просмотрите этот файл с помощью nano или вашего любимого текстового редактора:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote_deployment.yaml



---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: quote
spec:
  replicas: 1
  selector:
    matchLabels:
      app: quote
  template:
    metadata:
      labels:
        app: quote
    spec:
      containers:
        - name: quote
          image: docker.io/datawire/quote:0.4.1
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi

---
apiVersion: v1
kind: Service
metadata:
  name: quote
spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
  selector:
    app: quote

Обратите внимание, что на этот раз реальный сценарий HTTP-запроса не содержится в манифесте — этот манифест только предоставляет приложению выполнение запросов на данный момент. Когда вы закончите просмотр файла, создайте пространство имен и развертывание цитаты с помощью kubectl:

  1. kubectl create ns hpa-external-load

  2. 

  3. kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote_deployment.yaml -n hpa-external-load

Убедитесь, что развертывание и службы приложения quote запущены и работают:

  1. kubectl get all -n hpa-external-load



Output
NAME                             READY   STATUS    RESTARTS   AGE
pod/quote-dffd65947-s56c9        1/1     Running   0          3m5s

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/quote   ClusterIP   10.245.170.194   <none>        80/TCP    3m5s

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/quote       1/1     1            1           3m5s

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/quote-6c8f564ff        1         1         1       3m5s

Далее вы создадите HPA для развертывания quote. Это настраивается в quote-deployment-hpa-test.yaml. Просмотрите файл в nano или в вашем любимом текстовом редакторе:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote-deployment-hpa-test.yaml



apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: external-load-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: quote
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 60
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 20

Обратите внимание, что в этом случае установлено другое пороговое значение для метрики ресурсов ЦП (20%). Существует также другое поведение масштабирования. Эта конфигурация изменяет поведение scaleDown.стабилизацияWindowSeconds и задает меньшее значение 60 секунд. На практике это не всегда требуется, но в этом случае вы можете ускорить процесс, чтобы быстрее увидеть, как средство автомасштабирования выполняет действие по уменьшению масштаба. По умолчанию HorizontalPodAutoscaler имеет период охлаждения 5 минут. В большинстве случаев этого достаточно, чтобы избежать колебаний при масштабировании реплик.

Когда будете готовы, разверните его с помощью kubectl:

  1. kubectl apply -f Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/manifests/hpa/metrics-server/quote-deployment-hpa-test.yaml -n hpa-external-load

Теперь проверьте, находится ли ресурс HPA на месте и активен:

  1. kubectl get hpa external-load-test -n hpa-external-load



Output
NAME                 REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
external-load-test   Deployment/quote   1%/20%    1         3         1          108s

Наконец, вы будете выполнять настоящие HTTP-запросы, используя сценарий оболочки quote_service_load_test.sh. Причина, по которой этот сценарий оболочки ранее не был встроен в манифест, заключается в том, что вы можете наблюдать, как он работает в вашем кластере, во время регистрации непосредственно на вашем терминале. Проверьте сценарий с помощью nano или вашего любимого текстового редактора:

  1. nano Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/scripts/quote_service_load_test.sh



#!/usr/bin/env sh

echo
echo "[INFO] Starting load testing in 10s..."
sleep 10
echo "[INFO] Working (press Ctrl+C to stop)..."
kubectl run -i --tty load-generator \
    --rm \
    --image=busybox \
    --restart=Never \
    -n hpa-external-load \
    -- /bin/sh -c "while sleep 0.001; do wget -q -O- http://quote; done" > /dev/null 2>&1
echo "[INFO] Load testing finished."

Для этой демонстрации откройте два отдельных окна терминала. В первом запустите сценарий оболочки quote_service_load_test.sh:

  1. Kubernetes-Starter-Kit-Developers/09-scaling-application-workloads/assets/scripts/quote_service_load_test.sh

Затем во втором окне запустите команду наблюдения kubectl, используя флаг -w для ресурса HPA:

  1. kubectl get hpa -n hpa-external-load -w

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

Output
NAME                 REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
external-load-test   Deployment/quote   1%/20%    1         3         1          2m49s
external-load-test   Deployment/quote   29%/20%   1         3         1          3m1s
external-load-test   Deployment/quote   67%/20%   1         3         2          3m16s

Вы можете наблюдать, как автомасштабирование срабатывает при увеличении нагрузки и увеличивает значение реплики развертывания сервера quote, установленное на более высокое значение. Как только сценарий генератора нагрузки останавливается, наступает период охлаждения, и примерно через 1 минуту набор реплик снижается до исходного значения 1. Вы можете нажать Ctrl+C, чтобы завершить запуск скрипта после возврата к первому окну терминала.

Заключение

В этом руководстве вы развернули и наблюдали за поведением автоматического масштабирования Horizontal Pod (HPA) с помощью Kubernetes Metrics Server в нескольких различных сценариях. HPA — это важный компонент Kubernetes, который помогает вашей инфраструктуре обрабатывать больше трафика по мере необходимости.

Metrics Server имеет существенное ограничение, заключающееся в том, что он не может предоставлять какие-либо метрики, кроме использования ЦП или памяти. Вы можете дополнительно просмотреть prometheus-adapter.