client-go默认限流器（QPS=5，Burst=10）不适用生产场景，因全局共享、无法感知后端负载、混用读写请求；应手动配置独立RateLimiter并确保SharedInformer、DynamicClient等统一使用。
为什么 client-go 的默认限流器经常不够用
Kubernetes API Server 对请求有严格的速率限制（比如 qps 和 burst），client-go 默认用的 rest.DefaultQPS（5）和 rest.DefaultBurst（10）只适合轻量运维脚本。真实场景里，批量 List+Watch 资源、多 goroutine 并发调协、或对接 CI/CD 频繁更新 ConfigMap，很容易触发 429 Too Many Requests 错误。
- 默认限流器是全局共享的，所有
RESTClient实例共用同一套桶，改一个地方影响全部 - 它不感知后端实际负载，比如集群扩容后 API Server 能力变强，但 client-go 还卡在 5 QPS
- Watch 请求和普通 List 请求混在同一限流器下，而 Watch 是长连接、低频心跳，不该挤占 List 的额度
怎么给不同 client 或操作类型配独立限流器
核心是绕过 rest.InClusterConfig() 或 rest.Config 的默认构造，手动注入自定义的 RateLimiter：
- 用
rate.NewLimiter(rate.Limit(qps), burst)创建新限流器，别直接改config.QPS和config.Burst—— 那俩字段在 client-go v0.22+ 后已被标记为只读，改了也不生效 - 把限流器塞进
config.RateLimiter字段，再传给kubernetes.NewForConfig() - 如果要区分读写：给写操作（Create/Update/Delete）单独建 client，配更低
qps（比如 2），读操作（List/Get）可设高些（比如 10）
cfg, _ := rest.InClusterConfig() cfg.RateLimiter = rate.NewLimiter(rate.Limit(10), 20) clientset, _ := kubernetes.NewForConfig(cfg)
注意：rate.Limiter 不是线程安全的，但 client-go 内部会加锁调用，你不用额外同步。
Watch 场景下怎么避免被断连重试压垮 API Server
Watch 本身不走标准限流路径，但它的初始 List 请求和后续重连的 List 请求会被限流器拦截。一旦因限流失败，client-go 会按指数退避重试（BackoffManager），反而造成雪崩式请求堆积。
立即学习“go语言免费学习笔记（深入）”；
- 关键动作：把 Watch 的初始 List 拆出来，用一个宽松限流器（比如
qps=1,burst=5），Watch 连接建立后就不再受此限流器约束 - 设置
config.TimeoutSeconds = 30，避免 Watch 因超时频繁重建 - 在
WatchOption里加resourceVersion=""（空字符串）强制从当前最新版本开始，减少 List 全量扫描压力
listOptions := metav1.ListOptions{
Watch: true,
ResourceVersion: "0", // 从当前最新开始，不是从头
}
RateLimiter 替换后为啥还是收到 429
常见原因不是限流器没生效，而是你漏掉了几个隐式请求来源：
-
SharedInformer底层也走同一个RESTClient，它自己会高频 List+Watch，必须确保传给NewSharedInformerFactory的 client 已配置好限流器 -
DynamicClient（dynamic.NewForConfig()）用的是另一套 config，得单独配一遍 - 自定义 CRD 的 client 如果是用
controller-runtime，它的Manager默认不继承 client-go 的限流配置，得显式传cache.Options{Scheme: scheme, SyncPeriod: ...}并检查底层 client 是否已替换
最稳的做法：所有 client 实例都从同一个配好 RateLimiter 的 *rest.Config 构造，别混用 InClusterConfig() 和手动构造的 config。
限流不是越狠越安全，关键是让失败可预期、可追踪。API Server 的 429 响应头里带 Retry-After，client-go 会自动读取并延迟重试，但前提是你的限流器没把它提前拦在本地。
