Масштабируйте свои контейнеры с помощью настраиваемых показателей Stackdriver, которые важны для вашего бизнеса

Если вы посмотрите на самые популярные функции Kubernetes, скорее всего, автоматическое масштабирование займет первое место в списке. Kubernetes предоставляет ресурс под названием «HorizontalPodAutoscaler», который является встроенной функцией для масштабирования ваших контейнеров на основе нескольких факторов, таких как использование ресурсов (ЦП и память), использование сети или трафик внутри модулей. Если ваш кластер приближается к пределу ресурсов и вам нужно добавить больше узлов в кластер, то управляемые службы Kubernetes, такие как GKE, предоставляют Kubernetes Cluster Autoscaler из коробки.

Представьте, что вы запустили приложение и, естественно, начали с малого, поскольку не ожидали большого спроса. Однако публикация в социальных сетях заставляет ваше приложение стать вирусным, и люди внезапно понимают, насколько это круто. Теперь все хотят использовать ваше приложение, и объем трафика резко возрос! Вы беспокоитесь, потому что не знаете, сможет ли ваше приложение взять на себя дополнительную нагрузку.

К счастью, вы понимаете, что спроектировали свое приложение для работы в Kubernetes и развернули его на Google Kubernetes Engine. Приложение легко масштабируется в соответствии с потребностями из-за почти бесконечной возможности масштабирования, предоставляемой Google Cloud.

Как работает автоматическое масштабирование горизонтальных модулей

Автоматическое масштабирование горизонтальных модулей широко использует три категории показателей из коробки:

  • Показатели ресурсов - это такие показатели, как использование ЦП и памяти.
  • Метрики модуля - это показатели, специфичные для модуля, такие как использование сети и трафик (например, количество пакетов в секунду).
  • Метрики объекта - это метрики определенных типов объектов. Например, если вы используете Ingress, вы можете использовать количество запросов в секунду для масштабирования ваших контейнеров.

Вы можете добиться всего этого, используя HorizontalPodAutoscaler манифест, подобный приведенному ниже:

Если вы примените приведенный выше манифест, он автоматически масштабирует развертывание Nginx от одной до десяти реплик на основе:

  • Метрика ресурсов - средняя загрузка ЦП менее 50%.
  • Метрика пакета - средний трафик пакета 1 Кбайт в секунду.
  • Метрика объекта - трафик 10 000 запросов в секунду по всем модулям.

В показателях объекта можно использовать как значение, так и среднее значение. Например, метрика объекта requests-per-second, используемая в части Ingress, будет описывать общий трафик, идущий ко всем модулям, управляемым ресурсом Ingress. Если бы мы использовали Среднее значение, оно бы разделило значение на количество контейнеров и сравнило бы его с целевым значением.

Имейте в виду, что с увеличением количества подов процент распределения нагрузки уменьшается. Например, если вы запускаете один модуль и вращаете другой, новый модуль займет 50% вашей нагрузки. Но если раскрутить третью, то уйдет 33%. Десятый займет всего 10% вашей нагрузки. Поэтому всегда планируйте максимальное количество подов, помня, какую емкость вы хотите, и всегда выделяйте свой кластер на определенную сумму, чтобы справиться с некоторой пакетной емкостью. Использование Kubernetes Cluster Autoscaler вместе с Horizontal Pod Autoscaler - отличная идея.

Использование внешних показателей

Масштабирование на основе метрик объекта Kubernetes - это здорово. Однако это не влияет на качество обслуживания клиентов. Такие показатели, как использование ЦП, использование памяти и пропускная способность сети, будут иметь смысл для инженера. Тем не менее, для клиента, использующего ваше приложение, ключевыми показателями производительности являются такие показатели, как время отклика. Клиентов не волнует, как вы запускаете свое приложение. Все, что их волнует, - это беспроблемное взаимодействие с пользователем - один сбой - и вы потеряете потенциального клиента.

К счастью, Kubernetes предоставляет возможность использовать внешние метрики для масштабирования ваших контейнеров. Давайте рассмотрим пример использования пользовательских метрик в Google Kubernetes Engine. Google использует Stackdriver в качестве решения для мониторинга по умолчанию, и вы можете отправлять в него пользовательские метрики из своего приложения. Вы также можете развернуть решение для мониторинга, такое как Prometheus, которое может отслеживать настраиваемые метрики, такие как время ответа, и публиковать их в Stackdriver. Затем вы можете использовать Stackdriver Adapter для пользовательских метрик для Kubernetes, чтобы читать метрики Stackdriver для автоматического масштабирования контейнеров приложений.

Итак, без лишних слов, давайте посмотрим, как этого добиться.

Включить Stackdriver в Google Cloud

Если вы еще не включили Stackdriver в Google Cloud, перейдите в консоль Google Cloud - ›Мониторинг. Это должно создать для вас новое рабочее пространство, подобное приведенному ниже:

Развертывание адаптера Stackdriver для пользовательских метрик

Для Google Kubernetes требуется Адаптер Stackdriver Custom Metrics, чтобы позволить Horizontal Pod Autoscaler запрашивать пользовательские метрики из Stackdriver. Войдите в свой кластер GKE и начните с предоставления текущему пользователю роли администратора кластера, чтобы он мог развернуть адаптер:

$ kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user "$(gcloud config get-value account)"

Затем выполните команду ниже, чтобы развернуть адаптер:

$ kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml

Экспорт пользовательских показателей из вашего приложения

Затем вам нужно будет развернуть приложение для экспорта метрик в Stackdriver. Для этого вы можете использовать инструмент мониторинга, такой как Prometheus (тема для другой статьи), или пользовательское приложение, которое отправляет метрики в Stackdriver, что мы собираемся обсудить сейчас.

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

  • Вид метрики должен быть GAUGE.
  • Тип показателя может быть INT64 или DOUBLE.
  • Перед названием показателя следует указать custom.googleapis.com/.
  • Тип ресурса должен быть "gke_container".
  • И метки ресурсов должны иметь pod_id и необязательный container_name = "".
  • project_id, zone и cluster_name являются обязательными значениями, и их можно получить с сервера метаданных с помощью клиента вычислений метаданных Google Cloud.
  • Вы можете установить namespace_id и instance_id на любое значение.

В приведенном выше манифесте определяется настраиваемая метрика responsetime и отправляется настроенное время ответа каждые пять секунд. Конечно, это только для тестирования. На самом деле вам нужно иметь решение для мониторинга, которое может собирать и отправлять эти метрики в Stackdriver.

Google предоставляет пример репозитория, чтобы продемонстрировать, как вы можете отправлять метрики в Stackdriver, и мы явно будем использовать этот. Итак, приступим:

$ git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git
$ cd kubernetes-engine-samples/custom-metrics-autoscaling/direct-to-sd/
$ sed -i 's/foo/responsetime/g' custom-metrics-sd.yaml
$ kubectl apply -f custom-metrics-sd.yaml
$ kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
custom-metric-sd-b6d766db9-96fd4   1/1     Running   0          7s
$ kubectl logs custom-metric-sd-b6d766db9-96fd4
2020/04/20 22:49:32 Failed to write time series data: googleapi: Error 500: One or more TimeSeries could not be written: An internal error occurred.: timeSeries[0], backendError
2020/04/20 22:49:37 Failed to write time series data: googleapi: Error 500: One or more TimeSeries could not be written: An internal error occurred.: timeSeries[0], backendError
2020/04/20 22:49:42 Finished writing time series with value: 0xc420015290
2020/04/20 22:49:47 Finished writing time series with value: 0xc420015290
2020/04/20 22:49:52 Finished writing time series with value: 0xc420015290
2020/04/20 22:49:57 Finished writing time series with value: 0xc420015290
2020/04/20 22:50:02 Finished writing time series with value: 0xc420015290
2020/04/20 22:50:07 Finished writing time series with value: 0xc420015290
2020/04/20 22:50:12 Finished writing time series with value: 0xc420015290

Итак, теперь у нас есть модуль и отправка пользовательских показателей в Stackdriver. Проверим, отображаются ли параметры на Stackdriver или нет.

Перейдите в Google Cloud Console - ›Мониторинг -› Metrics Explorer.

На вкладке МЕТРИЧЕСКИЙ введите gke_container и выберите показатель custom/responsetime.

Как видите, отображается параметр responsetime , и текущее значение равно 40. Мы успешно включили экспорт пользовательских метрик из Google Kubernetes Engine в Stackdriver.

Развертывание горизонтального автомасштабирования модулей

Поскольку мы развернули экспортер метрик, давайте реализуем HorizontalPodAutoscaler, который масштабируется на основе метрик, указанных выше:

$ sed -i 's/foo/responsetime/g' custom-metrics-sd-hpa.yaml
$ kubectl apply -f custom-metrics-sd-hpa.yaml
$ kubectl get hpa
NAME               REFERENCE                     TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
custom-metric-sd   Deployment/custom-metric-sd   40/20     1         5         1          17s
$ kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
custom-metric-sd-b6d766db9-96fd4   1/1     Running   0          10m
custom-metric-sd-b6d766db9-lbxnr   1/1     Running   0          97s
custom-metric-sd-b6d766db9-n9tfv   1/1     Running   0          113s
custom-metric-sd-b6d766db9-qdtgp   1/1     Running   0          97s
custom-metric-sd-b6d766db9-xxhrt   1/1     Running   0          82s

Как видите, количество подов быстро увеличилось до пяти реплик, поскольку параметры пересекают ожидаемое среднее значение 20.

Давайте изменим среднее время отклика до десяти и попробуем еще раз:

$ sed -i 's/40/10/g' custom-metrics-sd.yaml
$ kubectl apply -f custom-metrics-sd.yaml
$ kubectl get pods
NAME                               READY   STATUS        RESTARTS   AGE
custom-metric-sd-b6d766db9-lbxnr   0/1     Terminating   0          2m37s
custom-metric-sd-b6d766db9-n9tfv   0/1     Terminating   0          2m53s
custom-metric-sd-b6d766db9-qdtgp   0/1     Terminating   0          2m37s
custom-metric-sd-b6d766db9-xxhrt   0/1     Terminating   0          2m22s
custom-metric-sd-f6b4cc784-qbmqx   1/1     Running       0          2m20s
$ kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
custom-metric-sd-6ff96cfbf8-nrzb5   1/1     Running   0          4m5s

Как видите, HPA завершает работу модулей, чтобы уменьшить набор реплик.

Если мы теперь вернемся к панели инструментов Stackdriver, мы увидим следующее:

Поздравляю! Вы успешно настроили автоматическое масштабирование горизонтальных модулей на основе пользовательских метрик Stackdriver в Google Kubernetes Engine.

Заключение

Спасибо за прочтение! Надеюсь, вам понравилась статья. Помните, что существует множество способов масштабирования ваших рабочих нагрузок в зависимости от ваших сценариев использования. Однако масштабирование контейнеров на основе показателей клиентского опыта, несомненно, поможет вашему бизнесу сделать все возможное и порадовать ваших клиентов!