tencent cloud

容器服务

动态与公告
产品动态
公告
产品发布记录
产品简介
产品概述
产品优势
产品架构
应用场景
产品功能
基本概念
原生 Kubernetes 名词对照
容器服务高危操作
地域和可用区
开源组件
购买指南
购买指引
购买 TKE 标准集群
购买原生节点
购买超级节点
快速入门
新手指引
快速创建一个标准集群
入门示例
容器应用部署 Check List
集群配置
标准集群概述
集群管理
网络管理
存储管理
节点管理
GPU 资源管理
远程终端
应用配置
工作负载管理
服务和配置管理
组件和应用管理
弹性伸缩
容器登录方式
可观测配置
运维可观测性
成本洞察和优化
调度配置
调度组件概述
资源利用率优化调度
业务优先级保障调度
Qos 感知调度
安全和稳定性
容器服务安全组设置
身份验证和授权
应用安全
多集群管理
计划升级
备份中心
云原生服务指南
云原生 etcd
Prometheus 监控服务
TKE Serverless 集群指南
TKE 注册集群指南
实践教程
集群
Serverless 集群
调度
安全
服务部署
网络
发布
日志
监控
运维
Terraform
DevOps
弹性伸缩
容器化
微服务
成本管理
混合云
AI
故障处理
节点磁盘爆满排障处理
节点高负载排障处理
节点内存碎片化排障处理
集群 DNS 解析异常排障处理
集群 Kube-Proxy 异常排障处理
集群 API Server 网络无法访问排障处理
Service&Ingress 网络无法访问排障处理
Service&Ingress 常见报错和处理
Nginx Ingress 偶现 Connection Refused
CLB Ingress 创建报错排障处理
Pod 网络无法访问排查处理
Pod 状态异常与处理措施
授权腾讯云售后运维排障
CLB 回环问题
API 文档
History
Introduction
API Category
Making API Requests
Elastic Cluster APIs
Resource Reserved Coupon APIs
Cluster APIs
Third-party Node APIs
Relevant APIs for Addon
Network APIs
Node APIs
Node Pool APIs
TKE Edge Cluster APIs
Cloud Native Monitoring APIs
Scaling group APIs
Super Node APIs
Other APIs
Data Types
Error Codes
TKE API 2022-05-01
常见问题
TKE 标准集群
TKE Serverless 集群
运维类
隐患处理
服务类
镜像仓库类
远程终端类
事件类
资源管理类
服务协议
TKE Service Level Agreement
TKE Serverless Service Level Agreement
联系我们
词汇表
文档容器服务实践教程弹性伸缩事件驱动弹性伸缩最佳实践（KEDA）基于 Prometheus 自定义指标的弹性伸缩

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

PDF
聚焦模式
字号
最后更新时间： 2024-12-24 15:55:55

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 只是众多触发器中的一种。

上一篇: 多级服务同步水平伸缩（Workload 触发器）下一篇: 集群弹性伸缩实践

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈