KEDA 2.17.0版本中ScaledObject的fallback功能验证问题解析

在KEDA 2.17.0版本中，用户在使用ScaledObject资源时遇到了一个关键问题：当尝试配置fallback功能时，部署会被验证webhook拒绝。这个问题主要影响使用Redis等外部触发器类型的用户，导致他们无法正常使用fallback机制。

问题背景

KEDA是一个Kubernetes事件驱动的自动扩缩容组件，它通过ScaledObject资源来定义扩缩容规则。fallback功能是KEDA提供的一项重要特性，当外部指标系统不可用时，它可以提供一个备用的扩缩容策略，确保应用能够继续运行。

在2.17.0版本中，验证webhook增加了一个新的检查逻辑：要求所有非CPU/内存类型的触发器必须显式指定metricType为AverageValue，才能启用fallback功能。这个变更原本是为了确保fallback行为的正确性，但在实现过程中出现了一个逻辑缺陷。

问题表现

用户在使用Redis触发器时，即使生成的HPA中确实使用了AverageValue类型（这是Redis触发器的默认行为），部署仍然会被webhook拒绝。错误信息明确指出："至少需要一个非CPU或内存的触发器具有AverageValue类型才能启用fallback"。

这个问题特别影响那些：

1. 使用Redis等外部触发器
2. 配置了fallback策略
3. 但没有显式声明metricType的用户

技术分析

问题的根源在于验证webhook的逻辑判断过于严格。它要求触发器定义中必须显式包含metricType: AverageValue，而忽略了某些触发器（如Redis）默认就会使用AverageValue的事实。

在Kubernetes的HPA v2 API中，External指标类型支持两种目标值类型：

• Value：绝对值
• AverageValue：平均值

对于队列长度等指标，通常使用AverageValue更为合理，这也是Redis等触发器默认采用的方式。但在2.17.0的webhook验证中，这一默认行为没有被正确识别。

解决方案

KEDA团队迅速响应，在2.17.1版本中修复了这个问题。在等待升级期间，用户可以采用以下两种临时解决方案：

1. 显式声明metricType：在每个触发器定义中添加metricType: AverageValue

triggers:
  - type: redis
    metricType: AverageValue
    # 其他配置...

2. 临时禁用webhook验证：在KEDA部署配置中关闭验证webhook（不推荐用于生产环境）

最佳实践

为了避免类似问题，建议用户：

1. 显式声明metricType，即使使用默认值
2. 在升级前充分测试新版本
3. 关注KEDA的发布说明，了解验证规则的变更

总结

这个问题的出现提醒我们，在复杂的Kubernetes生态系统中，验证规则的变更需要全面考虑各种触发器的默认行为。KEDA团队通过快速发布2.17.1版本解决了这个问题，展示了良好的开源响应能力。对于用户来说，及时升级到最新版本是避免此类问题的最佳方式。

通过这次事件，我们也看到KEDA社区活跃的技术支持氛围，用户和开发者之间的良好互动确保了问题的快速定位和解决。