这是一个BUG报告还是功能请求？
取消注解其中一个，并单独放在一行：
/kind bug
/kind feature
发生了什么？
当前pod自动扩缩控制器的实现基本上是通过瞬时观察到的指标值计算所需的副本数，然后将其与当前副本数进行比较，并通过差值进行实际的缩放。这可能会导致一些副作用，尤其是当指标值随着时间的推移而频繁变化时。这也可能对某些服务的ok-rate或性能产生潜在影响。
个人认为，引入EMA(exponential moving average)并在控制器中存储一小段时间序列指标可以帮助解决这个问题。它也被Jenkins用于计算负载统计数据：
关于Exponential Smoothing的一些介绍：
https://en.wikipedia.org/wiki/Exponential_smoothing
Jenkins的前身：https://github.com/kohsuke/jenkins/blob/55203ebeed1b7e182878d3e3c1184ac042f20473/core/src/main/java/hudson/slaves/NodeProvisioner.java#L727
我们可以添加类似于autoscaling.kubernetes.io/ema-decay: 0.5的注解，表示EMA的衰减系数。每个自动扩缩器可能有自己的衰减，如果没有这个注解，那么我们应该将衰减默认设置为0,以使其与当前逻辑兼容。
我们需要了解其他什么信息吗？:
环境:
- Kubernetes版本(使用
kubectl version): - 云提供商或硬件配置：
- OS(例如来自/etc/os-release):
- 内核(例如
uname -a): - 安装工具：
- 其他：
9条答案
按热度按时间uqcuzwp81#
/sig autoscaling
8ftvxx2r2#
@kubernetes/sig-autoscaling-feature-requests
Any comment will be appreciated :)
x8diyxa73#
我同意频繁更改跟踪输入信号噪声的推荐是不好的做法。
在我做出这些更改后，自动缩放器将：
@DirectXMan12正在尝试使用https://zh.wikipedia.org/wiki/PID_控制器#伪代码。我认为它针对的是类似的问题。
我认为最好在SIG autoscaling会议上讨论这个问题，以制定解决此问题的计划。
m1m5dgzv4#
是的。我对此进行了更多的思考。我不认为PID控制器能完全解决这个问题(经过一些实验后),但我认为像移动平均值，或者考虑一阶和二阶导数可能会有帮助(它现在正在变化多少，以及这种变化速率有多稳定)。我有一些非常松散的想法。我认为我们可能需要在SIG中开启一个基于CRD的下一代自动扩展器的子项目。
其中一个技巧是让它对普通用户来说足够简单/易懂。
im9ewurl5#
我认为我们可能需要在SIG中开展一个基于CRD的下一代自动扩缩容器实验的子项目。
听起来不错。如果我们能为自动扩缩容器提供一个轻量级的预演框架，那么我们就可以测试自动扩缩容器在接收各种“样式”的指标时的行为。
xbp102n06#
问题在90天不活跃后过期。
使用
/remove-lifecycle stale将问题标记为新鲜。过期的问题在30天不活跃后开始腐烂并最终关闭。
如果现在可以安全地关闭此问题，请使用
/close进行操作。向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
生命周期：过期
a5g8bdjr7#
/remove-lifecycle stale
6bc51xsx8#
问题在90天不活跃后过期。
使用
/remove-lifecycle stale将问题标记为新鲜。过期的问题在30天不活跃后开始腐烂并最终关闭。
如果现在可以安全地关闭此问题，请使用
/close进行操作。向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
生命周期：过期
u59ebvdq9#