clientset 初始化需先通过 rest.inclusterconfig（集群内）或 clientcmd.buildconfigfromflags（本地）获取 *rest.config，再传给 kubernetes.newforconfig() 创建；禁用硬编码 url 或 http.defaultclient。
client-go 的 clientset 怎么初始化并连接到集群
Operator 必须拿到一个能跟 apiserver 通信的 clientset，否则所有操作都是空谈。它不是凭空 new 出来的，得靠 rest.InClusterConfig()（运行在集群内）或 clientcmd.BuildConfigFromFlags()（本地调试）生成 config，再喂给 kubernetes.NewForConfig()。
常见错误是直接用 http.DefaultClient 或硬写 URL —— client-go 会自动处理 bearer token、TLS、重试、序列化等细节，跳过它等于重造轮子且大概率出错。
- 集群内运行：确保 Pod 挂载了 ServiceAccount Token（默认已挂载），调用
rest.InClusterConfig()即可 - 本地调试：用
kubeconfig文件路径，例如clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig") - 务必检查返回的
*rest.Config是否为 nil，否则NewForConfig会 panic - 如果 Operator 需要操作 CRD 资源（比如你自定义的
MyApp），clientset不管用，得用dynamic.Client或生成的 clientset（用 kubebuilder 或 controller-gen）
怎么安全地 Get/Update 一个 Deployment
别直接用 clientset.AppsV1().Deployments("ns").Get(ctx, "name", metav1.GetOptions{}) 就完事。实际场景中，你要处理版本冲突、权限不足、资源不存在这三类高频问题。
Update 特别容易踩坑：直接改完对象丢给 Update() 会触发完整替换，可能覆盖掉其他 controller 写入的字段（比如 status 或 annotation）。正确做法是先 Get，再深拷贝、修改、Update；或者用 Patch 只发变更部分。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 总是传入带超时的
context.Context，比如ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) - 对
Get结果做errors.IsNotFound()判断，而不是检查 err == nil - 更新时优先考虑
clientset.AppsV1().Deployments("ns").Patch(ctx, "name", types.StrategicMergePatchType, patchData, metav1.PatchOptions{})，避免读-改-写竞争 - 如果必须用
Update，确保对象里只保留你要改的字段，其他字段从Get结果 copy，不要 new 空 struct
ListWatch 机制下怎么避免漏事件或重复处理
Operator 本质是基于 ListWatch 构建的，但 cache.NewInformer() 或 controller.Watch 不是“开箱即用就稳”。Watch 连接可能断开、relist 间隔可能错过事件、resourceVersion 过期都会导致状态不一致。
最典型的症状是：CR 创建后，Operator 日志没打印任何 reconcile 日志；或者同一个对象被反复 reconcile 十几次。
- 确保 Informer 的
ResyncPeriod设置合理（比如 5 分钟），否则长时间没事件时缓存会彻底失效 - 不要在
Reconcile里直接调clientset.List()—— 应该从 Informer 的Store里取，否则绕过 cache，性能差还易错 - Watch 的
EventHandler中的OnAdd/OnUpdate/OnDelete是异步的，不能在里面做耗时操作（如调外部 API），应只往 workqueue 塞 key - workqueue 的 key 格式必须统一，推荐用
types.NamespacedName{Namespace: obj.GetNamespace(), Name: obj.GetName()}字符串，避免因斜杠或大小写导致去重失败
为什么 UpdateStatus 失败却没报错，以及怎么修复
Deployment 的 spec 和 status 是两个独立子资源，clientset.AppsV1().Deployments("ns").UpdateStatus() 才是改 status 的正路。用普通 Update() 改 status 字段会静默失败 —— server 返回 409 Conflict，但 client-go 默认不暴露这个错误，只返回 nil。
更隐蔽的是：如果你用 dynamic client 更新 CR 的 status，必须确认 CRD 定义里声明了 subresources.status，否则 apiserver 直接 404，而 client-go 的 error message 里只有 “the server could not find the requested resource”，根本看不出是 subresource 问题。
- 检查 CRD YAML 是否包含
subresources: {status: {}} - status 更新一定要用
xxxClient.Status().Update(ctx, obj, ...)或xxxClient.Status().Patch(...) - 对 CR 使用 dynamic client 时，patch path 要写成
/status，不是/ - 如果 status 更新频繁，考虑加个简单版本号字段（如
status.observedGeneration），避免无意义的重复 patch
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
