不推荐单独依赖 client-go 做生产级监控，它适合控制器逻辑或轻量状态轮询，而非替代 Prometheus；应结合 SharedInformer 实现稳定事件监听、超时控制和 CRD 状态补充，定位为精准干预而非持续观测。
直接用 client-go 做集群状态监控是可行的，但**不推荐单独依赖它做生产级监控**——它适合控制器逻辑或轻量状态轮询，不适合替代 Prometheus 这类专为指标采集设计的系统。
用 client-go List-Watch 实时跟踪 Pod 状态变化
这是最典型的“监控”动作：不查日志、不拉指标，而是监听资源生命周期事件。关键在于避免自己实现重连和事件去重。
-
clientset.CoreV1().Pods("default").Watch(ctx, metav1.ListOptions{Watch: true})返回watch.Interface，调用ResultChan()获取watch.Event - 每个
Event.Type是Added/Modified/Deleted，Event.Object是 *corev1.Pod，需类型断言 - ⚠️ 常见坑：没处理
ctx.Done()导致 goroutine 泄漏；Watch 连接断开后没重试，直接静默退出 - ✅ 更稳做法：用
cache.NewSharedInformer封装，它自动重连、本地缓存、支持 AddEventHandler 注册回调
用 client-go 检查节点就绪状态（别只看 Ready condition）
单纯查 Node.Status.Con 里 
Type=="Ready" 的 Status=="True" 不够——很多故障下节点仍显示 Ready，但实际无法调度 Pod。
- 要同时检查
Node.Status.Allocatable是否非空，以及Node.Spec.Unschedulable == false - 更实用的是结合
Node.Status.NodeInfo.KubeletVersion和Node.Status.Images判断 kubelet 是否活跃（比如 5 分钟内没上报镜像列表，大概率失联） - ⚠️ 常见坑：用
List()后遍历判断，却没设context.WithTimeout，API Server 响应慢时整个监控流程卡住 - ✅ 建议加超时：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)，用完记得cancel()
用 client-go 补充 Prometheus 监控盲区（如自定义资源状态）
Prometheus 擅长指标，但对 CRD 资源的语义状态（比如 MyDatabase.Spec.Replicas == MyDatabase.Status.ReadyReplicas）抓取困难，这时 client-go 是唯一选择。
- 写个轻量 informer 监听你的 CRD，一旦发现
Status.Phase == "Failed"，立刻发告警或触发修复逻辑 - 注意：CRD 的 GroupVersion 必须提前注册到
scheme，否则clientset.RESTClient()解析失败，报错"no kind is registered for the type" - ✅ 示例注册方式：
myv1.AddToScheme(scheme.Scheme)，再传给dynamic.NewForConfig或自定义 clientset - 性能影响：频繁 Get 单个 CR 对 API Server 压力大，优先用 SharedInformer + 本地 cache，而不是循环 List
为什么 client-go 不该当主力监控工具？
它本质是 Kubernetes 客户端 SDK，不是监控采集器。硬用它做全量指标采集，会踩一堆隐性坑：
- 没有采样控制：每秒 Watch 所有 Pods，API Server QPS 爆表，触发限流（
429 Too Many Requests） - 无指标聚合：你得自己算 CPU 使用率百分比、滚动平均值、P95 延迟——而 Prometheus 内置 PromQL 就能一行搞定
- 无持久化：内存里存的状态重启即丢，没法查历史趋势；Prometheus 自带 TSDB，Grafana 可随时回溯
- 告警能力弱：没 Alertmanager 那套静默、分组、路由机制，容易消息轰炸或漏告
真正该做的，是让 client-go 做“精准干预”（比如发现 Deployment 失败立即 Patch 回滚），把“持续观测”交给 Prometheus + Grafana ——两者定位不同，混用反而增加运维复杂度。
