📚 课程目录第4章 Scaler触发器体系

4. Scaler 触发器体系：Scaler 接口定义、内置 Scaler 分类

KEDA 的弹性伸缩能力核心在于其丰富的 Scaler（触发器） 体系。Scaler 是连接外部事件源与 Kubernetes 工作负载的桥梁，负责采集指标、评估阈值并驱动 HPA 进行扩缩容。本章深入剖析 Scaler 的接口定义、内置分类及协同机制。

4.1 Scaler 接口定义

KEDA 定义了一套标准的 Scaler 接口，所有内置或自定义 Scaler 都必须实现该接口。该接口位于 pkg/scalers 包中，核心方法如下：

// Scaler 接口定义（简化版）
type Scaler interface {
    // 获取当前指标值，返回一个 float64 切片
    GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)

    // 返回 Scaler 的元数据，包括指标名称、目标值等
    GetMetricSpecForScaling(ctx context.Context) []v2beta2.MetricSpec

    // 返回 Scaler 是否处于激活状态（用于空闲回收）
    IsActive(ctx context.Context) (bool, error)

    // 关闭 Scaler，释放资源
    Close(ctx context.Context) error
}

  关键说明：
  GetMetrics：KEDA 的 HPA 每 15 秒（默认）轮询该方法，获取实时指标值。
GetMetricSpecForScaling：定义 HPA 的 targetValue 或 targetAverageValue，决定伸缩阈值。
IsActive：当指标低于阈值时返回 false，KEDA 可将工作负载缩零以节省资源。

4.2 内置 Scaler 分类

KEDA 官方提供了 50+ 内置 Scaler，按事件源类型可分为以下四大类：

分类	典型 Scaler	适用场景
消息队列	Kafka、RabbitMQ、Azure Service Bus、AWS SQS、GCP Pub/Sub、Redis Streams	异步任务处理、事件驱动微服务、流式数据处理
数据库	PostgreSQL、MySQL、MongoDB、Redis、Cassandra、DynamoDB	基于数据库连接数、查询队列深度或缓存命中率的伸缩
HTTP/API	HTTP（自定义 API）、Prometheus、Elasticsearch、InfluxDB、Datadog	基于外部 HTTP 端点、监控系统或日志平台的指标伸缩
云原生/其他	Kubernetes Workload（CPU/Memory）、Cron、Pulsar、NATS JetStream、AWS CloudWatch	定时任务、基础设施指标、混合云事件源

4.3 消息队列 Scaler 详解

消息队列是 KEDA 最常用的 Scaler 类别，其核心逻辑是：队列深度（未消费消息数） 驱动 Pod 数量。以 Kafka Scaler 为例：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
spec:
  scaleTargetRef:
    name: my-consumer-deployment
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: my-cluster-kafka-bootstrap:9092
      topic: my-topic
      consumerGroup: my-group
      lagThreshold: "10"          # 滞后消息数超过 10 则扩容
      offsetResetPolicy: latest

最佳实践： 消息队列 Scaler 通常配合 cooldownPeriod（冷却期）使用，避免频繁扩缩容导致抖动。建议设置 cooldownPeriod: 60（秒）。

4.4 数据库 Scaler 详解

数据库 Scaler 通过查询 SQL 或 NoSQL 数据库中的指标（如连接数、查询队列长度）来触发伸缩。以 PostgreSQL Scaler 为例：

triggers:
- type: postgresql
  metadata:
    connectionStringFromEnv: POSTGRES_CONN_STRING
    query: "SELECT COUNT(*) FROM tasks WHERE status = 'pending'"
    targetValue: "5"   # 待处理任务超过 5 则扩容

注意： 数据库 Scaler 的查询频率不宜过高，建议通过 pollingInterval 控制（默认 30 秒），避免对数据库造成额外压力。

4.5 HTTP/API Scaler 详解

HTTP Scaler 允许从任意 HTTP 端点获取指标，适用于自定义监控系统或第三方 API。其配置灵活，支持 JSONPath 提取指标值：

triggers:
- type: http
  metadata:
    url: "https://api.example.com/metrics/queue-depth"
    valueLocation: "data.queueSize"   # JSONPath 提取
    targetValue: "100"
    authMode: "bearer"
    bearerTokenSecret: my--secret

4.6 Scaler 协同架构

KEDA 的 Scaler 并非孤立工作，而是通过 ScaledObject 控制器统一调度。下图展示了多个 Scaler 协同驱动 HPA 的架构：

4.7 多 Scaler 协同策略

KEDA 支持在同一个 ScaledObject 中配置多个 Scaler，实现 多指标联合伸缩。协同策略如下：

取最大值（默认）：HPA 会选择所有 Scaler 中计算出的最大副本数，确保系统能应对最紧张的事件源。
取最小值：可通过 fallback 策略或自定义 HPA 行为实现，适用于资源敏感场景。
加权平均：高级场景可通过 ScaledObject 的 advanced 字段配合 behavior 实现。

示例： 同时监听 Kafka 队列深度和 PostgreSQL 待处理任务数，取最大值扩容：

spec:
  triggers:
  - type: kafka
    metadata:
      topic: my-topic
      lagThreshold: "10"
  - type: postgresql
    metadata:
      query: "SELECT COUNT(*) FROM tasks WHERE status = 'pending'"
      targetValue: "5"
  # HPA 自动取两个 Scaler 中较大的副本数

4.8 Scaler 选择建议

场景	推荐 Scaler	理由
异步消息处理	Kafka / RabbitMQ	队列深度直接反映负载，响应迅速
数据库密集型任务	PostgreSQL / MySQL	基于连接数或查询队列，避免数据库过载
自定义监控指标	HTTP / Prometheus	灵活接入任意指标源，无需修改应用代码
定时批量任务	Cron	按时间计划伸缩，适合批处理场景

通过合理选择和组合 Scaler，KEDA 能够实现从消息队列到数据库、从 HTTP 端点到云原生服务的全场景事件驱动弹性伸缩，为云原生应用提供精准、高效的自动扩缩容能力。