参考文档1：
https://juejin.cn/post/6858058420453539853
问题
关于requeue 事件：
- 这些事件的处理时间间隔是不是会持续增加？
- 如果持续增加，最大会有多长？
- 这样持续的事件处理会不会影响到controller性能？
- 当集群中事件数量规模扩大时会不会冲刷掉正常的请求？
先看 结论
-
事件被再处理的时间间隔确实会逐渐增加，并且影响因素主要有两个，一是位于wait.Until中的抖动参数，二是ItemExponentialFailureRateLimiter限流器中的幂指数延迟时间。
-
有最大值限制，最大的时间间隔是1000s。并且当达到最大时间间隔后，后面会稳定为最大值。
-
controller中使用了令牌桶来限流，最大处理能力是10qps。当请求数量超限时，controller会存在性能问题，请求响应时间会增加。
-
当前能想到的处理方法是更改限速器参数配置或者增加controller中worker的数量 。
最小堆和优先队列可以保证每个请求按时间上的先后顺序被处理。当请求规模扩大时，理论上只要资源充足，不会出现丢请求的状况。
再说下我观察到过的实际情况
- 见过 requeue只有两次的情况，kube-ovn nat gw pod 并不会再被继续处理
- 也见过 requeue在 3s 内 requeue 8次的情况，自定义crd 也不会继续被处理
- 也见过requeue 18次的情况， 自定义crd 不会再继续被处理
image.png
时间上确实有放大。
对照：
对照指定不存在的vpc subnet 创建 pod，可以看到 pod 始终都在重试
image.png
可以看到即使在目前，已经重试了74次，最近的重试时间跨度为20s， 所以目前认为nat gw pod的requeque逻辑应该是有一定问题的
确认并修复以下相关资源
. nat-gw-pod 创建失败的requeque情况
. nat-gw-pod route init 的requeue
. vip requeque的情况 目前正常 ，正常的情况如下
. eip requeque的情况
. fip requeque的情况
. dnat requeque的情况
. snat requeque的情况
自定义crd 和 pod 的backoff 逻辑有一定的区别
可以看到
image.png
在重试200+的时候，pod 仍能保持在20s 重试一次的频率
但是
1. 自定义crd vip
image.png
自定义crd的延时重试的，延时增加的很快， 很快应该就会逼近1000s。观察到达1000s后是否会继续重试
image.png
确认会继续重试
2. 自定义 crd eip
和 vip一样，正常
image.png
3. 自定义 crd fip
和 vip一样，正常
image.png
4. 自定义 crd snat
正常
image.png
4. 自定义 crd dnat
正常
image.png
问题
如果，真的观察到requeue的次数不够，比如没达到1000s就不再重试了，或者达到1000s后 也不再重试了， 那么影响因素有哪些？
网友评论