容器服务基于 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: default
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=~"default",destination_workload=~"b"}[1m]))
        threshold: "100" # A服务副本数=ceil(B服务QPS/100)
参考上述配置完成 YAML 文件后，执行以下命令应用 b-scaledobject.yaml 文件：
kubectl apply -f b-scaledobject.yaml
相比 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 地址获取
1. 登录容器服务控制台，选择左侧导航栏中的云原生服务 > Prometheus。
2. 在实例列表里单击实例 ID，在基本信息里的 IPv4 地址即为所需替换的 Prometheus 地址。
﻿
﻿
基于 Prometheus 自定义指标的弹性伸缩

本页目录：

Prometheus 触发器

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

相比 prometheus-adapter 的优势

Prometheus 地址获取
