无需自定义指标的水平Pod自动缩放

问题描述

我们要根据Kafka主题中的消息量水平缩放Pod.标准解决方案是将指标发布到Kubernetes的自定义指标API.但是，由于公司准则，我们不允许使用Kubernetes的自定义指标API.我们只允许使用非管理员功能.是否有使用kubernetes-nativ功能的解决方案，还是我们需要实施定制的解决方案?

We want to scale our pods horizontally based on the amount of messages in our Kafka Topic. The standard solution is to publish the metrics to the custom metrics API of Kubernetes. However, due to company guidelines we are not allowed to use the custom metrics API of Kubernetes. We are only allowed to use non-admin functionality. Is there a solution for this with kubernetes-nativ features or do we need to implement a customized solution?

推荐答案

我不确定这是否满足您的需求，但是您可以使用在与Kubernetes对象无关的指标上自动缩放.

I'm not exactly sure if this would fit your needs but you could use Autoscaling on metrics not related to Kubernetes objects.

使用外部指标需要您的监控系统知识；该设置类似于使用自定义指标时所需的设置.外部指标允许您根据监视系统中可用的任何指标自动扩展群集.只需提供一个带有name和selector的metric块，如上所述，并使用External度量标准类型而不是Object.如果metricSelector匹配了多个时间序列，则Horizo​​ntalPodAutoscaler将使用它们的值之和.外部指标同时支持Value和AverageValue目标类型，其功能与使用Object类型时完全相同.

Using external metrics requires knowledge of your monitoring system; the setup is similar to that required when using custom metrics. External metrics allow you to autoscale your cluster based on any metric available in your monitoring system. Just provide a metric block with a name and selector, as above, and use the External metric type instead of Object. If multiple time series are matched by the metricSelector, the sum of their values is used by the HorizontalPodAutoscaler. External metrics support both the Value and AverageValue target types, which function exactly the same as when you use the Object type.

例如，如果您的应用程序处理来自托管队列服务的任务，则可以将以下部分添加到Horizo​​ntalPodAutoscaler清单中，以指定每30个未完成的任务需要一个工作线程.

For example if your application processes tasks from a hosted queue service, you could add the following section to your HorizontalPodAutoscaler manifest to specify that you need one worker per 30 outstanding tasks.

- type: External
 external:
   metric:
     name: queue_messages_ready
     selector: "queue=worker_tasks"
   target:
     type: AverageValue
     averageValue: 30

在可能的情况下，最好使用自定义指标目标类型而不是外部指标，因为集群管理员可以更轻松地保护自定义指标API.外部指标API可能允许访问任何指标，因此群集管理员在公开它时应格外小心.

When possible, it’s preferable to use the custom metric target types instead of external metrics, since it’s easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows access to any metric, so cluster administrators should take care when exposing it.

您还可以查看 zalando-incubator/kube-metrics-adapter 并使用Prometheus收集器外部指标.

You may also have a look at zalando-incubator/kube-metrics-adapter and use Prometheus collector external metrics.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
 name: myapp-hpa
 annotations:
   # This annotation is optional.
   # If specified, then this prometheus server is used,
   # instead of the prometheus server specified as the CLI argument `--prometheus-server`.
   metric-config.external.prometheus-query.prometheus/prometheus-server: http://prometheus.my->namespace.svc
   # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
   # <configKey> == query-name
   metric-config.external.prometheus-query.prometheus/processed-events-per-second: |
     scalar(sum(rate(event-service_events_count{application="event-service",processed="true"}[1m])))
spec:
 scaleTargetRef:
   apiVersion: apps/v1
   kind: Deployment
   name: custom-metrics-consumer
 minReplicas: 1
 maxReplicas: 10
 metrics:
 - type: External
   external:
     metric:
       name: prometheus-query
       selector:
         matchLabels:
           query-name: processed-events-per-second
     target:
       type: AverageValue
       averageValue: "10"

这篇关于无需自定义指标的水平Pod自动缩放的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！