HPA с пользовательскими метриками - PullRequest
1 голос
/ 30 апреля 2020

Я столкнулся с двумя различными подходами к масштабированию по конкретному c metri c, и мне интересно, в чем разница, и если таковое есть в моем случае.

У меня есть развертывание на GKE, которое включает в себя очистку и экспорт указанного c metri c из приложения в драйвер стека. с помощью коляски Прометей-на-SD. metri c появляется на стековом драйвере как custom.googleapis.com/dummy/foo

сейчас, обычно, когда я делаю HPA для настраиваемого metri c, я использую его следующим образом:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: custom-metric-prometheus-sd
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: custom-metric-prometheus-sd
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: External
    external:
      metricName: "custom.googleapis.com|dummy|foo"
      targetAverageValue: 20

теперь тот же самый hpa работает также с использованием метода метрик Pod. вроде:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: custom-metric-prometheus-sd
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: custom-metric-prometheus-sd
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: Pods
    pods:
      metricName: "custom.googleapis.com|dummy|foo"
      targetAverageValue: 20

работает так же. Я понимаю, что при использовании Pod Metrics HPA будет извлекать метрики из всех модулей и вычислять среднее значение, которое будет сравниваться с целевым значением для определения количества реплик. в основном это то же самое, как если бы вы использовали targetAverageValue в метрике External c. так, в моем случае оба будут делать то же самое, верно? может быть, что-то другое в аспектах производительности, задержки, чего-нибудь еще?

спасибо Чен

1 Ответ

0 голосов
/ 07 мая 2020

Да, вы в значительной степени правы. Метрики, которые вы указали в своем вопросе, будут работать так же.

Пройдем немного глубже и прочтем документацию о типе метрик: Kubernetes.io: Документы: Справка: API Kubernetes: v1.18: Метрика c -v2beta1-autoscaling

ExternalMetricSource - внешний относится к глобальной метрике c, которая не связана ни с одним объектом Kubernetes. Это позволяет автоматическое масштабирование на основе информации, поступающей от компонентов, работающих за пределами кластера (например, длина очереди в службе облачных сообщений или QPS от loadbalancer, работающей за пределами кластера).

PodsMetricSource - относится к pods метрике c, описывающей каждый модуль в текущем целевом масштабе (например, количество обработанных транзакций в секунду). Значения будут усреднены вместе перед сравнением с целевым значением.

Пожалуйста, имейте в виду, что эта ссылка для API версии 1.18. Пожалуйста, используйте версию, соответствующую вашему варианту использования.

Документация показывает, что они разработаны как разные метрики, но их можно использовать так же, как и вы.

Помимо описания, еще одна вещь, отличающая их, состоит в том, что metri c:

  • External имеет поля:
    • metricName
    • metricSelector
    • targetAverageValue
    • targetValue
  • Pods имеет поля:
    • metricName
    • metricSelector
    • targetAverageValue

Как вы можете видеть выше, Pods Метри c не имеет поля targetValue.

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

Пожалуйста, дайте мне знать, если у вас есть какие-либо вопросы по этому поводу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...