3. ScaledObject 详解:核心 CRD 与关键配置
ScaledObject 是 KEDA 中定义自动缩放策略的核心自定义资源(CRD)。它告诉 KEDA 要监控哪个事件源、缩放哪个工作负载(如 Deployment)、以及缩放行为的边界与频率。本章将深入解析 ScaledObject 的完整定义、触发器配置、副本数边界以及轮询与冷却参数。
3.1 ScaledObject CRD 定义
一个典型的 ScaledObject 资源包含以下核心字段:
| 字段路径 | 类型 | 说明 |
|---|---|---|
scaleTargetRef |
object | 指定要缩放的工作负载(name、apiVersion、kind) |
triggers |
array | 事件源触发器列表,定义监控指标来源 |
minReplicaCount |
integer | 最小副本数(默认 0) |
maxReplicaCount |
integer | 最大副本数(默认 100) |
pollingInterval |
integer | 轮询事件源的间隔(秒,默认 30) |
cooldownPeriod |
integer | 缩容冷却期(秒,默认 300) |
advanced |
object | 高级配置,如恢复策略、缩放修饰器 |
关键点: ScaledObject 通过
scaleTargetRef 与工作负载解耦,一个 ScaledObject 只能关联一个工作负载,但可以配置多个触发器。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: rabbitmq-consumer-scaledobject
spec:
scaleTargetRef:
name: consumer-deployment
apiVersion: apps/v1
kind: Deployment
triggers:
- type: rabbitmq
metadata:
queueName: orders
host: amqp://guest:guest@rabbitmq.default.svc:5672
queueLength: "10"
minReplicaCount: 1
maxReplicaCount: 20
pollingInterval: 15
cooldownPeriod: 120
3.2 触发器(Trigger)配置
触发器是 ScaledObject 的核心,它定义了 KEDA 从哪个事件源获取指标。每个触发器包含 type 和 metadata 两个主要部分。
3.2.1 触发器类型
KEDA 支持 50+ 种事件源触发器,常见类型包括:
- 消息队列: RabbitMQ、Kafka、AWS SQS、Azure Queue、Redis Streams
- 数据库: PostgreSQL、MySQL、MongoDB、Cassandra
- HTTP: Prometheus、Metrics API、External
- 云服务: AWS CloudWatch、Azure Monitor、GCP Stackdriver
- 自定义: External、Kubernetes Workload
3.2.2 触发器元数据
每个触发器类型都有特定的元数据字段。以 RabbitMQ 为例:
| 元数据字段 | 说明 | 示例值 |
|---|---|---|
queueName |
队列名称 | orders |
host |
RabbitMQ 连接地址 | amqp://guest:guest@rabbitmq:5672 |
queueLength |
触发缩放的队列长度阈值 | 10 |
protocol |
协议类型(amqp / http) | amqp |
最佳实践: 将敏感信息(如连接字符串)存储在 Kubernetes Secret 中,通过
valueFrom 引用,避免明文暴露。
triggers:
- type: rabbitmq
metadata:
queueName: orders
queueLength: "10"
authenticationRef:
name: rabbitmq-auth # 引用外部认证资源
3.3 minReplicaCount 与 maxReplicaCount
这两个参数定义了缩放边界,防止工作负载过度缩放或缩到零。
| 参数 | 默认值 | 作用 | 典型场景 |
|---|---|---|---|
minReplicaCount |
0 | 保证至少运行的副本数 | 关键服务至少保留 1 个副本 |
maxReplicaCount |
100 | 限制最大副本数,防止资源耗尽 | 根据集群容量设置上限 |
注意: 当
minReplicaCount 设置为 0 时,如果队列为空且冷却期结束,KEDA 会将工作负载缩到 0 副本。这可以节省资源,但首次请求会有冷启动延迟。
3.4 pollingInterval 与 cooldownPeriod
这两个时间参数控制 KEDA 的缩放节奏,直接影响系统的响应速度和稳定性。
3.4.1 pollingInterval(轮询间隔)
定义 KEDA 每隔多少秒检查一次事件源指标。默认 30 秒。
- 值越小: 响应越快,但增加事件源和 KEDA 的负载
- 值越大: 减少开销,但缩放延迟增加
- 推荐范围: 5-60 秒,根据业务敏感度调整
3.4.2 cooldownPeriod(冷却期)
定义在最后一次触发缩放后,KEDA 等待多少秒才执行缩容操作。默认 300 秒。
- 作用: 防止指标抖动导致频繁缩容/扩容
- 值越小: 缩容更快,但可能因短暂波动误缩
- 值越大: 更稳定,但资源释放延迟
- 推荐范围: 60-600 秒,根据业务波动特性调整
校准原则: pollingInterval 决定“多快发现需要扩容”,cooldownPeriod 决定“多快确认可以缩容”。两者配合使用,形成缩放节奏。
3.5 参数配置对比与建议
| 场景 | pollingInterval | cooldownPeriod | minReplicaCount | maxReplicaCount |
|---|---|---|---|---|
| 实时消息处理 | 5-10 秒 | 60-120 秒 | 1 | 50 |
| 批处理任务 | 30-60 秒 | 300-600 秒 | 0 | 20 |
| Web API 响应 | 15-30 秒 | 120-300 秒 | 2 | 100 |
| 成本敏感型 | 30-60 秒 | 300-600 秒 | 0 | 10 |
实战建议: 在生产环境中,先使用默认值运行一段时间,观察缩放行为后再逐步调优。重点关注队列积压趋势和 Pod 启动时间,找到最适合业务节奏的参数组合。