KEDA中scaling-modifier触发fallback时副本数波动问题分析

问题背景

在Kubernetes自动扩展工具KEDA中，当使用scaling-modifier功能时，如果其中一个scaler出现错误触发fallback机制，目标pod的副本数会出现异常波动现象，而不是稳定保持在fallback设定的值上。这个问题在KEDA 2.13.1版本中被发现并报告。

问题现象

正常情况下，当scaler出现错误时，系统应该将pod副本数稳定维持在用户配置的fallback值上。但实际观察到的现象是，副本数会在1和fallback值之间不断波动，导致系统稳定性受到影响。

技术分析

根本原因

经过深入分析，发现问题主要出在两个方面：

1. metrics提供机制：当没有fallback时，系统会提供一个复合metric；但当fallback触发时，系统却提供了分离的metrics，且这些metric值不等于fallback值。这些错误的metrics会触发HPA将副本数缩放到1。

2. fallback计算逻辑：在doFallback()函数中存在一个关键bug，当scaling-modifier激活时，metricSpec.External.Target.AverageValue会变为0，导致无法正确计算fallback值。正确的做法应该是使用scaledObject.Spec.Advanced.ScalingModifiers.Target。

更深层次的问题

进一步分析发现，当用户设置了failureThreshold时，问题会更加复杂：

1. 在失败次数达到阈值前，doFallback()不会被调用
2. 系统会继续向HPA提供错误的metrics
3. 同时KEDA会尝试将目标缩放到fallback值
4. 这导致副本数在错误值和fallback值之间持续波动，直到失败次数超过阈值

解决方案建议

针对这个问题，建议从以下几个方面进行修复：

1. metrics提供机制：确保在fallback情况下仍然提供正确的复合metric，其值应该等于fallback值。

2. fallback计算逻辑：修改doFallback()函数，在scaling-modifier激活时使用正确的scaledObject.Spec.Advanced.ScalingModifiers.Target值。

3. failureThreshold处理：重新评估failureThreshold在复合scaler场景下的作用机制，可能需要调整错误报告策略，确保在达到阈值前也能提供合理的metrics。

技术影响

这个问题如果不解决，会对生产环境产生以下影响：

1. 系统稳定性：pod副本数的持续波动会导致服务可用性下降
2. 资源利用率：频繁的扩缩容会造成资源浪费
3. 监控告警：异常的副本数变化可能触发误报

最佳实践建议

在使用KEDA的scaling-modifier功能时，建议：

1. 仔细测试fallback机制在各种错误场景下的行为
2. 暂时避免同时使用scaling-modifier和failureThreshold
3. 密切关注pod副本数的变化趋势
4. 考虑在关键生产环境升级到修复后的版本

这个问题展示了在复杂自动扩展系统中，各种功能组合可能产生的边缘情况，也提醒我们在设计系统时要充分考虑各种异常场景的处理逻辑。