如何在Golang中监控应用部署状态_实时查看Pod和Service状态

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 等约定标签。

• 在 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 —— 必须等缓存同步完成再开始业务逻辑，否则可能漏掉初始状态。