Golang中用client-go监控K8s部署状态需通过Informer监听Pod/Service事件，结合label selector关联Deployment，检查Pod阶段与就绪态、Endpoints可用性，并封装为带缓存同步校验的健康检查器。
在 Golang 中监控 Kubernetes 应用部署状态，核心是通过 Kubernetes Client-go 调用 API 实时获取 Pod 和 Service 的最新状态。不需要写 Web 控制台也能做到轻量、可嵌入、可告警的实时观测。
使用 client-go 连接集群并监听资源变化
client-go 提供了 Informer 机制，能高效监听 Pod/Service 等资源的增删改事件，避免轮询开销。
- 初始化
rest.Config（支持 in-cluster 或 kubeconfig） - 创建
SharedInformerFactory，为v1.Pod和v1.Service分别启动 Informer - 注册
AddFunc/UpdateFunc/DeleteFunc处理状态变更 - 调用
informer.Run(stopCh)启动监听
示例关键片段：
podInformer := informerFactory.Core().V1().Pods().Informer()
podInformer.AddEventHandler(&cache.ResourceEventHandlerFuncs{
AddFunc: func(obj interface{}) {
pod := obj.(*corev1.Pod)
fmt.Printf("[ADD] %s/%s → %s\n", pod.Namespace, pod.Name, pod.Status.Phase)
},
UpdateFunc: func(old, new interface{}) {
newPod := new.(*corev1.Pod)
oldPod := old.(*corev1.Pod)
if oldPod.Status.Phase != newPod.Status.Phase {
fmt.Printf("[UPDATE] %s/%s: %s → %s\n",
newPod.Namespace, newPod.Name,
oldPod.Status.Phase, newPod.Status.Phase)
}
},
})
按 Deployment 关联查询 Pod 状态
单纯看 Pod 容易迷失上下文。应通过 ownerReferences 反查所属 Deployment，或用 label selector 匹配 app=my-app 等约定标签。
立即学习“go语言免费学习笔记（深入）”；
- 在 ListOptions 中设置
LabelSelector，例如labels.SelectorFromSet(labels.Set{"app": "api"}) - 对每个 Pod 检查
pod.Status.Phase（Pending/Running/Succeeded/Failed/Unknown） - 进一步检查
pod.Status.Conditions和pod.Status.ContainerStatuses判断就绪与健康 - 若 Pod 处于
Running但Ready=False，说明 readiness probe 未通过
同步获取 Service 端点与可用性
Service 本身无“运行中”概念，其可用性取决于后端 Endpoint 是否就绪。
- 监听
v1.Endpoints资源（和 Service 同名），查看Subsets[].Addresses是否有 IP - 结合
EndpointSlice（推荐 v1.21+）获取更细粒度的端点状态 - 若 Endpoints 为空，常见原因：Pod 未就绪、label 不匹配、Service selector 配置错误
- 可额外调用
CoreV1().Services(ns).Get(ctx, name, ...)获取 ClusterIP、Ports 等配置信息
封装成可复用的状态检查器
把逻辑收拢为结构体，支持按 namespace + app label 查询整体部署健康度：
- 定义
DeploymentStatus结构体，含TotalPods、ReadyPods、AvailableService、EndpointCount字段 - 提供
Check(ctx, namespace, appName string) (*DeploymentStatus, error)方法 - 返回 JSON 或暴露为 HTTP handler（如
GET /healthz/deploy/api），便于集成 Prometheus 或前端 - 添加超时与重试控制，避免单次 API 失败导致误判
基本上就这些。不复杂但容易忽略的是 Informer 初始化后的 WaitForCacheSync —— 必须等缓存同步完成再开始业务逻辑，否则可能漏掉初始状态。
