|
|
Note that only HPA (Horizontal Pod Autoscaling) with apiVersion: autoscaling/v2, whose support has been available since Kubernetes v1.12, is discussed below.
| Ниже рассматривается только HPA (Horizontal Pod Autoscaling) с apiVersion: autoscaling/v2, чья поддержка появилась начиная с Kubernetes v1.12.
|
Configuring HPA requires:
- defining what is being scaled (
.spec.scaleTargetRef );
- defining the scaling range (
.spec.minReplicas , .scale.maxReplicas );
- defining metrics to be used as the basis for scaling (
.spec.metrics ) and registering them with the Kubernetes API.
| Для настройки HPA требуется:
- определить, что именно масштабируется (
.spec.scaleTargetRef );
- определить диапазон масштабирования (
.spec.minReplicas , .scale.maxReplicas );
- зарегистрировать в API Kubernetes и определить метрики, на основе которых производится масштабирование (
.spec.metrics ).
|
Metrics in terms of HPA are of three types:
- classic — of type (
.spec.metrics[].type ) “Resource”; these are used for simple scaling based on CPU and memory consumption;
- custom — of type (
.spec.metrics[].type ) “Pods” or “Object”;
- external — of type (
.spec.metrics[].type ) “External”.
| Метрики с точки зрения HPA бывают трех видов:
- классические — с типом (
.spec.metrics[].type ) «Resource», используются для простейшего масштабирования по потреблению процессора и памяти;
- кастомные — с типами (
.spec.metrics[].type ) «Pods» или «Object»;
- внешние — с типом (
.spec.metrics[].type ) «External».
|
Caution! By default, HPA uses different approaches for scaling:
- If the metrics indicate that scaling up is required, it is done immediately (
spec.behavior.scaleUp.stabilizationWindowSeconds = 0). The only limitation is the rate of increase: pods can double in 15 seconds, but if there are less than 4 pods, 4 new pods will be added.
- If the metrics indicate that scaling down is required, it happens within 5 minutes (
spec.behavior.scaleUp.stabilizationWindowSeconds = 300): suggestions for a new number of replicas are calculated, then the largest value is selected. There is no limit on the number of pods to be removed at once.
| Важно! По умолчанию HPA использует разные подходы при масштабировании:
- Если метрики указывают на требование масштабировать вверх, это происходит незамедлительно (
spec.behavior.scaleUp.stabilizationWindowSeconds = 0). Единственное ограничение — скорость прироста: за 15 секунд поды могут удвоиться, но если подов меньше 4, добавятся 4 новых пода.
- Если метрики указывают на то, что требуется масштабировать вниз, это происходит в течение 5 минут (
spec.behavior.scaleUp.stabilizationWindowSeconds = 300): собираются предложения о новом количестве реплик, в результате чего выбирается самое большое значение. Нет ограничений на количество удаляемых подов за один раз.
|
If metrics are subject to fluctuations that result in a surge of unnecessary application replicas, the following approaches are used:
- Wrapping the metric with an aggregation function (e. g.,
avg_over_time() ) if the metric is defined by a PromQL query. For more details, see. example.
- Increasing the stabilization window (parameter
spec.behavior.scaleUp.stabilizationWindowSeconds ) in the HorizontalPodAutoscaler resource. During the this period, requests to increase the number of replicas will be accumulated, then the most modest request will be selected. This method is identical to applying the min_over_time(<stabilizationWindowSeconds>) aggregation function, but only if the metric is increasing and scaling up is required. For scaling down, the default settings usually work good enough. For more details, see example.
- Limiting the rate of increase of the new replica count with
spec.behavior.scaleUp.policies .
| Если имеются проблемы с колебаниями метрик и происходит резкое увеличение ненужных реплик приложения, применяются следующие подходы:
- Оборачивание метрики агрегирующей функцией (например,
avg_over_time() ), если метрика определена PromQL-запросом. Подробнее см. пример.
- Увеличение времени стабилизации (параметр
spec.behavior.scaleUp.stabilizationWindowSeconds ) в ресурсе HorizontalPodAutoscaler. В течение обозначенного периода будут собираться предложения об увеличении количества реплик, в результате чего будет выбрано самое скромное предложение. Это решение тождественно применению агрегирующей функции min_over_time(<stabilizationWindowSeconds>) , но только в том случае, если метрика растет и требуется масштабирование вверх. Для масштабирования вниз, как правило, достаточно стандартных настроек. Подробнее см. пример.
- Ограничение скорости прироста новых реплик с помощью политик
spec.behavior.scaleUp.policies .
|
Scaling types
| Типы масштабирования
|
The following metrics can be used to scale applications:
- Classic metrics.
- Custom namespace-scoped metrics. This type is suitable if you have a single application, the source of the metrics is in the namespace and it is tied to one of the objects.
- Custom cluster-wide metrics. This type is suitable if you have many applications using the same metric, whose source is in the application namespace, and it is associated with one of the objects. Such metrics let you put common infrastructure components into a separate deployment (“infra”).
- If the metric source is not tied to the application namespace, you can use external metrics. For example, metrics provided by a cloud provider or an external SaaS service.
| Используйте следующие метрики для масштабирования приложений:
- Классического типа.
- Кастомные namespace-scoped-метрики. При условии, если у вас одно приложение, источник метрик находится внутри namespace и связан с одним из объектов.
- Кастомные cluster-wide-метрики. При условии, если у вас много приложений используют одинаковую метрику, источник которой находится в namespace приложения, и она связана с одним из объектов. Подобные метрики предусмотрены на случай необходимости выделения общих инфраструктурных компонентов в отдельный деплой («infra»).
- Если источник метрики не привязан к namespace приложения, используйте внешние метрики. Например, метрики облачного провайдера или внешнего SaaS-сервиса.
|
Caution! We recommend using option 1 (classic metrics), or option 2 (custom metrics defined in the Namespace). In this case, we suggest defining the application configuration (including its autoscaling) in the app repository. You should consider options 3 and 4 only if you have a large collection of identical microservices.
| Важно! Рекомендуется использовать вариант 1 (классические метрики), или вариант 2 (кастомные метрики, определяемые в Namespace). В этом случае, рекомендуется определить конфигурацию приложения, включающую его автоматическое масштабирование, в репозиторий самого приложения. Следует рассматривать варианты 3 и 4 только в том случае, если у вас имеется большая коллекция идентичных микросервисов.
|
Classic resource consumption-based scaling
| Классическое масштабирование по потреблению ресурсов
|
Below is an example HPA configuration for scaling based on the classic metrics from metrics.k8s.io : CPU and memory utilization for pods. The averageUtulization value reflects the target percentage of resources that have been requested.
| Пример HPA для масштабирования по базовым метрикам из metrics.k8s.io : CPU и памяти подов. Особое внимание на averageUtulization — это значение отражает целевой процент ресурсов, который был реквестирован.
|
yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-hpa
namespace: app-prod
spec:
Indicates the controller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app
Controller scaling limits.
minReplicas: 1
maxReplicas: 10
If the application is prone to short-term spikes in CPU consumption,
you can postpone the scaling decision to see if it is necessary.
By default, scaling up occurs immediately.
behavior:
scaleUp:
stabilizationWindowSeconds: 300
metrics:
CPU- and memory-based scaling.
- type: Resource
resource:
name: cpu
target:
Scaling will occur when the average CPU utilization of all pods in scaleTargetRef exceeds the specified value.
For a metric with type: Resource, only type: Utilization is available.
type: Utilization
Scaling will occur if 1 core is requested for all Deployment pods and if over 700m is already in use on average.
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
Example of a scaling rule when the average memory usage of all pods in scaleTargetRef exceeds the given value.
type: Utilization
Scaling will occur if 1 GB of memory is requested for the pods and more than 800 MB is already in use on average.
averageUtilization: 80
| yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-hpa
namespace: app-prod
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app
Границы масштабирования контроллера.
minReplicas: 1
maxReplicas: 10
Если для приложения характерны кратковременные скачки потребления CPU,
можно отложить принятие решения о масштабировании, чтобы убедиться, что оно необходимо.
По умолчанию масштабирование вверх происходит немедленно.
behavior:
scaleUp:
stabilizationWindowSeconds: 300
metrics:
Масштабирование по CPU и памяти.
- type: Resource
resource:
name: cpu
target:
Масштабирование, когда среднее использование CPU всех подов в scaleTargetRef превышает заданное значение.
Для метрики с type: Resource доступен только type: Utilization.
type: Utilization
Масштабирование, если для всех подов из Deployment запрошено по 1 ядру и в среднем уже используется более 700m.
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
Пример масштабирования, когда среднее использование памяти всех подов в scaleTargetRef превышает заданное значение.
type: Utilization
Масштабирование, если для подов запрошено по 1 ГБ памяти и в среднем использовано уже более 800 МБ.
averageUtilization: 80
|
Scaling based on custom metrics
| Масштабирование по кастомным метрикам
|
Registering custom metrics with Kubernetes API
| Регистрация кастомных метрик в Kubernetes API
|
Custom metrics must be registered with the /apis/custom.metrics.k8s.io/ API, this registration is done by prometheus-metrics-adapter (and it also implements the API). The metrics can then be referenced using the HorizontalPodAutoscaler object. Customizing a vanilla prometheus-metrics-adapter is a time-consuming process. We made it easier by defining a set of Custom Resources with different Scopes:
- Namespaced:
ServiceMetric ;
IngressMetric ;
PodMetric ;
DeploymentMetric ;
StatefulsetMetric ;
NamespaceMetric ;
DaemonSetMetric (unavailable to users).
- Cluster:
ClusterServiceMetric (unavailable to users);
ClusterIngressMetric (unavailable to users);
ClusterPodMetric (unavailable to users);
ClusterDeploymentMetric (unavailable to users);
ClusterStatefulsetMetric (unavailable to users);
ClusterDaemonSetMetric (unavailable to users).
| Кастомные метрики необходимо регистрировать в API /apis/custom.metrics.k8s.io/ , эту регистрацию производит prometheus-metrics-adapter (и он же реализует API). На эти метрики можно будет ссылаться из объекта HorizontalPodAutoscaler. Настройка ванильного prometheus-metrics-adapter — трудоемкий процесс, мы его упростили, определив набор Custom Resources с разным Scope:
- Namespaced:
ServiceMetric ;
IngressMetric ;
PodMetric ;
DeploymentMetric ;
StatefulsetMetric ;
NamespaceMetric ;
DaemonSetMetric (недоступен пользователям).
- Cluster:
ClusterServiceMetric (недоступен пользователям);
ClusterIngressMetric (недоступен пользователям);
ClusterPodMetric (недоступен пользователям);
ClusterDeploymentMetric (недоступен пользователям);
ClusterStatefulsetMetric (недоступен пользователям);
ClusterDaemonSetMetric (недоступен пользователям).
|
You can use the cluster-wide resource to define the metric globally, and use the Namespace to redefine it locally. Format is the same for all custom resources.
| С помощью cluster-wide-ресурса можно задать глобальное определение метрики, а с помощью Namespace можно переопределить её локально. Формат для всех custom resource — одинаковый.
|
Using custom metrics in HPA
| Применяем кастомные метрики в HPA
|
Once a custom metric is registered, it can be referenced. In terms of HPA, custom metrics can be of two types — Pods and Object .
| После регистрации кастомной метрики на нее можно ссылаться. С точки зрения HPA, кастомные метрики бывают двух видов — Pods и Object .
|
Object refers to an object in the cluster that has metrics in Prometheus with corresponding labels (namespace=XXX,ingress=YYYYY ). These labels will be substituted in place of <<.LabelMatchers>> in your custom request.
| Object — отсылает к объекту в кластере, который имеет в Prometheus метрики с соответствующими лейблами (namespace=XXX,ingress=YYY ). Эти лейблы будут подставляться вместо <<.LabelMatchers>> в вашем кастомном запросе.
|
yaml
apiVersion: deckhouse.io/v1beta1
kind: IngressMetric
metadata:
name: mymetric
namespace: mynamespace
spec:
query: sum(rate(ingress_nginx_detail_requests_total{«.LabelMatchers»}[2m])) by («.GroupBy») OR on() vector(0)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Specifies the controller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 1
maxReplicas: 2
Metrics to use for scaling.
An example of using custom metrics.
metrics:
- type: Object
object:
An object that has metrics in Prometheus.
describedObject:
apiVersion: networking.k8s.io/v1
kind: Ingress
name: myingress
metric:
A metric registered with the IngressMetric or ClusterIngressMetric custom resource.
You can use rps_1m, rps_5m, or rps_15m that come with the prometheus-metrics-adapter module.
name: mymetric
target:
You can use
Value or AverageValue for metrics of type Object.
type: AverageValue
Scaling occurs if the average value of the custom metric for all pods in the Deployment deviates significantly from 10.
averageValue: 10
| yaml
apiVersion: deckhouse.io/v1beta1
kind: IngressMetric
metadata:
name: mymetric
namespace: mynamespace
spec:
query: sum(rate(ingress_nginx_detail_requests_total{«.LabelMatchers»}[2m])) by («.GroupBy») OR on() vector(0)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 1
maxReplicas: 2
Метрики, используемые для масштабирования.
Пример использования кастомных метрик.
metrics:
- type: Object
object:
Объект, который обладает метриками в Prometheus.
describedObject:
apiVersion: networking.k8s.io/v1
kind: Ingress
name: myingress
metric:
Метрика, зарегистрированная с помощью custom resource IngressMetric или ClusterIngressMetric.
Можно использовать rps_1m, rps_5m или rps_15m которые поставляются с модулем prometheus-metrics-adapter.
name: mymetric
target:
Для метрик типа Object можно использовать
Value или AverageValue .
type: AverageValue
Масштабирование происходит, если среднее значение кастомной метрики для всех подов в Deployment сильно отличается от 10.
averageValue: 10
|
Pods — all pods will be selected from the resource managed by HPA and metrics will be collected for each pod with the relevant labels (namespace=XXX , pod=YYYY-sadiq , namespace=XXX , pod=YYYY-e3adf , etc.). Then the HPA will calculate an average value based on these metrics and will use it for scaling.
| Pods — из ресурса, которым управляет HPA, будут выбраны все поды и для каждого пода будут собраны метрики с соответствующими лейблами (namespace=XXX , pod=YYY-sadiq , namespace=XXX , pod=YYY-e3adf , и т. д.). Из этих показателей HPA рассчитает среднее значение и использует для масштабирования.
|
Using custom metrics with the RabbitMQ queue size
| Пример использования кастомных метрик с размером очереди RabbitMQ
|
In the example below, scaling is performed based on the send_forum_message queue in RabbitMQ for which the rmq service is registered. If the number of messages in this queue exceeds 42, scaling is carried out.
| В представленном примере рассматривается очередь send_forum_message в RabbitMQ, для которого зарегистрирован сервис rmq . Если количество сообщений в этой очереди превышает 42, выполняется масштабирование.
|
yaml
apiVersion: deckhouse.io/v1beta1
kind: ServiceMetric
metadata:
name: rmq-queue-forum-messages
namespace: mynamespace
spec:
query: sum (rabbitmq_queue_messages{«.LabelMatchers»,queue=~”send_forum_message”,vhost=”/”}) by («.GroupBy»)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
The controller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myconsumer
minReplicas: 1
maxReplicas: 5
metrics:
- type: Object
object:
describedObject:
apiVersion: v1
kind: Service
name: rmq
metric:
name: rmq-queue-forum-messages
target:
type: Value
value: 42
| yaml
apiVersion: deckhouse.io/v1beta1
kind: ServiceMetric
metadata:
name: rmq-queue-forum-messages
namespace: mynamespace
spec:
query: sum (rabbitmq_queue_messages{«.LabelMatchers»,queue=~”send_forum_message”,vhost=”/”}) by («.GroupBy»)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myconsumer
minReplicas: 1
maxReplicas: 5
metrics:
- type: Object
object:
describedObject:
apiVersion: v1
kind: Service
name: rmq
metric:
name: rmq-queue-forum-messages
target:
type: Value
value: 42
|
Using volatile custom metrics
| Пример использования нестабильной кастомной метрики
|
This example improves on the previous one.
| Улучшение предыдущего примера.
|
In the example below, scaling is based on the send_forum_message queue in RabbitMQ, for which the rmq service is registered. If the number of messages in this queue exceeds 42, scaling takes place. The MQL function avg_over_time() smooths (averages the metric) to avoid over-scaling due to short-term spikes in the number of messages.
| В представленном примере рассматривается очередь send_forum_message в RabbitMQ, для которого зарегистрирован сервис rmq . Если количество сообщений в этой очереди превышает 42, выполняется масштабирование. Мы не хотим реагировать на краткосрочные всплески, поэтому используется MQL-функцию avg_over_time() , чтобы усреднить метрику.
|
yaml
apiVersion: deckhouse.io/v1beta1
kind: ServiceMetric
metadata:
name: rmq-queue-forum-messages
namespace: mynamespace
spec:
query: sum (avg_over_time(rabbitmq_queue_messages{«.LabelMatchers»,queue=~”send_forum_message”,vhost=”/”}[5m])) by («.GroupBy»)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
The controller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myconsumer
minReplicas: 1
maxReplicas: 5
metrics:
- type: Object
object:
describedObject:
apiVersion: v1
kind: Service
name: rmq
metric:
name: rmq-queue-forum-messages
target:
type: Value
value: 42
| yaml
apiVersion: deckhouse.io/v1beta1
kind: ServiceMetric
metadata:
name: rmq-queue-forum-messages
namespace: mynamespace
spec:
query: sum (avg_over_time(rabbitmq_queue_messages{«.LabelMatchers»,queue=~”send_forum_message”,vhost=”/”}[5m])) by («.GroupBy»)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myconsumer
minReplicas: 1
maxReplicas: 5
metrics:
- type: Object
object:
describedObject:
apiVersion: v1
kind: Service
name: rmq
metric:
name: rmq-queue-forum-messages
target:
type: Value
value: 42
|
Examples involving custom metrics of type Pods
| Примеры с использованием кастомных метрик типа Pods
|
In the example below, the number of workers is scaled based on the percentage of active php-fpm workers.
The trigger is the average number of php-fpm-workers in mybackend Deployment, which should not exceed 5.
| Пример масштабирования воркеров по процентному количеству активных php-fpm-воркеров.
В представленом примере среднее количество php-fpm-воркеров в Deployment mybackend не больше 5.
|
yaml
apiVersion: deckhouse.io/v1beta1
kind: PodMetric
metadata:
name: php-fpm-active-workers
spec:
query: sum (phpfpm_processes_total{state=”active”,«.LabelMatchers»}) by («.GroupBy»)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
The controller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: mybackend
minReplicas: 1
maxReplicas: 5
metrics:
HPA has to loop through all the Deployment pods and collect metrics from them.
- type: Pods
Unlike type: Object, you don’t have to specify describedObject.
pods:
metric:
A custom metric registered using the PodMetric custom resource.
name: php-fpm-active-workers
target:
For metrics of type: Pods, only AverageValue can be used.
type: AverageValue
The scaling will take place if the average metric value of all Deployment pods exceeds 5.
averageValue: 5
| yaml
apiVersion: deckhouse.io/v1beta1
kind: PodMetric
metadata:
name: php-fpm-active-workers
spec:
query: sum (phpfpm_processes_total{state=”active”,«.LabelMatchers»}) by («.GroupBy»)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: mybackend
minReplicas: 1
maxReplicas: 5
metrics:
Указание HPA обойти все поды Deployment’а и собрать с них метрики.
- type: Pods
Указывать describedObject в отличие от type: Object не надо.
pods:
metric:
Кастомная метрика, зарегистрированная с помощью custom resource PodMetric.
name: php-fpm-active-workers
target:
Для метрик с type: Pods можно использовать только AverageValue.
type: AverageValue
Масштабирование, если среднее значение метрики у всех подов Deployment’а больше 5.
averageValue: 5
|
Scaling the Deployment based on the percentage number of active php-fpm-workers:
| Масштабируется Deployment по процентному количеству активных php-fpm-воркеров.
|
yaml
apiVersion: deckhouse.io/v1beta1
kind: PodMetric
metadata:
name: php-fpm-active-worker
spec:
Percentage of active php-fpm-workers. The round() function gets rid of millipercentages in HPA.
query: round(sum by(«.GroupBy») (phpfpm_processes_total{state=”active”,«.LabelMatchers»}) / sum by(«.GroupBy») (phpfpm_processes_total{«.LabelMatchers»}) * 100)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: {{ .Chart.Name }}-hpa
spec:
The cpntroller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: {{ .Chart.Name }}
minReplicas: 4
maxReplicas: 8
metrics:
- type: Pods
pods:
metric:
name: php-fpm-active-worker
target:
type: AverageValue
Scaling will take place if, on average, the Deployment has 80% of the workers in use.
averageValue: 80
| yaml
apiVersion: deckhouse.io/v1beta1
kind: PodMetric
metadata:
name: php-fpm-active-worker
spec:
Процент активных php-fpm-воркеров. Функция round() для того, чтобы не смущаться от миллипроцентов в HPA.
query: round(sum by(«.GroupBy») (phpfpm_processes_total{state=”active”,«.LabelMatchers»}) / sum by(«.GroupBy») (phpfpm_processes_total{«.LabelMatchers»}) * 100)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: {{ .Chart.Name }}-hpa
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: {{ .Chart.Name }}
minReplicas: 4
maxReplicas: 8
metrics:
- type: Pods
pods:
metric:
name: php-fpm-active-worker
target:
type: AverageValue
Масштабирование, если в среднем по Deployment 80% воркеров заняты.
averageValue: 80
|
Registering external metrics with the Kubernetes API
| Регистрация внешних метрик в Kubernetes API
|
The prometheus-metrics-adapter module supports the externalRules mechanism. It allows you to define custom PromQL queries and register them as metrics.
| Модуль prometheus-metrics-adapter поддерживает механизм externalRules , с помощью которого можно определять кастомные PromQL-запросы и регистрировать их как метрики.
|
A universal rule that allows you to create your own metrics without customization in prometheus-metrics-adapter has been added in the installation examples — “any metric in Prometheus with the name kube_adapter_metric_<name> will be registered in the API under the name <name> ”. Then, you just need to write an exporter that will export such a metric or create a recording rule in Prometheus that will aggregate your metric based on other metrics.
| В примерах инсталляций добавлено универсальное правило, которое позволяет создавать собственные метрики без настроек в prometheus-metrics-adapter , — «любая метрика в Prometheus с именем kube_adapter_metric_<name> будет зарегистрирована в API под именем <name> ». После чего, остается написать экспортер (exporter), который будет экспортировать подобную метрику, или создать правило recording rule в Prometheus, которое будет агрегировать вашу метрику на основе других метрик.
|
Below is an example of CustomPrometheusRules:
| Пример CustomPrometheusRules:
|
The example showcases Prometheus custom rules for the mymetric metric.
| В примере представлены пользовательские правила Prometheus для метрики mymetric .
|
yaml
apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
The recommended template for naming your CustomPrometheusRules.
name: prometheus-metrics-adapter-mymetric
spec:
groups:
The recommended template
- name: prometheus-metrics-adapter.mymetric
rules:
The name of your new metric
Note that the ‘kube_adapter_metric_’ prefix is mandatory.
- record: kube_adapter_metric_mymetric
A request with results that will end up in the final metric; there’s no point in attaching extra labels to it.
expr: sum(ingress_nginx_detail_sent_bytes_sum) by (namespace,ingress)
| В примере представлены пользовательские правила Prometheus для метрики mymetric .
|
Using external metrics in HPA
| yaml
apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
Рекомендованный шаблон для названия ваших CustomPrometheusRules.
name: prometheus-metrics-adapter-mymetric
spec:
groups:
Рекомендованный шаблон.
- name: prometheus-metrics-adapter.mymetric
rules:
Название вашей новой метрики.
Важно! Префикс ‘kube_adapter_metric_’ обязателен.
- record: kube_adapter_metric_mymetric
Запрос, результаты которого попадут в итоговую метрику, нет смысла тащить в нее лишние лейблы.
expr: sum(ingress_nginx_detail_sent_bytes_sum) by (namespace,ingress)
|
Once an external metric is registered, you can refer to it.
| Применение внешних метрик в HPA
|
yaml
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
The controller to be scaled (reference to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 1
maxReplicas: 2
metrics:
Scaling based on the external metrics
- type: External
external:
metric:
The metric we registered by creating a metric in Prometheus (kube_adapter_metric_mymetric), but without the prefix ‘kube_adapter_metric_’.
name: mymetric
selector:
For external metrics, you can and should refine the request with labels.
matchLabels:
namespace: mynamespace
ingress: myingress
target:
Only
type: Value can be used for metrics of type External.
type: Value
Scaling will take place if the value of our metric exceeds 10.
value: 10
| После регистрации внешней метрики на нее можно сослаться.
|
Using the queue size in Amazon SQS
| yaml
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 1
maxReplicas: 2
metrics:
Используем внешние метрики для масштабирования.
- type: External
external:
metric:
Метрика, которую мы зарегистрировали с помощью создания метрики в Prometheus kube_adapter_metric_mymetric, но без префикса ‘kube_adapter_metric_’.
name: mymetric
selector:
Для внешних метрик можно и нужно уточнять запрос с помощью лейблов.
matchLabels:
namespace: mynamespace
ingress: myingress
target:
Для метрик типа External можно использовать только
type: Value .
type: Value
Масштабирование, если значение нашей метрики больше 10.
value: 10
|
To install an exporter to integrate with SQS:
- Create a dedicated “service” Git repository ( alternatively, you could use, e.g., an “infrastructure” repository).
- Copy the exporter installation and the script to it — these will be used to create the necessary CustomPrometheusRules.
| Пример с размером очереди в Amazon SQS
|
That’s it, you have integrated the cluster. In case you need to configure autoscaling for just one application (in a single namespace), we recommend installing the exporter together with that application and using NamespaceMetrics .
| Чтобы установить экспортер для интеграции с SQS:
- Создайте отдельный “служебный” репозиторий Git (или, к примеру, можно использовать “инфраструктурный” репозиторий).
- Разместите в нем инсталляцию экспортера и сценарий для создания требуемого CustomPrometheusRules.
|
The following is an example of an exporter (e. g., sqs-exporter) to retrieve metrics from Amazon SQS if:
- a
send_forum_message queue is running in Amazon SQS;
- scaling is done when the number of messages in that queue exceeds 42.
| Готово, вы объединили кластер. Если необходимо настроить автомасштабирование только для одного приложения (в одном пространстве имен), лучше ставить экспортер вместе с этим приложением и воспользоваться NamespaceMetrics .
|
yaml
apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
The recommended name — prometheus-metrics-adapter-.
name: prometheus-metrics-adapter-sqs-messages-visible
Pay attention!
namespace: d8-monitoring
labels:
Pay attention!
prometheus: main
Pay attention!
component: rules
spec:
groups:
- name: prometheus-metrics-adapter.sqs_messages_visible # the recommended template
rules:
- record: kube_adapter_metric_sqs_messages_visible # Pay attention! The ‘kube_adapter_metric_’ prefix is required.
expr: sum (sqs_messages_visible) by (queue)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
The targets of scaling (link to a deployment or statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myconsumer
minReplicas: 1
maxReplicas: 5
metrics:
- type: External
external:
metric:
Must match CustomPrometheusRules record name without ‘kube_adapter_metric_’ prefix.
name: sqs_messages_visible
selector:
matchLabels:
queue: send_forum_messages
target:
type: Value
value: 42
| Ниже приведен пример экспортера (например, sqs-exporter) для получения метрик из Amazon SQS, если:
- в Amazon SQS работает очередь
send_forum_message ;
- выполняется масштабирование при количестве сообщений в этой очереди больше 42.
|
Debugging
| yaml
apiVersion: deckhouse.io/v1
kind: CustomPrometheusRules
metadata:
Рекомендованное название — prometheus-metrics-adapter-.
name: prometheus-metrics-adapter-sqs-messages-visible
spec:
groups:
Рекомендованный шаблон названия.
- name: prometheus-metrics-adapter.sqs_messages_visible
rules:
Важно! Префикс ‘kube_adapter_metric_’ обязателен.
- record: kube_adapter_metric_sqs_messages_visible
expr: sum (sqs_messages_visible) by (queue)
—
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2
metadata:
name: myhpa
namespace: mynamespace
spec:
Указывается контроллер, который нужно масштабировать (ссылка на deployment или statefulset).
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myconsumer
minReplicas: 1
maxReplicas: 5
metrics:
- type: External
external:
metric:
name должен совпадать с CustomPrometheusRules record без префикса ‘kube_adapter_metric_’.
name: sqs_messages_visible
selector:
matchLabels:
queue: send_forum_messages
target:
type: Value
value: 42
|
How do I get a list of custom metrics?
| Способы отладки
|
shell
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/
| Как получить список кастомных метрик?
|
How do I get the value of a metric associated with an object?
| shell
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/
|
shell
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/services//my-service-metric
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/ingresses//rps_1m
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/ingresses/*/mymetric
| Как получить значение метрики, привязанной к объекту?
|
How do I get the value of a metric created via NamespaceMetric ?
| shell
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/services//my-service-metric
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/ingresses//rps_1m
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/ingresses/*/mymetric
|
shell
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/metrics/my-ns-metric
| Как получить значение метрики, созданной через NamespaceMetric ?
|
How do I get external metrics?
| shell
kubectl get –raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/my-namespace/metrics/my-ns-metric
|
shell
kubectl get –raw /apis/external.metrics.k8s.io/v1beta1
kubectl get –raw /apis/external.metrics.k8s.io/v1beta1/namespaces/d8-ingress-nginx/d8_ingress_nginx_ds_cpu_utilization
| Как получить external-метрики?
|
| shell
kubectl get –raw /apis/external.metrics.k8s.io/v1beta1
kubectl get –raw /apis/external.metrics.k8s.io/v1beta1/namespaces/d8-ingress-nginx/d8_ingress_nginx_ds_cpu_utilization
|
|
|