证书或Token权限问题最常见报错是x509: certificate signed by unknown authority或Forbidden: User "system:anonymous" cannot list...，本地用clientcmd.BuildConfigFromFlags读kubeconfig，集群内必须用rest.InClusterConfig并配RBAC权限。
用 client-go 连接 Kubernetes 集群失败：证书或 Token 权限问题最常见
直接报错 x509: certificate signed by unknown authority 或 Forbidden: User "system:anonymous" cannot list ...，基本不是代码写错了，而是认证没配对。
本地开发时，优先复用 kubectl 的配置（即 ~/.kube/config），避免手动拼证书路径和 Token：
config, err := rest.InClusterConfig() // 仅限 Pod 内运行
// vs
config, err := clientcmd.BuildConfigFromFlags("", kubeconfigPath) // 本地调试用，kubeconfigPath 可设为 ""
- 如果传空字符串给
BuildConfigFromFlags，client-go 会自动读取KUBECONFIG环境变量或默认路径 - 在集群内运行时，别硬编码
~/.kube/config—— 它不存在，必须用InClusterConfig()读取 ServiceAccount 自动挂载的 token 和 CA - RBAC 权限要按实际操作收敛：比如只读 Deployment，就不要给
cluster-admin；用kubectl auth can-i --list快速验证当前账号权限
Watch Deployment 状态变化但收不到事件？检查 ResourceVersion 和 namespace 范围
Watch 不是“实时推送”，而是基于 HTTP long-running GET + 增量响应。漏事件或连接频繁断开，大概率是参数没对齐。
典型 Watch 循环里，ResourceVersion 是关键游标：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
opts := metav1.ListOptions{
Watch: true,
ResourceVersion: "0", // 从最新版本开始监听（非从头）
}
watch, err := clientset.AppsV1().Deployments("default").Watch(ctx, opts)
-
ResourceVersion: "0"表示从当前最新状态开始 watch；设为空字符串会触发 list+watch，但可能错过中间变更 - 务必指定 namespace（如
"default"），跨 namespace 的资源不会出现在该 Watch 流中；需要全集群监听，得用clientset.AppsV1().Deployments("").Watch(...)（注意是空字符串，不是"*"） - Watch 连接可能因超时、网络抖动断开，需在
watch.ResultChan()循环外层加重连逻辑，不能假定一次 Watch 永久有效
更新 Deployment 镜像时出错：Patch 比 Replace 更安全，且要处理冲突
直接 Update() 整体替换对象，极易因字段被 controller（如 HPA、Deployment Controller）自动修改而触发冲突（409 Conflict）。用 Patch() 是更稳的选择。
推荐用 StrategicMergePatchType 修改镜像字段，它理解 struct tag（如 +patchStrategy=merge）：
patchData := []byte(`{"spec":{"template":{"spec":{"containers":[{"name":"myapp","image":"nginx:1.25"}]}}}}`)
_, err := clientset.AppsV1().Deployments("default").Patch(
ctx,
"my-deploy",
types.StrategicMergePatchType,
patchData,
metav1.PatchOptions{},
)
- 确保 patch JSON 中的
name字段与原容器名严格一致，否则会新增容器而非替换 - 如果 Deployment 启用了
revisionHistoryLimit，Patch 后会自动滚动更新并保留旧 ReplicaSet —— 这是预期行为，不是 bug - 若需强制跳过冲突检测（极少见），可加
FieldManager: "my-controller"到PatchOptions，但会覆盖其他 manager 的字段管理权
Controller 重启后丢状态？别把状态存在内存里
Deployment 控制器本身不存状态，它每次 reconcile 都从 API Server 拉取最新资源快照。你的程序如果也这么干，就不用操心“恢复” —— 但前提是每次 List/Get 都带 context 超时，且能容忍短暂不一致。
- 不要用全局 map 缓存 Pod IP 或副本数；下次 reconcile 时重新
List即可 - 如果真需要持久化中间状态（例如灰度批次记录），用 CRD 存自身状态，或借助 etcd（通过
clientset.CoreV1().ConfigMaps存到集群），而不是本地文件或内存 - reconcile 函数必须幂等：同一事件调用两次，结果应与调用一次相同；Kubernetes 本身不保证事件只投递一次
真正难的是处理“部分失败”场景：比如 Patch 成功但后续的 ConfigMap 更新失败。这时候得设计回滚路径，或者接受最终一致性 —— 多数 Operator 就是这么工作的。
