📚 课程目录第3章 ScaledObject基础

ScaledObject 基础：CRD 介绍、YAML 结构与核心配置

ScaledObject 是 KEDA 的核心自定义资源（CRD），它定义了“何时”以及“如何”对工作负载进行自动缩放。本章将深入解析 ScaledObject 的 YAML 结构、触发器配置与副本数设定，为后续事件源集成与容量规划打下坚实基础。

3.1 ScaledObject CRD 介绍

ScaledObject 作为 Kubernetes 的扩展资源，其本质是一个 CRD（Custom Resource Definition）。它充当了事件源与 Kubernetes HPA（Horizontal Pod Autoscaler）之间的桥梁。当 ScaledObject 被创建时，KEDA 会自动生成一个对应的 HPA 对象，并根据配置的触发器指标动态调整工作负载的副本数。

  核心职责： 监听外部事件源（如 Kafka、RabbitMQ、Prometheus）的指标 → 将指标转换为 HPA 可理解的格式 → 驱动 HPA 调整 Deployment/StatefulSet 的副本数。

3.2 ScaledObject YAML 结构

一个标准的 ScaledObject YAML 包含四个主要部分：scaleTargetRef（目标工作负载）、triggers（事件源触发器）、minReplicaCount / maxReplicaCount（副本范围）以及 advanced（高级恢复与冷却策略）。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicaCount: 1
  maxReplicaCount: 10
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        metricName: http_requests_total
        query: sum(rate(http_requests_total[1m]))
        threshold: '100'
  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 60

3.3 触发器（Trigger）配置详解

触发器是 ScaledObject 的灵魂，它定义了从何处获取指标以及如何判断是否需要缩放。KEDA 支持 50+ 种事件源，每种都有其特定的 metadata 字段。以下为三种最常用的触发器配置示例：

触发器类型	典型场景	关键 Metadata 字段
prometheus	基于自定义业务指标（如 QPS、错误率）	`serverAddress`, `query`, `threshold`
kafka	基于 Kafka 主题的消费者滞后（lag）	`bootstrapServers`, `topic`, `lagThreshold`
rabbitmq	基于 RabbitMQ 队列中的消息数量	`host`, `queueName`, `mode`, `value`

多触发器组合： 一个 ScaledObject 可以包含多个触发器。KEDA 会取所有触发器中计算出的最大期望副本数作为最终目标，确保系统不会因单一指标误判而缩容。

3.4 最小/最大副本数设置

minReplicaCount 和 maxReplicaCount 定义了工作负载的缩放边界，是容量规划的核心参数。

minReplicaCount（默认值：1）：即使没有事件触发，也至少保持的副本数。用于保证基础吞吐量与冷启动延迟的平衡。
maxReplicaCount（默认值：100）：允许扩展到的最大副本数。用于防止资源耗尽或成本失控。
特殊值 0：当 minReplicaCount: 0 时，KEDA 允许将工作负载缩零，实现真正的 Serverless 体验。但需配合 scaleTargetRef 的 apiVersion 支持（如 Deployment 需启用 scale-to-zero 特性）。

容量规划陷阱： 设置 maxReplicaCount 时，务必结合集群总资源配额与单个 Pod 的资源请求（requests）。例如，若单个 Pod 请求 2 核 CPU，maxReplicaCount 设为 50，则峰值需预留 100 核，否则 HPA 将因资源不足而无法扩容。

3.5 ScaledObject 与 HPA 的协作流程

下图展示了 ScaledObject 如何将外部事件源指标转化为 HPA 的缩放决策：

3.6 高级配置：冷却与恢复策略

除了基础配置，advanced 字段提供了精细化的缩放行为控制，避免频繁抖动：

cooldownPeriod（默认值：300 秒）：在最后一次触发指标低于阈值后，等待多久才执行缩容操作。适用于应对突发流量尖峰后的稳定期。
pollingInterval（默认值：30 秒）：KEDA 从事件源拉取指标的频率。频率越高，响应越快，但会增加事件源负载。
restoreToOriginalReplicaCount：当 ScaledObject 被删除时，是否将工作负载副本数恢复为原始值（即创建 ScaledObject 前的副本数）。
horizontalPodAutoscalerConfig.behavior：直接透传 HPA 的 behavior 字段，用于自定义扩容/缩容的速率限制与稳定窗口。

  生产建议： 对于延迟敏感型服务，建议将 pollingInterval 设为 10-15 秒，cooldownPeriod 设为 60-120 秒。对于批处理任务，可适当增大间隔以减少 API 调用开销。

3.7 多触发器与副本数计算逻辑

当 ScaledObject 配置了多个触发器时，KEDA 会为每个触发器独立计算一个期望副本数，然后取其中的 最大值 作为最终目标。这种“取最大值”策略确保了系统不会因为某个指标暂时正常而忽略其他关键指标。

这种设计确保了系统的鲁棒性：即使某个触发器因配置错误而返回 0，其他触发器仍能正常驱动扩容，避免服务过载。