Pod 内必须用 rest.InClusterConfig()，本地开发必须用 clientcmd.BuildConfigFromFlags()；Watch 删除事件应监听 Update 并检查 DeletionTimestamp；判断 Deployment 就绪需分层验证 ObservedGeneration、AvailableReplicas 及 Pod 状态；更新 Status 前须深拷贝并比对避免死循环。
client-go 连不上集群时先看 rest.InClusterConfig() 和 clientcmd.BuildConfigFromFlags() 用对没
本地调试和 Pod 内运行是两套完全不同的配置路径，混用必报错。Pod 内必须用 rest.InClusterConfig()（它会自动读取 /var/run/secrets/kubernetes.io/serviceaccount/ 下的 token 和 ca.crt），而本地开发必须用 clientcmd.BuildConfigFromFlags("", kubeconfigPath)。
常见错误现象：x509: certificate signed by unknown authority —— 多半是手动 new 了个 rest.Config 然后硬塞了 host 和 cert 数据，漏掉了 base64 解码、证书路径解析或 insecure-skip-tls-verify 标志传递。
- 别自己拼
rest.Config，clientcmd.BuildConfigFromFlags()会自动处理certificate-authority-data的 base64 解码 - Pod 内运行时，确保 ServiceAccount 已绑定
cluster-reader类角色，否则rest.InClusterConfig()能连上但 list/watch 全部 403 - 临时跳过校验只用于调试：设
config.Insecure = true，但上线前必须删掉——生产环境禁用
Watch Pod 删除事件收不到？重点盯 DeletionTimestamp 和 Status.Phase
watch.Event.Type == watch.Deleted 只在对象从 etcd 彻底删除后才触发，而用户执行 kubectl delete pod 后，Pod 进入 Terminating 状态并停留数秒，此时仍出现在 List 结果里，裸 Watch 就会漏掉这个关键窗口。
正确做法是监听 Update 事件，并检查 pod.ObjectMeta.DeletionTimestamp != nil 或 pod.Status.Phase == "Pending" || pod.Status.Phase == "Running" 的反向逻辑——只要不是这两个值，就应视为退出中或已异常。
- 用
cache.NewInformer替代裸 Watch：它缓存全量对象，能捕获 Update 中的 phase 变更，比等 Delete 更及时 - 不要依赖
Terminating字符串匹配，Kubernetes 不保证该字符串稳定；DeletionTimestamp是唯一可靠信号 - 若需精确判断“正在被删除”，组合判断：
obj.GetDeletionTimestamp() != nil && obj.GetDeletionTimestamp().After(time.Now().Add(-30*time.Second))
轮询 Deployment Ready 状态时别只查 AvailableReplicas
Deployment 的 AvailableReplicas 字段只反映“就绪且满足最小可用数”的副本数，但它不体现 Pod 是否卡在 ContainerCreating、Pending 或 CrashLoopBackOff。单纯等 AvailableReplicas == Replicas 可能永远不触发，尤其当镜像拉取失败或资源不足时。
完整判断逻辑应分层：先确认 Deployment.Status.ObservedGeneration == Deployment.Generation（控制器已看到最新 spec），再查 AvailableReplicas，最后遍历其管理的 ReplicaSet 和 Pod 列表，检查每个 Pod 的 Phase 和 Conditions。
- 用
client.AppsV1().Deployments(ns).Get(ctx, name, metav1.GetOptions{})拿最新状态，别缓存旧对象 - 避免高频轮询：间隔至少 2–3 秒，配合指数退避；Prometheus 查询同理，必须设
context.WithTimeout - 若要实时感知，优先走 Informer + EventHandler，而非轮询 Get
controller-runtime 的 Reconcile 方法里更新 Status 容易引发死循环
每次调用 UpdateStatus() 都会触发一次新的 Reconcile 请求，如果逻辑里没做变更判断，就会形成无限重试。典型场景：每次 Reconcile 都无条件更新 .Status.LastHeartbeatTime，导致每秒跑十几次。
核心原则是：只在真正需要刷新状态时才写入，且必须对比新旧值。client-go 提供 apimeta.IsStatusConditionTrue() 等工具函数辅助判断。
- 用
controllerutil.SetControllerReference()设置 OwnerRef，避免手动构造引发字段不一致 - 更新 Status 前先深拷贝原对象，用
!reflect.DeepEqual(old.Status, new.Status)判定是否真有变更 - 重试控制交给
reconcile.Result{RequeueAfter: time.Second * 30}，别用time.Sleep阻塞 goroutine
复杂点在于状态判断从来不是单字段的事——DeletionTimestamp、ObservedGeneration、Conditions 这些字段的语义必须组合使用，且不同资源类型含义不同。容易被忽略的是：所有这些字段都可能为空或未设置，直接解引用 panic 是最常见的线上事故来源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
