📚 课程目录第2章 KEDA基础回顾

2. KEDA 基础回顾：架构组件与事件驱动缩放原理

在深入 Serverless 平台容量调优之前，必须牢固掌握 KEDA 的核心架构与工作流。KEDA（Kubernetes Event-Driven Autoscaling）并非替代 HPA，而是作为 事件驱动的触发器，将外部指标（消息队列长度、请求延迟、数据库连接数等）转换为 Kubernetes 可消费的指标，从而驱动 Pod 的弹性伸缩。

2.1 KEDA 架构三大核心组件

KEDA 由三个关键组件构成，它们协同工作，形成从事件源到 Pod 副本数调整的完整链路。

组件	角色	关键职责
Scaler	事件源适配器	连接外部系统（Kafka、RabbitMQ、Prometheus、AWS SQS 等），拉取或接收指标值，并将指标值暴露给 Metric Adapter。
Metric Adapter	指标转换与暴露	实现 Kubernetes 自定义/外部指标 API（`custom.metrics.k8s.io` / `external.metrics.k8s.io`），将 Scaler 获取的指标值转换为 HPA 可识别的格式。
Operator	控制器与协调器	监听 `ScaledObject` / `ScaledJob` CRD 的变化，创建并管理对应的 HPA 对象，并负责激活/空闲状态的切换。

  架构要点： Operator 是大脑，Scaler 是感官，Metric Adapter 是神经。三者缺一不可，任何一环的版本差异都会直接影响容量调优的准确性。

2.2 核心 CRD：ScaledObject 与 ScaledJob

KEDA 通过两个自定义资源定义（CRD）来声明缩放规则，分别对应无状态工作负载（Deployment）和批处理任务（Job）。

2.2.1 ScaledObject

用于定义 Deployment、StatefulSet 或任何支持 /scale 子资源的自定义资源的缩放策略。它指定了目标工作负载、触发器（Scaler 配置）、最小/最大副本数以及冷却/恢复行为。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
spec:
  scaleTargetRef:
    name: my-consumer-deployment  # 目标 Deployment
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
  - type: kafka
    metadata:
      topic: orders-topic
      bootstrapServers: kafka-cluster:9092
      consumerGroup: my-group
      lagThreshold: "100"          # 当积压消息超过 100 条时触发扩容
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 60

2.2.2 ScaledJob

专门用于 Job 类型的工作负载。当事件触发时，KEDA 会创建 Job 实例来处理事件，而不是调整已有 Pod 的副本数。适用于消息处理、数据批处理等场景。

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: event-processor-job
spec:
  jobTargetRef:
    template:
      spec:
        containers:
        - name: processor
          image: my-processor:latest
        restartPolicy: Never
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.region.amazonaws.com/123456789/my-queue
      queueLength: "10"
  maxReplicaCount: 50

版本差异注意点： 在 KEDA v2.8 之前，ScaledJob 不支持 advanced 字段中的 scalingStrategy（如 default、accurate、eager）。v2.8+ 引入了更精细的 Job 创建策略，直接影响批处理场景下的资源利用率。

2.3 事件驱动缩放原理（核心流程）

KEDA 的事件驱动缩放并非直接修改 Deployment 的副本数，而是通过“代理”HPA 的方式实现。其完整工作流如下：

用户创建 ScaledObject： 用户向 Kubernetes API Server 提交 ScaledObject 资源。
Operator 监听并创建 HPA： KEDA Operator 监听到 ScaledObject 事件，根据 ScaledObject 的配置（min/max、触发器）自动创建一个对应的 HPA 对象。该 HPA 的目标指标指向 KEDA 的 Metric Adapter。
Scaler 拉取外部指标： KEDA 内部的 Scaler 组件（如 Kafka Scaler）按照轮询间隔（默认 30 秒）从外部系统拉取指标值（如消费者组滞后量）。
Metric Adapter 暴露指标： Scaler 将指标值传递给 Metric Adapter，Metric Adapter 将其注册到 Kubernetes 的指标 API 中。
HPA 轮询指标并计算： Kubernetes 的 HPA 控制器定期（默认 15 秒）通过 external.metrics.k8s.io API 查询指标值，并根据公式 期望副本数 = ceil(当前副本数 × (当前指标值 / 目标值)) 计算目标副本数。
HPA 调整 Deployment 副本数： HPA 调用 Deployment 的 /scale 子资源，更新 spec.replicas，触发 Pod 的扩容或缩容。

2.4 缩放决策的关键参数

KEDA 的缩放行为并非简单的“指标高就扩容”，而是由多个参数共同控制，这些参数在不同版本中的默认值和行为存在差异。

参数	作用域	说明	版本差异关注点
`pollingInterval`	ScaledObject	Scaler 拉取外部指标的频率（秒）。默认 30 秒。	v2.10+ 支持在 ScaledObject 级别覆盖全局配置。
`cooldownPeriod`	ScaledObject	缩容冷却时间（秒）。默认 300 秒。	v2.7+ 引入 `idleReplicaCount` 后，冷却逻辑发生变化。
`idleReplicaCount`	ScaledObject	空闲时保留的副本数（通常为 0）。v2.7+ 引入。	旧版本无此字段，缩容到 `minReplicaCount` 后停止。
`fallback`	ScaledObject	当指标拉取失败时的回退策略（如回退到指定副本数）。	v2.6+ 支持，早期版本无此机制。
`advanced.horizontalPodAutoscalerConfig.behavior`	ScaledObject	直接透传 HPA 的 `behavior` 配置，控制扩缩容速率。	v2.0+ 支持，但不同 KEDA 版本对 HPA API 版本的兼容性不同。

容量调优陷阱： 在 Serverless 平台上，pollingInterval 和 cooldownPeriod 的默认值往往不适合突发流量场景。例如，默认 300 秒的冷却时间可能导致流量骤降后 Pod 仍然长时间运行，造成资源浪费。后续章节将详细讲解如何针对不同版本调整这些参数。

2.5 Scaler 类型与版本兼容性

KEDA 内置了 50+ 种 Scaler，覆盖主流中间件和云服务。Scaler 的实现细节（如指标计算方式、认证方式）在不同 KEDA 版本中可能存在细微差异，直接影响调优结果。

2.6 版本差异对容量调优的直接影响

理解 KEDA 基础架构后，必须明确：不同 KEDA 版本在以下三个维度上的差异，会直接导致容量调优策略的失效或偏差。

指标计算精度： 某些 Scaler（如 Kafka Scaler）在 v2.8 之前使用 sum 聚合所有分区滞后量，v2.8+ 改为 max 聚合，导致相同指标值下扩容行为不同。
HPA 行为透传： 早期版本（v2.0-v2.3）对 HPA behavior 字段的支持不完整，可能导致自定义扩缩容速率配置失效。
空闲副本处理： v2.7 引入 idleReplicaCount 后，缩容到 0 的行为从“可选”变为“标准”，旧版本需要额外配置才能实现。