kubernetes 更新EndpointSlices的批处理延迟使用两个不一致的标志

wfveoks0 于 5个月前发布在 Kubernetes

关注(0)|答案(8)|浏览(121)

发生了什么？
有两个标志 endpointSliceChangeMinSyncDelay 和 endpointUpdatesBatchPeriod ,用于向队列中添加延迟以处理多个后续更新事件。
有关使用 delay 值的 AddAfter() 方法的工作队列的用法参考：
addPod: https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/endpointslice/endpointslice_controller.go#L495
queueServiceForEndpointSlice: https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/endpointslice/endpointslice_controller.go#L484

你期望会发生什么？

预期的行为是在将更改排队到 EndpointSlices 时以一致的方式使用这些标志。
要么对 Services/EndpointSlices 和 Pods 的更改都应该使用 max( endpointSliceChangeMinSyncDelay , endpointUpdatesBatchPeriod ) ,要么应该有非常明确的迹象表明它们为什么没有这样做，以及为什么将 endpointUpdatesBatchPeriod 覆盖到 0 到 1 秒之间的值不会影响对 Services/EndpointSlices 的更改的延迟。

我们如何尽可能最小精确地重现它？

我们还需要了解什么？

/sig scalability

Kubernetes 版本

云提供商

OS 版本

无响应*

安装工具

无响应*

容器运行时(CRI)和版本(如适用)

无响应*

8条答案

按热度按时间

rjee0c151#

cc @mborsz@marseel

赞(0）回复(0）举报 5个月前

ljsrvy3e2#

/sig network
/cc @aojea@robscott

赞(0）回复(0）举报 5个月前

dfty9e193#

嘿，@dlapcevic,看起来endpointSliceChangeMinSyncDelay是由#89438引入的，可能是受到@liggitt或@wojtek-t的启发。我认为这个特定的EndpointSlices触发的更改最小值实现了以下目标：

降低了我们与过期的EndpointSlices同步的可能性
增加了批处理概率
减少了API服务器上的负载

对于可能触发同步的所有更改，强制执行类似的最小值可能是合理的，但我不确定是否有太多先例。值得从sig scalability那里获得一些观点。我认为大多数平台已经将endpointUpdatesBatchPeriod设置为接近1秒的最小值，但我不确定。

赞(0）回复(0）举报 5个月前

k2fxgqgv4#

感谢@robscott的解释。
我想让我们考虑两个问题：

简化配置。
或许可以为所有情况设置一个单一的标志，具有相同的默认值，或者完全解耦EndpointSlice和pod(endpoint)更新延迟。
澄清影响。
对我来说，这种设置方式有些令人困惑。最好能有一些理由或指导原则来解释为什么EndpointSlice更新的默认值是1s,而pod(endpoint)更新的默认值是0,以及它会产生什么样的行为和可扩展性影响(权衡)。
我认为这两个方面都应该对那些对提高EndpointSlice性能感兴趣的K8s用户开放。

赞(0）回复(0）举报 5个月前

6qftjkof5#

/triage accepted

赞(0）回复(0）举报 5个月前

9ceoxa926#

这个问题已经超过一年没有更新了，应该重新进行优先级评估。
你可以：