应复用单例客户端、使用sharedinformer替代轮询、限制并发与请求频率、精简watch字段和逻辑；避免高频list/watch、重复建客户端、阻塞回调及未过滤的全量事件处理。
Go 语言本身性能足够好，但 Kubernetes 客户端（client-go）使用不当会成为服务性能瓶颈——尤其是高频 List/Watch、未限流的并发请求、或反复重建客户端实例时。
避免每次请求都新建 rest.Config 和 Clientset
频繁调用 rest.InClusterConfig() 或 clientset.NewForConfig() 不仅开销大，还可能触发重复的证书加载和 TLS 握手。生产环境应复用单例客户端。
- 在应用启动时初始化一次
rest.Config，再基于它构建clientset.Clientset或更轻量的dynamic.Client - 若需多租户或命名空间隔离，复用同一
rest.Config，仅通过clientset.CoreV1().Pods("ns")切换作用域，而非新建 client - 注意：不要在 HTTP handler 内部 new clientset——这是最常见导致 goroutine 泄漏和连接耗尽的原因
用 SharedInformer 替代轮询式 List + Watch
手动实现 List/Watch 容易出错：忘记重连、丢失事件、未处理 resourceVersion 冲突，且轮询 List 会产生大量无意义 API 请求，加重 apiserver 压力。
- 优先使用
cache.NewSharedIndexInformer或更高层封装如cache.NewSharedInformer，它自动处理断连重试、event 排序、本地缓存 - 注册
AddFunc/UpdateFunc处理变更，避免在回调中做阻塞操作（如 HTTP 调用），必要时投递到 worker queue - Informers 默认不启用 resync（可通过
resyncPeriod控制），但若业务依赖“最终一致”，可设为 30s–5m，避免状态漂移
限制并发与请求频率，尤其对非核心资源
未加约束的并发 List 操作（比如批量查 100 个命名空间下的 ConfigMap）极易触发 apiserver 的 429 Too Many Requests，甚至影响集群其他组件。
立即学习“go语言免费学习笔记（深入）”；
- 使用
controller-runtime/pkg/client时，通过Options{Limit: n}控制单次 List 数量；用client-go原生 client 时，手动分页（Continuetoken）+ 控制 goroutine 并发数（如semaphore包） - 对非实时性要求高的场景（如审计、报表），主动延长 List 间隔，或改用
cached client（如 informer 的Store）读取本地副本 - 避免在循环中直接调用
Get——例如遍历 Pod 列表后逐个Get对应 Node，应改用批量List+ map 查找
精简 Watch event 处理逻辑与字段选择
默认 Watch 返回完整对象（含 status、annotations 等冗余字段），网络和反序列化开销显著；而复杂处理逻辑（如 deepEqual、结构体转换）会拖慢 event 回调，造成 informer 队列积压。
- 使用
fieldSelector和labelSelector过滤无关对象，减少传输和处理量 - Watch 时指定
WatchOption{AllowWatchBookmarks: true}减少因长时间空闲导致的重连 - 对只关心部分字段的场景（如仅检测 Pod phase 变更），用
FieldsV1或自定义解码器跳过不需要的字段，或启用server-side apply的 diff 模式（需 k8s ≥1.27）
真正卡住性能的往往不是 Go 代码本身，而是对 Kubernetes API 使用模式的理解偏差——比如把 client 当作无状态工具反复创建，或把 informer 当作“高级 List”来用。关键点在于：复用、缓存、过滤、节制。
