Go服务在Kubernetes中不推荐仅依赖DNS解析做服务发现，因其延迟高、无法感知Pod健康状态、不提供端口映射且不能区分就绪与未就绪实例；可靠方式是用client-go监听Endpoints或Pod变化，实时维护本地endpoint池。
Go 服务在 Kubernetes 中做服务发现，不能只靠 DNS 解析 my-service.default.svc.cluster.local 就完事——它延迟高、不感知 Pod 健康状态、无法做客户端负载均衡。真正可靠的方式是用 client-go 直连 API Server，读取 Endpoints 或监听 Pod 变化。
为什么 DNS 方式在 Go 里不推荐作为主发现路径
DNS 解析（如 CoreDNS）本质是查 Endpoints 对象的 IP 列表，但 Go 程序无法：
- 实时感知 Endpoints 更新（TTL 默认 30s，glibc/resolver 还可能缓存更久）
- 区分就绪（Ready）与未就绪 Pod（DNS 返回所有后端，包括 Pending 或 CrashLoopBackOff 的）
- 获取端口映射（targetPort 名称或数字需从 Service 定义中解析，DNS 不提供）
- 处理 headless Service 场景下的多端口、多协议实例发现
所以 DNS 更适合作为 fallback 或调试辅助，而非生产级服务发现主干。
用 client-go ListWatch Endpoints 实现实时 endpoint 池
Endpoints 是 Service 的真实后端地址快照，由 kube-proxy 和 endpoints controller 维护，比直接 Watch Pod 更轻量、语义更清晰。
- 必须确保 Service 的
selector准确匹配目标 Pod 标签，否则Endpoints为空 - Watch 时用
metav1.ListOptions{FieldSelector: "metadata.name=my-service"}，避免拉全量再过滤 - 每次事件中要检查
endpoints.Subsets，每个 Subset 包含addresses（就绪 Pod）和notReadyAddresses（不就绪 Pod），只取前者 - 端口信息来自
endpoints.Subsets[].Ports[].Port，注意它对应的是 Service 的port字段，不是 Pod 的containerPort
示例关键逻辑：
立即学习“go语言免费学习笔记（深入）”；
watcher, _ := clientset.CoreV1().Endpoints("default").Watch(ctx, metav1.ListOptions{
FieldSelector: "metadata.name=my-service",
})
for event := range watcher.ResultChan() {
ep, ok := event.Object.(*corev1.Endpoints)
if !ok { continue }
for _, subset := range ep.Subsets {
for _, addr := range subset.Addresses {
// addr.IP + subset.Ports[0].Port 构成可用 endpoint
}
}
}Watch Pod + LabelSelector 比 Endpoints 更灵活但开销更大
当需要绕过 Service 抽象（比如直连某类 Job Pod、或做自定义健康标记），就得 Watch Pod 并用 LabelSelector 过滤。
- 务必加
FieldSelector: "status.phase=Running"，否则会收到大量Pending/SucceededPod 事件 - Pod 的
targetPort需从容器定义里取：pod.Spec.Containers[0].Ports[0].ContainerPort，且要处理多个容器/多个端口的情况 - 注意
PodIP在容器启动后才分配，Watch 到事件时需检查pod.Status.PodIP != "" - RBAC 权限要同时包含
pods和pods/status，否则无法读取Status.Phase
client-go discovery.Clientset 用来动态识别服务资源结构
如果你的服务发现逻辑要支持任意命名空间、任意 Service 名，或需要兼容 CRD 提供的“服务”抽象（如 ServiceImport），就不能硬编码 CoreV1().Services() 路径。
- 用
discoveryClient.ServerResourcesForGroupVersion("v1")查services是否存在、是否 namespaced - 用
restmapper.RESTMapping(schema.GroupKind{Group: "", Kind: "Service"}, "v1")获取其 REST 路径和版本偏好，避免因集群升级导致 API 路径变更（如/api/v1→/api/v2） - 该能力在编写通用 CLI 工具或 Operator 时关键，普通业务服务可跳过
最易被忽略的一点：Informer 缓存的 Endpoints 对象默认不包含 Subsets 的完整字段（尤其 notReadyAddresses），若需精确判断就绪状态，必须用 ListWatch 原始事件流，不能依赖 Informer 的本地 store。
