📚 课程目录第2章 ScaledObject核心概念

ScaledObject 基础：核心结构与参数配置

ScaledObject 是 KEDA 中定义自动扩缩容规则的核心 CRD（Custom Resource Definition）。它告诉 KEDA 要监控哪个事件源、如何根据事件源指标计算副本数、以及扩缩容的边界与行为。理解 ScaledObject 的 YAML 结构是配置 Serverless 平台瓶颈参数的第一步。

2.1 ScaledObject YAML 结构

一个完整的 ScaledObject 定义包含四个主要部分：目标工作负载（scaleTargetRef）、事件源触发器（triggers）、副本数边界（minReplicaCount / maxReplicaCount）、行为控制参数（pollingInterval / cooldownPeriod）。以下是一个典型示例：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaledobject
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-processor
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
  - type: rabbitmq
    metadata:
      queueName: orders
      queueLength: "10"
      host: amqp://guest:guest@rabbitmq-svc:5672
  - type: prometheus
    metadata:
      serverAddress: http://prometheus-svc:9090
      metricName: http_requests_total
      threshold: "100"
      query: sum(rate(http_requests_total[2m]))

  结构要点：scaleTargetRef 指向被扩缩容的 Kubernetes 资源（Deployment/StatefulSet/CustomResource）；triggers 数组支持同时配置多个事件源，KEDA 会取所有触发器的最大值作为目标副本数。

2.2 triggers 字段详解

triggers 是 ScaledObject 的核心，它定义了 KEDA 从哪个事件源拉取指标以及如何判断是否需要扩缩容。每个 trigger 包含 type 和 metadata 两个必填字段。

字段	类型	说明	示例值
type	string	事件源类型，KEDA 内置 50+ 种 scaler	rabbitmq, prometheus, kafka, cron
metadata	map[string]string	事件源连接参数与阈值配置	queueName: orders, queueLength: "10"
authenticationRef	object	引用 TriggerAuthentication 或 ClusterTriggerAuthentication	name: rabbitmq-auth
metricType	string	指标聚合方式：AverageValue / Value / Utilization	AverageValue

最佳实践：当使用多个 trigger 时，KEDA 会计算每个 trigger 建议的副本数，最终取最大值。例如 RabbitMQ 建议 5 个副本、Prometheus 建议 8 个副本，则最终目标副本数为 8。

2.3 minReplicaCount 与 maxReplicaCount 配置

这两个参数定义了扩缩容的上下边界，是防止资源浪费和突发流量冲击的关键屏障。

minReplicaCount：最小副本数，默认值为 0。设置为 0 时，如果事件源无负载，KEDA 会将工作负载缩容到 0 个 Pod（需要配合 clusterrole 权限）。
maxReplicaCount：最大副本数，默认值为 100。建议根据集群资源配额和下游系统承载能力设置合理上限。

# 典型配置：允许缩零，但限制最大副本数
spec:
  minReplicaCount: 0
  maxReplicaCount: 50

# 生产环境：保留至少 2 个 Pod 应对突发
spec:
  minReplicaCount: 2
  maxReplicaCount: 30

注意：minReplicaCount 设置为 0 时，KEDA 需要额外的 RBAC 权限才能删除 Deployment 的副本到 0。如果集群未配置，建议至少保留 1 个副本以避免冷启动延迟。

2.4 pollingInterval 与 cooldownPeriod

这两个时间参数控制 KEDA 的指标采集频率和缩容等待时间，直接影响系统的响应速度和稳定性。

参数	默认值	单位	作用	推荐场景
pollingInterval	30	秒	KEDA 每隔多少秒拉取一次事件源指标	实时性要求高：10-15s；批处理：60-120s
cooldownPeriod	300	秒	指标低于阈值后，等待多久才开始缩容	流量波动大：60-120s；稳定负载：300-600s

# 快速响应配置：适合秒级波动的消息队列场景
spec:
  pollingInterval: 15
  cooldownPeriod: 60

# 保守配置：适合长周期批处理任务
spec:
  pollingInterval: 60
  cooldownPeriod: 600

  性能影响：pollingInterval 过短会增加事件源（如数据库、消息队列）的查询压力；cooldownPeriod 过短可能导致频繁缩容/扩容震荡（thrashing）。建议根据业务负载曲线逐步调优。

2.5 参数配置对比速查表

参数	默认值	最小值	最大值	典型生产值
pollingInterval	30s	1s	无上限	15-30s
cooldownPeriod	300s	0s	无上限	60-180s
minReplicaCount	0	0	无上限	1-3
maxReplicaCount	100	1	无上限	20-50

生产配置建议：对于消息队列类事件源，建议 pollingInterval 设置为 15-20s，cooldownPeriod 设置为 60-120s，minReplicaCount 保留 1-2 个 Pod 避免冷启动，maxReplicaCount 根据下游处理能力设置上限。