必须配置 rest.Config：本地用 kubeconfig 文件（KUBECONFIG 环境变量或 BuildConfigFromFlags），Pod 内用 rest.InClusterConfig()；Pod 操作需指定命名空间（如 "default" 或 metav1.NamespaceAll）；Watch 需处理错误并重试；Delete 须显式设 GracePeriodSeconds 和 PropagationPolicy。
用 client-go 连接集群前必须配置 rest.Config
不配对 rest.Config，所有后续操作都会报 no Auth Provider found for name "oidc" 或 unable to load in-cluster configuration。本地开发和 Pod 内运行的配置方式完全不同，不能混用。
常见错误是直接调用 rest.InClusterConfig() 试图在本地跑通——它只在 Kubernetes Pod 里有效；本地必须用 kubeconfig 文件：
- 检查
KUBECONFIG环境变量是否指向正确路径，如$HOME/.kube/config - 若使用非默认路径，显式传入：
clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig") - 若用 service account token（如 CI 场景），需手动构造
rest.Config：填Host、BearerToken、TLSClientConfig.Insecure（仅测试）或CertData
创建 CoreV1Client 后，List 和 Get 的命名空间参数不能省略
corev1.Pod 是命名空间作用域资源，调用 clientset.CoreV1().Pods("").List() 会 panic：空字符串触发 namespace is required。Kubernetes 不支持跨命名空间批量操作（除少数如 Node）。
正确做法分场景：
立即学习“go语言免费学习笔记（深入）”；
- 查某命名空间下所有 Pod：
clientset.CoreV1().Pods("default").List(ctx, metav1.ListOptions{}) - 查所有命名空间的 Pod（需权限）：
clientset.CoreV1().Pods(metav1.NamespaceAll).List(ctx, metav1.ListOptions{}) - 查单个 Pod：
clientset.CoreV1().Pods("default").Get(ctx, "my-pod", metav1.GetOptions{})
注意 NamespaceAll 是常量，不是字符串 "all"，写错会静默返回空列表。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Watch Pod 状态变化时，Watch 接口必须处理 connection refused 和 too old resource version
clientset.CoreV1().Pods("default").Watch() 返回的 watch.Interface 不自动重连。网络抖动或 apiserver 重启后，watch 流会中断并返回 error，但程序若不检查就继续读 channel，会 panic。
典型处理模式：
- 每次 watch 前生成新
resourceVersion：首次用""，后续从上一次事件的Event.Object.(*corev1.Pod).ResourceVersion取值 - 捕获
errors.IsForbidden(err)或errors.IsServiceUnavailable(err)后 sleep 后重试 - 遇到
TooOldResourceVersion错误，必须重新List并从最新ResourceVersion重启 watch
别依赖 time.Sleep 定期轮询替代 watch——性能差且错过事件。
删除 Pod 时，GracePeriodSeconds 和 PropagationPolicy 直接影响级联行为
调用 clientset.CoreV1().Pods("default").Delete(ctx, "my-pod", metav1.DeleteOptions{}) 默认立即终止容器（等价于 kubectl delete pod --grace-period=0），但不会清理关联的 OwnerReference 资源（如由 Deployment 创建的 Pod）。
要控制生命周期，必须显式设置：
-
GracePeriodSeconds: &int64(30)—— 给容器内进程优雅退出时间 -
PropagationPolicy: &deletePropagationBackground—— 后台异步删除 owner 控制的子资源（如 PVC 不会等 PV 释放完才返回） -
PropagationPolicy: &deletePropagationForeground—— 阻塞直到所有依赖资源被标记为删除（Deployment 会重建新 Pod）
忘记设 PropagationPolicy 是 Deployment 下 Pod 残留的常见原因——删了 Pod，Deployment 立刻新建一个，你以为删失败了，其实是策略没生效。
