водяной знакподавтоскалер
0.7.0
Отказ от ответственности : Этот проект находится в стадии бета-тестирования. API может измениться.
Контроллер автомасштабирования модулей водяных знаков (WPA) — это специальный контроллер, расширяющий возможности автомасштабирования горизонтального модуля (HPA).
Контроллер автомасштабирования модулей Watermark является альтернативой вышестоящему контроллеру автомасштабирования модулей Horizontal Pod.
Если вы хотите автоматически масштабировать некоторые из своих приложений, но:
например
apiVersion : datadoghq.com/v1alpha1
kind : WatermarkPodAutoscaler
[...]
spec :
algorithm : absolute
[...]Есть два варианта вычисления желаемого количества реплик:
average Контроллер будет использовать value from the external metrics provider / current number of replicas и сравнивать его с водяными знаками. Рекомендуемое количество реплик — это value from the external metrics provider / watermark (низкое или высокое в зависимости от текущего значения).
Алгоритм average подойдет, если вы используете метрику, не зависящую от количества реплик. Обычно количество запросов, полученных ELB, может указывать, сколько веб-серверов мы хотим иметь, учитывая, что мы знаем, что один веб-сервер должен обрабатывать n запросов в секунду. Добавление реплики не приведет к увеличению или уменьшению количества запросов, получаемых балансировщиком нагрузки.
absolute Значением по умолчанию является absolute . Следует использовать средний показатель. Рекомендуемое количество реплик рассчитывается как current number of replicas * value from the external metrics provider или watermark .
absolute алгоритм используется по умолчанию, поскольку он представляет собой наиболее распространенный вариант использования. Например, если вы хотите, чтобы ваше приложение использовало от 60% до 80% ресурсов ЦП, а avg:cpu.usage составляет 85%, вам необходимо масштабировать его. Метрика должна быть коррелирована с количеством реплик.
Примечание . В вышестоящем контроллере для округления рекомендуемого количества реплик используется только функция math.Ceil .
Это означает, что если у вас есть пороговое значение 10, вам нужно будет достичь использования 8,999... от внешнего поставщика метрик, чтобы уменьшить масштаб на одну реплику. Однако использование 10.001 приведет к масштабированию на одну реплику.
Контроллер WPA будет использовать math.Floor , если значение находится под нижним водяным знаком. Это обеспечивает симметричное поведение. В сочетании с другими параметрами масштабирования это позволяет более точно контролировать время уменьшения масштаба.
Чтобы использовать автомасштабирование Watermark Pod, разверните его в своем кластере Kubernetes:
Загрузите ZIP-файл проекта Watermark Pod Autoscaler. Исходный код можно найти по адресу DataDog/watermarkpodautoscaler .
Разархивируйте проект и перейдите в папку ./watermarkpodautoscaler .
Определите пространство имен и контроллер автомасштабирования Watermark Pod:
DD_NAMESPACE= " datadog "
DD_NAMEWPA= " wpacontroller "Создайте пространство имен:
kubectl create ns $DD_NAMESPACEУстановите контроллер Autoscaler Watermark Pod с помощью Helm:
helm install $DD_NAMEWPA -n $DD_NAMESPACE ./chart/watermarkpodautoscalerКонтроллер WatermarkPodAutoscaler поставляется с плагином kubectl, предоставляющим набор вспомогательных утилит. Дополнительную информацию можно найти на специальной странице документации: docs/kubectl-plugin.md.
Создайте WPA в том же пространстве имен, что и целевое развертывание.
Агент кластера Datadog уловит событие создания/обновления/удаления. Он анализирует спецификацию WPA, чтобы извлечь метрику и область действия, которые можно получить от Datadog.
В этом примере мы используем следующую конфигурацию спецификации:
apiVersion : datadoghq.com/v1alpha1
kind : WatermarkPodAutoscaler
metadata :
name : example-watermarkpodautoscaler
spec :
downscaleForbiddenWindowSeconds : 60
downscaleDelayBelowWatermarkSeconds : 300
upscaleForbiddenWindowSeconds : 30
upscaleDelayAboveWatermarkSeconds : 30
scaleDownLimitFactor : 30
scaleUpLimitFactor : 50
minReplicas : 4
maxReplicas : 9
scaleTargetRef :
kind : " Deployment "
name : " some_app "
apiVersion : " apps/v1 "
metrics :
- external :
highWatermark : 400m
lowWatermark : 150m
metricName : custom.request_duration.max
metricSelector :
matchLabels :
kubernetes_cluster : mycluster
service : billing
short_image : billing-app
type : External
tolerance : " 0.01 " Поддерживаются как External , так и Resource типы метрик. Контроллер WPA использует тот же формат, что и HPA. Дополнительная информация здесь.
Начиная с водяных знаков, значение полученной метрики ( watermarkpodautoscaler.wpa_controller_value ) от Datadog, выделенное фиолетовым цветом, когда между границами ( watermarkpodautoscaler.wpa_controller_low_watermark и watermarkpodautoscaler.wpa_controller_high_watermark ) будет указывать контроллеру не запускать событие масштабирования. Они указаны как Quantities , поэтому вы можете использовать m | "" | k | M | G | T | P | E чтобы легко представить значение, которое вы хотите использовать.
Мы можем использовать метрику watermarkpodautoscaler.wpa_controller_restricted_scaling{reason:within_bounds} чтобы убедиться, что она действительно ограничена. Примечание : метрика была умножена на 1000, чтобы было более понятно, что в течение этого времени контроллер не мог инициировать ни одно событие масштабирования.
Второй набор параметров конфигурации относится к скорости масштабирования вашего развертывания, контролируемой scaleDownLimitFactor и scaleUpLimitFactor . Это целые числа от 0 до 100. Они представляют собой максимальный коэффициент соответственно уменьшения и увеличения масштаба с учетом текущего количества реплик.
В этом случае, если у нас будет 10 реплик и рекомендуемое количество реплик равное 14 (более подробную информацию о рекомендации см. в разделе «Алгоритм») с scaleUpFactor равным 30 (%), мы будем ограничены 13 репликами.
На следующем графике мы видим, что предлагаемое количество реплик (отмечено фиолетовым цветом), представленное метрикой watermarkpodautoscaler.wpa_controller_replicas_scaling_proposal слишком велико по сравнению с текущим количеством реплик. Это активирует логику ограничения масштаба, которую можно отслеживать с помощью метрики watermarkpodautoscaler.wpa_controller_restricted_scaling{reason:upscale_capping} ( Примечание : как и выше, метрика была умножена, чтобы сделать ее более явной). Таким образом, эффективное количество реплик watermarkpodautoscaler.wpa_controller_replicas_scaling_effective будет масштабироваться, но в соответствии с scaleUpLimitFactor .
В этом аналогичном примере мы избегаем слишком сильного уменьшения масштаба и можем использовать тот же набор метрик, чтобы гарантировать, что мы масштабируемся только на разумное количество реплик.
Важно отметить, что мы всегда принимаем консервативные решения по масштабированию.
scaleUpLimitFactor 29 %: если у нас 10 реплик, а рекомендуется 13, мы увеличим масштаб до 12.scaleDownLimitFactor 29 %: если у нас 10 реплик, а рекомендуется 7, мы уменьшим масштаб до 8.minReplicas и maxReplicas имеют приоритет. Обратитесь к разделу «Приоритет». Наконец, последние доступные параметры — downscaleForbiddenWindowSeconds и upscaleForbiddenWindowSeconds . Они показывают, сколько времени (в секундах) после события масштабирования необходимо ждать перед уменьшением и увеличением масштаба соответственно. Мы сохраняем только последнее событие масштабирования и не сравниваем upscaleForbiddenWindowSeconds с последним разом, когда мы только повышали масштаб.
В следующем примере мы видим, что рекомендуемое количество реплик игнорируется, если мы находимся в периоде восстановления. Период восстановления при уменьшении масштаба можно визуализировать с помощью watermarkpodautoscaler.wpa_controller_transition_countdown{transition:downscale} , он обозначен желтым цветом на графике ниже. Мы видим, что он значительно превышает период восстановления повышенного уровня ( transition:upscale ), отмеченный оранжевым цветом на нашем графике. Если нам рекомендовано масштабироваться, мы будем масштабироваться только в том случае, если соответствующее окно восстановления истекло. Это сбросит оба обратного отсчета.
Чтобы избежать масштабирования из-за всплесков, вы можете использовать следующие функции: downscaleDelayBelowWatermarkSeconds и/или upscaleDelayAboveWatermarkSeconds . Эти параметры указываются как целые числа. Метрики должны оставаться выше или ниже соответствующего водяного знака в течение настроенного периода времени. Следить за тем, сколько времени осталось в статусе WPA, можно:
- lastTransitionTime: "2022-11-15T02:02:09Z"
message: Allow downscaling if the value stays under the Watermark
reason: Value below Low Watermark
status: "False"
type: BelowLowWatermark
Или в логах контроллера:
{"level":"info","ts":1668481092517.446,"logger":"controllers.WatermarkPodAutoscaler","msg":"Will not scale: value has not been out of bounds for long enough","watermarkpodautoscaler":"datadog/example-watermarkpodautoscaler","wpa_name":"example-watermarkpodautoscaler","wpa_namespace":"datadog","time_left":3209}
Примечание. Если вы используете несколько метрик с этой функцией, условие выше/ниже рассматривается с использованием OR метрик.
Например, предположим, что у вас есть 60-секундная upscaleDelay с двумя метриками: M1 и M2. Если M1 остается выше своей верхней отметки в течение 40 секунд [t0; t40] , а M2 превышает свою верхнюю отметку на 30 секунд, перекрываясь с M1 в течение последних 10 секунд, [t30; t60] , это проверяет условие upscaleDelay и допускает событие масштабирования.
Получая значение внешней метрики, мы сначала сравниваем его с суммой highWatermark + tolerance и с разницей lowWatermark - tolerance . Если мы находимся за пределами границ, мы вычисляем рекомендуемое количество реплик. Затем мы сравниваем это значение с текущим количеством реплик, чтобы потенциально ограничить рекомендуемое количество реплик в соответствии с minReplicas и maxReplicas . Наконец, мы проверяем, разрешено ли нам масштабирование, учитывая значения downscaleForbiddenWindowSeconds и upscaleForbiddenWindowSeconds .
Чтобы иметь более детальный контроль над условиями масштабирования цели, вы можете использовать следующие функции:
minAvailableReplicaPercentage : указывает минимальный процент реплик, которые должны быть доступны, чтобы контроллер мог автоматически масштабировать цель. Например, если установлено значение 50 и менее половины модулей за целью находятся в состоянии «Доступно», цель не будет масштабироваться контроллером.
readinessDelaySeconds : указывает, сколько времени реплики должны работать, прежде чем они будут учтены при принятии решений по масштабированию.
Если все условия соблюдены, контроллер масштабирует целевой объект в scaleTargetRef до рекомендуемого количества реплик, только если флаг dryRun не установлен в true . Это будет указано путем регистрации:
{ "level" : " info " , "ts" : 1566327479.866722 , "logger" : " wpa_controller " , "msg" : " DryRun mode: scaling change was inhibited currentReplicas:8 desiredReplicas:12 " }Агент кластера запускает информер для ресурсов WPA и, как и HPA, при создании/обновлении/удалении анализирует спецификацию для запроса метрики у Datadog.
Агент кластера по умолчанию не запускает прослушиватель WPA. Чтобы включить WPA в агенте кластера, установите переменную среды DD_EXTERNAL_METRICS_PROVIDER_WPA_CONTROLLER=true и обновите ClusterRole, назначенную учетной записи службы агента кластера, чтобы иметь доступ к объектам WatermarkPodAutoscaler:
[...]
- apiGroups : ["datadoghq.com"]
resources :
- watermarkpodautoscalers
verbs :
- get
- list
- watch
[...] Примечание. Чтобы включить WPA в агенте кластера с помощью контрольной диаграммы datadog, установите для clusterAgent.metricsProvider.wpaController значение true . ClusterRole будет обновлен автоматически.
После того, как вы применили эти изменения и создали объект WPA, если вы запустите модуль Datadog Cluster Agent и запустите agent status вы сможете увидеть более конкретные сведения о спецификациях проанализированных автомасштабирующих устройств (будь то горизонтальный или автомасштабирование модуля водяных знаков).
* watermark pod autoscaler: default/example2-watermarkpodautoscaler
- name : example2-watermarkpodautoscaler
- namespace : default
- type : watermark
- uid : ff09b7d8-d99b-11e9-a8c1-42010a8001c4
Metric name : sinus
Labels :
- foo : bar
Value : 75.1297378540039
Timestamp : 15688259400
Valid : true
* horizontal pod autoscaler: default/nginxext
- name : nginxext
- namespace : default
- type : horizontal
- uid : 61ef3f6e-af32-11e9-a8c1-42010a8001c4
Metric name : docker.mem.rss
Labels :
- cluster-location : us-central1-a
- cluster-name : charly
Value : 263888700952
Timestamp : 15688259400
Valid : trueПомимо упомянутых выше показателей, это журналы, которые помогут вам лучше понять правильное функционирование WPA.
Каждые 15 секунд мы получаем от Datadog метрику, указанную в разделе metrics спецификации.
{ "level" : " info " , "ts" : 1668484420515.7678 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Metrics from the External Metrics Provider " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "metrics" :[ 33959 ]}
{ "level" : " info " , "ts" : 1668484420515.8203 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Value is below lowMark " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "usage" : " 33959m " , "replicaCount" : 7 , "currentReadyReplicas" : 8 , "tolerance (%)" : 1 , "adjustedLM" : 34650 , "adjustedUsage" : 33959 }
{ "level" : " info " , "ts" : 1668484420515.8906 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Proposing replicas " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "proposedReplicas" : 7 , "metricName" : " datadogmetric@datadog:example-watermarkpodautoscaler-utilization-metric{map[kube_container_name:my-container service:my-target]} " , "reference" : " Deployment/datadog/example-watermarkpodautoscaler " , "metric timestamp" : " Tue, 15 Nov 2022 03:53:20 UTC " }
{ "level" : " info " , "ts" : 1668484420515.9324 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Normalized Desired replicas " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "desiredReplicas" : 7 }
{ "level" : " info " , "ts" : 1668484420515.946 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Cooldown status " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "backoffUp" : false , "backoffDown" : false , "desiredReplicas" : 7 , "currentReplicas" : 8 }
{ "level" : " info " , "ts" : 1668484420515.9563 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Will not scale: value has not been out of bounds for long enough " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "time_left" : 2335 }Здесь текущее количество реплик, наблюдаемых в целевом развертывании, равно шести. Затем мы видим необработанное значение, полученное от внешнего поставщика метрик, и сравниваем его с верхним и нижним водяными знаками. Учитывая результат этого сравнения, мы печатаем рекомендуемое количество реплик. В данном случае это пять.
Если вы хотите напрямую запросить внешний поставщик метрик, вы можете использовать следующую команду:
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces// | jq ."
При желании вы также можете добавить селекторы меток, добавив ?labelSelector=key%3Dvalue . Если бы мы хотели получить нашу метрику в этом случае, мы могли бы использовать:
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces// | jq .?labelSelector=key%3Dvalue%2Cotherkey%3Dothervalue%2Cshort_image%3Dimage "
Если вы видите такие журналы, как:
{ "level" : " info " , "ts" : 1566397216.8918724 , "logger" : " wpa_controller " , "msg" : " failed to compute desired number of replicas based on listed metrics for Deployment/datadog/propjoe-green: failed to get external metric dd.propjoe.request_duration.max: unable to get external metric datadog/propjoe-green/&LabelSelector{MatchLabels:map[string]string{fooa: bar,},MatchExpressions:[],}: no metrics returned from external metrics API " }Затем вы можете убедиться, что эта метрика действительно недоступна у внешнего поставщика метрик. Это может произойти из-за опечатки в метках или из-за того, что метрику невозможно получить из Datadog (что может быть связано с различными факторами: слишком разреженность, неработоспособность API, превышение ограничения скорости и т. д.). Вы можете просмотреть журналы внешнего поставщика метрик для дальнейшего изучения.
Затем мы проверяем ограничение скорости масштабирования и окна восстановления. В случае ограничения масштабирования вы увидите что-то вроде:
{ "level" : " info " , "ts" : 1566327268.8839815 , "logger" : " wpa_controller " , "msg" : " Upscaling rate higher than limit of 50.0% up to 9 replicas. Capping the maximum upscale to 9 replicas " }
{ "level" : " info " , "ts" : 1566327268.884001 , "logger" : " wpa_controller " , "msg" : " Returning 9 replicas, condition: ScaleUpLimit reason the desired replica count is increasing faster than the maximum scale rate " }
{ "level" : " info " , "ts" : 1566327479.8845513 , "logger" : " wpa_controller " , "msg" : " -> after normalization: 9 " }Затем мы рассмотрим периоды восстановления. У вас будут журналы, показывающие, когда было последнее событие масштабирования, а также когда следующие события увеличения и уменьшения масштаба запрещены до тех пор, пока:
{ "level" : " info " , "ts" : 1566327479.8845847 , "logger" : " wpa_controller " , "msg" : " Too early to downscale. Last scale was at 2019-08-20 18:57:44 +0000 UTC, next downscale will be at 2019-08-20 18:58:44 +0000 UTC, last metrics timestamp: 2019-08-20 18:57:59 +0000 UTC " }
{ "level" : " info " , "ts" : 1566327479.8846018 , "logger" : " wpa_controller " , "msg" : " Too early to upscale. Last scale was at 2019-08-20 18:57:44 +0000 UTC, next upscale will be at 2019-08-20 18:58:14 +0000 UTC, last metrics timestamp: 2019-08-20 18:57:59 +0000 UTC " }
{ "level" : " info " , "ts" : 1566327479.884608 , "logger" : " wpa_controller " , "msg" : " backoffUp: true, backoffDown: true, desiredReplicas 5, currentReplicas: 6 " }Наконец, у нас есть подтверждение того, что развертывание было правильно автомасштабировано:
{ "level" : " info " , "ts" : 1566327253.7887673 , "logger" : " wpa_controller " , "msg" : " Successful rescale of watermarkpodautoscaler, old size: 8, new size: 9, reason: cutom_metric.max{map[kubernetes_cluster:my-cluster service:my-service short_image:my-image]} above target " }wpa.datadoghq.com/logs-attributes , чтобы добавить дополнительные значения ключей в журналы, связанные с базовым объектом WPA. Пример: apiVersion: datadoghq.com/v1alpha1
kind: WatermarkPodAutoscaler
metadata:
annotations:
wpa.datadoghq.com/logs-attributes: '{"mywpa": "isgreat"}'
name: watermarkpodautoscaler-sinus
namespace: default
[...]
даст:
{"level":"info","ts":1643642642091.062,"logger":"controllers.WatermarkPodAutoscaler","msg":"getReadyPodsCount","watermarkpodautoscaler":"default/watermarkpodautoscaler-sinus","mywpa":"isgreat","full podList length":2,"toleratedAsReadyPodCount":2,"incorrectly targeted pods":0}
Что произойдет, если я масштабирую развертывание вручную?
В следующем цикле согласования новое количество реплик будет учитываться для вычисления желаемого количества реплик. Вы можете увидеть журнал, в котором говорится, что ресурс был изменен кем-то другим. Однако если количество настроенных реплик выходит за пределы допустимого диапазона, контроллер уменьшит его до количества реплик в пределах допустимого диапазона.
Как временно отключить WPA для ручного масштабирования моего развертывания?
Рекомендуемый способ — установить WPA в режим пробного запуска, а затем масштабировать его до нужного количества реплик. Вы можете настроить WPA в пробном режиме с помощью этой команды исправления:
kubectl patch wpa --type='json' -p='[{"op": "replace", "path": "/spec/dryRun", "value":true}]'
Не забудьте вернуть режим пробного запуска в значение false после завершения временного переопределения, чтобы WPA снова стал активным.
Какова площадь контроллера?
Согласно нашему тестированию, это фактор, влияющий на количество развертываний в кластере.
Контроллер не имеет состояния?
Да.
Поддерживает ли WPA несколько метрик?
Да, WPA может масштабироваться по нескольким показателям и работает аналогично HPA. WPA оценивает каждую метрику отдельно и предлагает количество реплик, связанных с метрикой, для которой требуется наибольшее количество. Например, если WPA оценивает metric1, metric2, metric3 и для каждого рассчитывает 10, 20, 30 предложений реплик соответственно, окончательное предложение будет равно 30.
Поскольку мы отслеживаем все определения WPA в целом по кластеру, мы используем кластерную роль.
Полезная опция — выдать себя за пользователя для проверки прав. Например, чтобы убедиться, что у вас есть право на развертывание в качестве учетной записи службы контроллера WPA:
kubectl get deploy < your_deploy > --as system:serviceaccount:datadog:watermarkpodautoscaler -n < your_ns >Или запросите внешний поставщик метрик:
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces//metric --as system:serviceaccount::watermarkpodautoscaler Требования:
После клонирования репозитория https://github.com/DataDog/watermarkpodautoscaler установите некоторые переменные среды:
export GO111MODULE=on
unset GOPATH
export PATH= $PATH : $( pwd ) /bin Затем, чтобы установить некоторые зависимости инструментов, запустите make install-tools .
make install-tools : Установите инструменты для использования SDK оператора.make build : собрать контроллер локально.make generate : Запустить несколько операторов SDK-генератора, который генерирует код для контроллера и регистрации информера.make test : Запустить модульные тесты.make validate : Запустить распространенные линтеры Golang ( golangci-lint ).make e2e : запустить сквозные тесты в текущем настроенном кластере Kubernetes.make container : создайте образ Docker контроллера с помощью SDK оператора.make container-ci : Создайте образ Docker контроллера с помощью многоэтапного Dockerfile.Документация по процессу выпуска доступна здесь.
Некоторые функции были вдохновлены конфигурируемым HPA или CHPA. Большая часть структуры кода также использовалась для автомасштабирования Watermark Pod, хотя общая упаковка CRD выполнялась с помощью SDK оператора.
