默认qps=5.0、burst=10，是client-go的保守兜底值，易触发429错误；应于调用newforconfig或newmanager前修改config.qps与config.burst，并按副本数、apiserver承载力及apf策略协同调优。
client-go 的 QPS 和 Burst 默认值是多少
默认是 QPS=5.0、Burst=10，定义在 k8s.io/client-go/rest/config.go。这不是“安全值”，而是保守兜底值——实际业务中几乎必然触发 429 Too Many Requests 错误，尤其在批量操作、控制器高频率 reconcile 或多副本轮询时。
怎么改 rest.Config 的 QPS/Burst 才不踩坑
必须在调用 kubernetes.NewForConfig() 之前修改，且需同步适配集群 API Server 的承受能力。常见错误是只调大 QPS 却忽略 Burst 容量，或反过来。
-
QPS应设为预期长期平均请求速率（比如每秒 80 次读写），不能盲目堆高；超过 100 后需确认 API Server 的--max-requests-inflight是否允许 -
Burst是令牌桶容量，建议设为QPS × 2～3（如 QPS=80 → Burst=160～240），确保突发事件（如 node 故障引发 200+ pod 删除）能被短时消化 - 若控制器运行在多副本模式下，所有副本共用同一套限速参数，总流量 ≈ 副本数 × (QPS + Burst)，务必按副本数反向压低单实例配置，否则可能集体触发 APF 排队
- 使用
rest.InClusterConfig()时，直接修改返回的 config 指针即可；用clientcmd.BuildConfigFromFlags()时，同样修改 config 对象，不要新建
controller-runtime 用户怎么配 QPS/Burst
controller-runtime 的 ctrl.NewManager() 内部会透传 rest.Config，所以你不需要绕开它另建 clientset。关键是在传入 config 前就完成修改：
config := ctrl.GetConfigOrDie()
config.QPS = 80
config.Burst = 200
mgr, err := ctrl.NewManager(config, ctrl.Options{
// 其他选项
})
注意：不要在 ctrl.Options 里试图覆盖 QPS/Burst——它们只影响 manager 自身的 event recorder、leader election 等组件，不影响 controller 实际调用资源的 clientset。
为什么改了 QPS/Burst 还是报 429
大概率是没管对地方，或存在隐式 client 复用。排查要点：
- 确认你修改的是最终传给
kubernetes.NewForConfig()或ctrl.NewManager()的那个 config 实例，而不是某个中间拷贝 - 检查是否手动 new 了额外的
rest.Config（比如为 dynamic client 或 metrics client 单独构造），这些都要单独配 - 如果你用了
client-go/dynamic或client-go/discovery，它们也各自持有一个 RESTClient，必须显式传入已修改的 config - 启用 APF（API Priority and Fairness）后，
429可能来自优先级流控队列而非客户端限速，此时需检查 PriorityLevelConfiguration 分配是否合理，而非只调大 client 端参数
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
