📚 课程目录第4章 KEDA内置Scaler概览

4. KEDA 内置 Scaler 概览

KEDA 的核心价值在于其丰富的内置 Scaler 生态。这些 Scaler 封装了与各类数据源（消息队列、监控系统、数据库等）的交互逻辑，使开发者无需编写任何自定义代码即可实现基于外部指标的自动伸缩。本章将系统介绍最常用的内置 Scaler，包括 Prometheus、Kafka、RabbitMQ 以及基于 Kubernetes 资源的 CPU/Memory Scaler。

4.1 内置 Scaler 架构与分类

KEDA 内置 Scaler 遵循统一的接口规范，每个 Scaler 负责从特定数据源拉取指标值，并将其转换为 Kubernetes HPA 可理解的度量。根据数据源类型，内置 Scaler 可分为以下几类：

类别	代表 Scaler	典型场景
消息队列	Kafka, RabbitMQ, Azure Queue, AWS SQS	基于队列深度触发工作负载伸缩
监控系统	Prometheus, Datadog, New Relic	基于自定义业务指标（如 QPS、错误率）伸缩
数据库	PostgreSQL, MySQL, MSSQL, Redis	基于数据库查询结果（如待处理订单数）伸缩
Kubernetes 资源	CPU, Memory	基于 Pod 资源使用率的传统 HPA 场景
HTTP/网络	HTTP (add-on), Nginx, Couchbase	基于 HTTP 请求速率或连接数伸缩

选择建议： 消息队列 Scaler 适用于异步处理工作负载；Prometheus Scaler 适合已有监控体系且需要自定义业务指标的场景；CPU/Memory Scaler 则作为基础资源保障，通常与其他 Scaler 组合使用。

4.2 Prometheus Scaler

Prometheus Scaler 是 KEDA 中最灵活、使用最广泛的内置 Scaler 之一。它允许你直接使用 PromQL 查询 Prometheus 实例，将查询结果作为伸缩依据。

核心配置参数

参数	必填	说明
`serverAddress`	是	Prometheus 服务器地址，如 `http://prometheus.monitoring:9090`
`query`	是	PromQL 查询语句，返回单个标量值或瞬时向量
`threshold`	是	触发伸缩的目标阈值
`namespace`	否	限定查询的命名空间，用于多租户场景

典型配置示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prometheus-scaledobject
spec:
  scaleTargetRef:
    name: my-app
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      query: |
        sum(rate(http_requests_total{job="my-app"}[2m]))
      threshold: "100"
      activationThreshold: "10"

  关键点： activationThreshold 用于定义激活阈值，只有当指标值超过此值时 Scaler 才开始工作，避免在低负载时频繁从 0 伸缩到 1。

4.3 Kafka Scaler

Kafka Scaler 专为 Apache Kafka 消费者组设计，它监控指定主题的消费者滞后（Consumer Lag），即消息生产速率与消费速率之间的差值。

工作原理

Kafka Scaler 通过连接 Kafka 集群的 Broker，获取指定主题分区的当前偏移量和消费者组已提交的偏移量，计算每个分区的滞后值，然后取所有分区的最大滞后值作为伸缩指标。

核心配置参数

参数	必填	说明
`bootstrapServers`	是	Kafka 集群地址，多个地址用逗号分隔
`topic`	是	要监控的主题名称
`consumerGroup`	是	消费者组名称
`lagThreshold`	是	触发伸缩的滞后阈值

配置示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
spec:
  scaleTargetRef:
    name: kafka-consumer
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka-cluster:9092
      topic: orders
      consumerGroup: order-processors
      lagThreshold: "50"

4.4 RabbitMQ Scaler

RabbitMQ Scaler 支持两种模式：队列长度模式和未确认消息模式。它通过 RabbitMQ Management HTTP API 获取队列状态。

两种模式对比

模式	指标含义	适用场景
队列长度	队列中待处理的消息总数	消息积压明显，需要快速扩容处理
未确认消息	已投递但消费者未确认的消息数	消费者处理缓慢，需要增加消费者实例

配置示例（队列长度模式）

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-scaledobject
spec:
  scaleTargetRef:
    name: rabbitmq-consumer
  triggers:
  - type: rabbitmq
    metadata:
      protocol: amqp
      host: amqp://guest:password@rabbitmq:5672/vhost
      queueName: task_queue
      mode: QueueLength
      value: "30"

安全注意： 在生产环境中，RabbitMQ 连接字符串中的密码应通过 envFrom 或 secretKeyRef 引用 Kubernetes Secret，避免明文暴露。

4.5 CPU / Memory Scaler

CPU 和 Memory Scaler 是 KEDA 对原生 Kubernetes HPA 的封装，它们的行为与标准 HPA 完全一致，但允许你在 ScaledObject 中统一管理所有触发器。

与原生 HPA 的差异

特性	原生 HPA	KEDA CPU/Memory Scaler
配置位置	独立的 HPA 资源	作为 ScaledObject 的触发器之一
多指标组合	支持，但配置较复杂	与外部 Scaler 无缝组合
冷却行为	使用默认冷却时间	可配置 `cooldownPeriod` 和 `pollingInterval`

配置示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
spec:
  scaleTargetRef:
    name: my-app
  triggers:
  - type: cpu
    metadata:
      type: Utilization
      value: "80"
  - type: memory
    metadata:
      type: Utilization
      value: "70"

4.6 内置 Scaler 选择决策流程

以下 SVG 图展示了在实际项目中如何根据数据源类型和业务需求选择合适的内置 Scaler：

4.7 多 Scaler 组合策略

KEDA 允许在同一个 ScaledObject 中配置多个触发器，系统会取所有触发器中建议的最大副本数作为最终目标。这种组合策略在以下场景中尤为有效：

资源 + 业务指标： 同时配置 CPU Scaler 和 Prometheus Scaler，确保在业务流量激增时快速扩容，同时在资源空闲时缩容。
多队列监控： 为同一个工作负载配置 Kafka Scaler 和 RabbitMQ Scaler，处理来自不同消息源的任务。
主备指标： 配置两个 Prometheus Scaler 查询不同的指标，当主指标不可用时，备指标仍能驱动伸缩。

  最佳实践： 组合多个 Scaler 时，务必为每个 Scaler 设置合理的 activationThreshold，避免因某个指标的微小波动导致不必要的伸缩。同时，建议设置 cooldownPeriod 为 60-120 秒，防止频繁伸缩。

4.8 本章小结

KEDA 内置 Scaler 覆盖了从基础设施资源到业务指标的广泛场景。Prometheus Scaler 提供了最大的灵活性，适合自定义业务指标；Kafka 和 RabbitMQ Scaler 专为消息驱动架构设计；CPU/Memory Scaler 则作为基础资源保障。掌握这些内置 Scaler 的配置和组合方式，是后续开发自定义 Scaler 的重要基础。