必须用 client-go，因其内置RestClient重试限流、DiscoveryClient资源协商、DynamicClient非结构化支持及SharedInformer机制，裸HTTP调用无法处理token刷新、watch重连、resourceVersion冲突和CRD解析等问题。
直接用 client-go 是唯一可行路径，其他封装库要么过时，要么绕不开它。 想绕过 client-go 自己拼 API 请求或依赖 kubectl 二进制，短期能跑，长期维护成本爆炸，且无法处理 watch、relist、retry 等核心逻辑。
为什么必须用 client-go 而不是裸 HTTP 调用
client-go 不只是“发请求的包”，它内置了：RestClient 的重试与限流、DiscoveryClient 的资源版本协商、DynamicClient 的非结构化资源支持，以及最关键的 SharedInformer 机制。裸调 /api/v1/pods 可能连 401 Unauthorized 后自动刷新 token 都得自己写。
常见错误现象包括：
- Watch 连接断开后不重连，程序静默丢失事件
- 并发更新时因 resourceVersion 冲突反复失败（
Operation cannot be fulfilled on pods "x": the object has been modified） - 集群启用了 CRD，但硬编码的 struct 解析失败，panic 在
json.Unmarshal
如何安全地创建 client-go 客户端实例
别直接 new rest.Config 手动填字段——90% 的权限/证书问题都出在这儿。优先走标准加载链：
立即学习“go语言免费学习笔记（深入）”；
- 本地开发：用
clientcmd.BuildConfigFromFlags("", kubeconfigPath)，kubeconfigPath默认是$HOME/.kube/config - Pod 内运行：用
rest.InClusterConfig()，它会自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的 token 和 ca.crt - 务必设置
QPS和Burst，尤其在批量操作时，否则容易触发 apiserver 的 429 限流
示例关键片段：
cfg, err := rest.InClusterConfig()
if err != nil {
panic(err)
}
cfg.QPS = 50
cfg.Burst = 100
clientset, err := kubernetes.NewForConfig(cfg)
管理自定义资源（CRD）的两种方式
如果目标资源是 CRD（比如 ingressroutes.contour.io），不能用 clientset —— 它只认内置资源。必须选以下之一：
- 用
dynamicClient+unstructured.Unstructured：适合通用工具类场景，无需提前定义 struct，但类型安全为零，字段访问靠字符串键（如obj.Object["spec"]["rules"]） - 用 client-gen 为 CRD 生成 typed client：需要 CRD 的 OpenAPI spec 或 Go struct 定义，生成后可享受编译期检查和 IDE 补全，但每次 CRD 变更都要重新生成
注意：dynamicClient.Resource(schema.GroupVersionResource) 中的 GroupVersionResource 必须严格匹配 CRD 的 spec.group、spec.versions[0].name 和 spec.names.plural，错一个就报 the server could not find the requested resource。
Watch 事件处理中容易忽略的边界
很多人以为 Informer 启动后就能稳收事件，但实际有三个隐性陷阱：
- 第一次 List 结果可能为空，
EventHandler.OnAdd不会触发，需手动调用informer.GetIndexer().List()做初始同步 -
OnUpdate的新旧对象都是指针，若直接赋值给局部变量并启动 goroutine 处理，很可能读到被后续事件覆盖的内存（典型 data race） - Informers 默认不监听 namespace 变更，若需跨 namespace 动态响应，得用
cache.NewSharedIndexInformer并注册cache.Indexers，而非直接用cache.NewSharedInformer
真正稳定的 watch 流程，往往要组合 Reflector、DeltaFIFO 和自定义 Process 函数，而不是只依赖 SharedInformer 的默认 handler。
