容器服务基于 Prometheus 自定义指标的弹性伸缩-实践教程-文档中心-腾讯云

Prometheus 触发器
KEDA 支持 prometheus 类型的触发器，即根据自定义的 PromQL 查询到的 Prometheus 指标数据进行伸缩，完整配置参数请参见 KEDA Scalers: Prometheus，本文将给出使用案例。
案例：基于 istio 的 QPS 指标伸缩
如果您使用 istio，业务 Pod 注入了 sidecar，会自动暴露一些七层的监控指标，最常见的是 istio_requests_total，可以通过这个指标计算 QPS。
假设场景是：A 服务需要根据 B 服务处理的 QPS 进行伸缩。配置示例如下：
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: b-scaledobject
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: a # 对 A 服务进行伸缩
  pollingInterval: 15
  minReplicaCount: 1
  maxReplicaCount: 100
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://monitoring-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090 # 替换 Prometheus 的地址
        query: | # 计算 B 服务 QPS 的 PromQL
          sum(irate(istio_requests_total{reporter=~"destination",destination_workload_namespace=~"prod",destination_workload=~"b"}[1m]))
        threshold: "100" # A服务副本数=ceil(B服务QPS/100)
相比 prometheus-adapter 的优势
﻿prometheus-adapter 也支持相同的能力，即根据 Prometheus 中的监控指标数据进行伸缩，但相比 KEDA 的方案有以下不足：
每次新增自定义指标，都要改动 prometheus-adapter  的配置，且改配置是集中式管理的，不支持通过 CRD 管理，配置维护较为繁琐。而 KEDA 方案只需要配置 ScaledObject 或 ScaledJob 这种 CRD，不同业务可以使用不同的 YAML 文件维护，利于配置维护。
prometheus-adapter 的配置语法晦涩难懂，不能直接写 PromQL，需要学习 prometheus-adapter 的配置语法，增加了学习成本，而 KEDA 的 prometheus 配置则非常简单，指标可以直接使用 PromQL 查询语句，简单明了。
prometheus-adapter 仅支持根据 Prometheus 监控数据进行伸缩，而对于 KEDA 来说，Prometheus 只是众多触发器中的一种。
﻿

基于 Prometheus 自定义指标的弹性伸缩

本页目录：

Prometheus 触发器

案例：基于 istio 的 QPS 指标伸缩

相比 prometheus-adapter 的优势