证书校验失败需检查 kubeconfig 中 certificate-authority-data 是否正确或设 insecure-skip-tls-verify: true；Watch 收不到删除事件因 Terminating 状态未触发 Delete，应监听 DeletionTimestamp 或 phase 变更；Prometheus 查询须设超时并避免高频请求；controller-runtime 中避免 Reconcile 死循环，只必要时更新 Status 并控制重试频率。
用 client-go 连接 Kubernetes 集群时证书校验失败怎么办
直接报错 x509: certificate signed by unknown authority 是最常见问题，本质是 Go 客户端默认启用 TLS 严格校验，而本地 ~/.kube/config 中的 certificate-authority-data 或 insecure-skip-tls-verify: true 没被正确加载。
- 确认
rest.InClusterConfig()和rest.InClusterConfig()的使用场景：前者用于 Pod 内运行（自动挂载 ServiceAccount Token），后者用于本地调试，需显式传入 kubeconfig 路径 - 若用
rest.InClusterConfig()，确保 Pod 有对应 RBAC 权限，且serviceaccount已绑定cluster-reader类角色 - 本地调试时别手动拼
rest.Config，优先用clientcmd.BuildConfigFromFlags("", kubeconfigPath)，它会自动处理 base64 解码、证书路径解析和 skip-tls 标志 - 临时跳过校验仅用于开发：设置
config.Insecure = true，但上线前必须删掉——生产环境禁用该选项
监听 Pod 状态变化为什么收不到删除事件
Watch 接口返回的 watch.Event 类型中，Delete 事件只在对象被**彻底从 etcd 删除后**触发；而用户执行 kubectl delete pod 后，Pod 先变成 Terminating 状态（仍在 list 中），几秒后才真正消失。很多监控逻辑误把 Terminating 当作“已删除”，导致漏判。
- 判断 Pod 是否正在退出：检查
pod.Status.Phase == "Pending" || pod.Status.Phase == "Running"，其余状态（Failed、Succeeded、Unknown、Terminating）都应纳入异常流处理 - 用
cache.NewInformer替代裸Watch：它自带本地缓存和事件队列，能捕获Update事件中的 phase 变更，比等Delete更及时 - 注意
DeletionTimestamp字段：只要非 nil，就代表删除流程已开始，此时应立即触发告警逻辑，无需等待Delete事件
如何避免 Prometheus 查询超时导致监控服务卡死
Golang 调用 Prometheus API（如 /api/v1/query）时，若未设超时，HTTP 请求可能无限 hang 住，拖垮整个监控 goroutine。Prometheus 自身响应慢常因查询范围过大、label 匹配爆炸或存储压力高引起。
- 所有
http.Client必须带Timeout：建议设为10s，并搭配context.WithTimeout控制整条调用链 - 避免在循环里高频查
up{job="xxx"}：改用count(up{job="xxx"} == 0)一次聚合，减少请求次数 - 查询时间范围别写死
time.Now().Add(-5m)：用time.Now().UTC().Add(-5 * time.Minute)，否则时区错位会导致查空数据 - 对返回的
prometheus.Result做类型断言前先检查result.Type == prometheus.ValVector，防止 panic
用 controller-runtime 实现自定义资源监控时 Reconcile 频率失控
默认 Reconciler 在对象变更时触发，但若在 Reconcile 里主动更新对象（比如打 status 时间戳），会再次触发自身，形成死循环。Kubernetes 会以指数退避重试，最终日志刷屏且监控延迟飙升。
