KEDA 中多触发器场景下的容错机制探讨

背景

在 Kubernetes 的自动扩展场景中，KEDA (Kubernetes Event-driven Autoscaling) 是一个广泛使用的组件，它允许用户基于各种事件源来动态扩展工作负载。在实际生产环境中，我们经常会遇到需要同时基于多种指标进行扩展决策的场景，比如同时考虑 CPU 使用率和 Prometheus 自定义指标。

问题现状

当前 KEDA 在处理多个触发器时存在一个明显的局限性：当任何一个触发器失败时，整个 ScaledObject 就会进入不可用状态（Ready: false, Active: false）。这意味着即使其他触发器仍然能够正常工作，自动扩展功能也会完全停止。

这种全有或全无的行为在某些场景下可能过于严格。例如：

• 当 Prometheus 服务暂时不可用时，CPU 指标仍然有效
• 当外部指标服务出现网络问题时，内存指标仍然可用

技术挑战

实现部分触发器失效时的容错机制面临几个技术挑战：

1. 状态管理复杂性：需要明确区分哪些触发器处于活动状态，哪些处于失效状态
2. 决策逻辑变更：当部分触发器失效时，如何确定最终的扩展决策
3. 向后兼容性：确保新功能不会破坏现有部署的行为
4. 配置清晰性：如何直观地表达这种容错行为

解决方案探讨

社区提出的解决方案是在触发器级别引入一个显式的容错配置选项。初步建议如下：

triggers:
  - type: cpu
    metricType: Utilization
    metadata:
      value: "50"
    skipFailing: true  # 新增配置项
  - type: prometheus
    metadata:
      query: rate(my_metric[1m])
      threshold: "3"

关键设计点

1. 配置位置：应该放在触发器规范中，而不是元数据部分
2. 默认行为：保持向后兼容，默认值为 false（即不跳过失败）
3. 与回退机制的关系：当没有配置 skipFailing 的触发器失败时，仍然触发回退机制
4. 状态恢复：当失效的触发器恢复后，应自动重新纳入扩展决策

实现考量

要实现这一功能，需要在 KEDA 控制器中做以下修改：

1. 触发器健康检查：需要单独评估每个触发器的健康状态
2. 决策聚合：修改现有的决策逻辑，只考虑健康的触发器
3. 状态报告：在 ScaledObject 状态中清晰反映哪些触发器被跳过
4. 监控指标：添加相关指标，帮助运维人员了解触发器的健康状态

生产环境建议

对于考虑在生产环境中使用此功能的用户，建议：

1. 明确业务需求：不是所有场景都适合跳过失败的触发器
2. 监控配置：确保有完善的监控来发现被跳过的触发器
3. 逐步采用：先在非关键工作负载上测试此功能
4. 文档记录：清晰记录每个触发器的容错配置及其业务影响

未来展望

这一功能的实现将为 KEDA 用户提供更灵活的自动扩展策略，特别是在混合云和复杂监控环境的场景下。未来还可以考虑：

1. 更细粒度的控制：如基于错误类型决定是否跳过
2. 权重机制：为不同触发器分配不同权重
3. 自动恢复策略：定义触发器自动恢复的条件和行为

通过这样的改进，KEDA 将能够更好地适应生产环境中的各种复杂情况，提供更可靠的自动扩展能力。