headless service 不分配 clusterip，不代理转发，仅通过 dns 提供 pod 真实 ip 和端口；需配置 ports.name 以生成 srv 记录，配合 statefulset 实现稳定网络标识与点对点通信。
Headless Service 本身不暴露端口——它不分配 ClusterIP，也不做代理转发，所以不存在“暴露端口”这一行为；你真正要做的，是让客户端能通过 DNS 查到 Pod 的真实 IP 和端口，然后自己直连。
为什么 clusterIP: None 后 port 字段还必须写
Service 资源的 ports 字段在 Headless 模式下不是用于转发，而是用于 DNS SRV 记录生成和端点发现。Kubernetes DNS（CoreDNS）会根据这个配置生成 _portname._protocol.service.namespace.svc.cluster.local 这类 SRV 记录，供客户端查出目标 Pod 的 IP + 端口组合。
- 如果只写
port: 8080，DNS 会返回 A 记录（仅 IP），客户端得自己硬编码端口 - 如果同时写
port: 8080和name: http，DNS 就能返回 SRV 记录，含target（Pod IP）、port（8080）和priority，Go 客户端可用net.LookupSRV自动解析 -
targetPort在 Headless Service 中可省略（不参与转发），但建议保留，方便阅读和与 Pod 端口对齐
Go 应用如何正确读取 Headless Service 的 SRV 记录
Go 标准库 net 包支持直接查 SRV，但要注意：CoreDNS 返回的 SRV 记录中 target 是 Pod 的短域名（如 go-app-0.go-headless.default.svc.cluster.local），不是 IP 地址；你需要再做一次 A 记录查询，或改用 LookupHost + 硬编码端口。
- 推荐方式：先查 SRV → 得到
target域名和port→ 再用net.LookupHost(target)解出 IP 列表 → 拼接IP:port连接 - 避坑点：
net.LookupSRV默认查的是tcp协议，如果你的 Go 服务监听的是 UDP，得传"udp"；协议不匹配会返回空 - 示例片段：
srvs, err := net.LookupSRV("http", "tcp", "go-headless.default.svc.cluster.local") if err != nil { log.Fatal(err) } for _, srv := range srvs { ips, _ := net.LookupHost(srv.Target) for _, ip := range ips { addr := net.JoinHostPort(ip, strconv.Itoa(int(srv.Port))) // 连接 addr... } }
selector 必须精确匹配 Pod 标签，且不能依赖 Deployment 自动生成的 label
Headless Service 不经过 kube-proxy，完全靠 DNS + Endpoints 控制器同步后端列表。如果 selector 写错，Endpoints 对象就为空，DNS 查不到任何记录。
- 常见错误：Deployment 模板里写了
app: go-app，但 Service 的selector写成app: go-service—— 零匹配，kubectl get endpoints go-headless显示<none></none> - 验证方法：运行
kubectl get endpoints go-headless -o wide，输出应包含所有目标 Pod 的 IP；若为空，立刻检查selector和 Pod 实际标签（kubectl get pod -l app=go-app -o wide） - StatefulSet 场景下，务必在
serviceName字段显式指向该 Headless Service，否则 Pod 域名不会按statefulset-0.service-name.namespace.svc.cluster.local规则生成
Headless Service + StatefulSet 是有状态 Go 服务的标配组合
无状态 Go 服务（如 HTTP API）通常用 ClusterIP Service 就够了；但当你需要每个实例有唯一身份、稳定网络标识（比如 gRPC server 需要被其他 Pod 点对点调用）、或实现分布式协调（如 Raft 成员发现），就必须用 Headless Service 配合 StatefulSet。
- StatefulSet 的每个 Pod 会获得固定序号（
go-app-0,go-app-1）和稳定 DNS 名称，Headless Service 让这些名称可被外部解析 - Go 服务启动时，可通过环境变量
HOSTNAME获取自身序号，再用fmt.Sprintf("go-app-%d.go-headless.default.svc.cluster.local:8080", i)构造其他成员地址 - 注意：不要在 Go 代码里写死
default.svc.cluster.local—— 生产环境 namespace 可能不同，应通过参数或 configmap 注入 domain 后缀
最易被忽略的一点：Headless Service 的 DNS 解析延迟比 ClusterIP 高，且不带健康检查。Pod 崩溃后，Endpoints 更新需几秒，DNS 缓存可能让客户端继续尝试已失效的 IP。生产环境务必在 Go 客户端加连接重试 + 超时，并监听 Endpoints 变化事件做本地缓存刷新。
