一、案例：基于 istio 的 QPS 指标伸缩
如果你使用 istio，业务 Pod 注入了 sidecar，会自动暴露一些七层的监控指标，最常见的是 istio_requests_total，可以通过这个指标计算 QPS。
假设场景是：A 服务需要根据 B 服务处理的 QPS 进行伸缩。配置示例如下：
apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: b-scaledobject namespace: defaultspec: 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 地址。