workqueue 并发数应根据单次处理耗时和积压容忍度反推，如80ms/次、容忍100个积压，则设8–10；需同步调大rest.config.qps/burst防429；限速器按场景选指数退避、tick或令牌桶；必须defer done(key)防panic卡死；多副本需key分片或哈希路由避免争抢。
WorkQueue 并发数到底该设多少？
控制器吞吐量卡在那儿，不是因为逻辑慢，而是 workqueue.NewRateLimitingQueue 的并发消费者太少。Kubernetes 官方示例常写 for i := 0; i ，但这是保守值，不是默认值。
- 实际并发数应基于「单次处理耗时」和「队列积压容忍度」反推：比如平均处理一次对象要 80ms，你希望峰值积压不超过 100 个，则理论最大并发 ≈ 1000ms / 80ms ≈ 12（再留点余量，设 8–10 更稳）
- 不要盲目堆高 goroutine 数：超过 20 后，调度开销、锁竞争（
queue.Get()内部有 mutex）、etcd 请求并发限制反而拖慢整体 - 注意
client-go的rest.Config.QPS和Burst必须同步调大，否则大量429 Too Many Requests错误会把队列“堵死”
RateLimitingQueue 的限速策略怎么选？
默认的 workqueue.DefaultControllerRateLimiter() 是指数退避 + 每秒 10 次突发，适合故障恢复场景，但对高频变更（如 ConfigMap 频繁更新）容易“越压越慢”。
- 短周期高频同步用
workqueue.NewMaxOfRateLimiter(…)组合：比如workqueue.NewItemExponentialFailureRateLimiter(5<em>time.Millisecond, 1000</em>time.Second)配workqueue.NewTickRateLimiter(10 * time.Second, 10)，保证失败项不霸占队列，同时每 10 秒最多重试 10 次 - 纯吞吐优先（如批量 reconcile）可换
workqueue.NewBucketRateLimiter(100, 100)：桶容量 100，每秒补 100 令牌，几乎无延迟 - 切记：所有限速器都只约束
Get()返回速度，不影响Add()；如果上游事件爆炸式涌入（如 node 故障触发 500+ pod 删除），得靠Forget()+Done()及时清理已处理 key，否则内存泄漏
为什么 processNextWorkItem 总是 panic 或漏 reconcile？
常见现象是日志里反复出现 processNextWorkItem: failed to get key from queue: queue is shutting down，或某几个对象永远不再被处理。
- 根本原因常是没做
defer queue.Done(key)—— 一旦处理中 panic，key 就卡在inFlight计数里，后续不会重入队列 - 正确结构必须是：
func (c *Controller) processNextWorkItem() { key, shutdown := c.queue.Get() if shutdown { return } defer c.queue.Done(key) err := c.syncHandler(key) if err == nil { c.queue.Forget(key) return } utilruntime.HandleError(fmt.Errorf("sync %v failed: %v", key, err)) c.queue.AddRateLimited(key) } - 别在
syncHandler里直接调queue.Add()：这会绕过限速器，且可能造成无限循环（如 update 触发自身再次 add）
Controller 共享 informer 时，如何避免多个实例争抢同一对象？
多个副本控制器共用一个 SharedInformer，但 workqueue 是各自独立的，所以 key 冲突本身不致命；真正问题是：谁该处理、谁该跳过？
立即学习“go语言免费学习笔记（深入）”；
- 关键不是锁，而是 key 分片：用
workqueue.NewNamedRateLimitingQueue+ 自定义KeyFunc，例如按 namespace 哈希分到不同子队列，再配不同 worker 数 - 更稳妥的做法是在
syncHandler开头加一层判断：if !c.shouldHandle(key) { return }，其中shouldHandle基于 Pod 名称哈希 % 副本数 == 当前实例序号 - 注意 informer 的
ResyncPeriod默认 10 小时，若你改短（如 30s），大量重复 sync 会冲垮队列；建议保持默认，靠 event 驱动，仅用 resync 做兜底校验
实际跑起来后，最易被忽略的是 etcd 连接复用和 client-go 的 Timeout 设置——超时时间比队列重试间隔还短，就会让一次失败变成多次无效重试。这问题不在队列本身，但在它下游。
