Headless Service不提供端口代理或ClusterIP，仅通过DNS返回Pod真实IP，客户端需预知Go服务监听端口并直连；Go必须监听0.0.0.0而非127.0.0.1，配合StatefulSet可获得稳定DNS名称如go-0.go-service.default.svc.cluster.local。
Headless 服务本身不“暴露端口”——它不走 kube-proxy，没有 ClusterIP，也没有端口转发逻辑。你真正要做的，是让 Go 服务监听的端口能被其他 Pod 直接访问，并通过 DNS 解析拿到后端 Pod 的真实 IP 和端口。所谓“自定义端口”，其实是 Go 进程自己监听的端口，不是 Service 配置出来的。
Headless Service 的 port 和 targetPort 字段其实没用
在 Headless Service 的 YAML 中写 port: 8080 和 targetPort: 8080 看似合理，但实际：
- kube-proxy 完全不处理 clusterIP: None 的 Service，所以这些端口不会被映射或代理
- DNS 查询（如 nslookup go-service.default.svc.cluster.local）只返回 A 记录（Pod IP），不带端口信息
- 客户端必须**硬编码或通过配置知道 Go 服务监听的具体端口**，然后直连 <pod-ip>:<your-go-port></your-go-port></pod-ip>
- 如果你的 Go 服务监听
:8081，那所有调用方都得连10.244.x.y:8081，Service 的port字段对运行时完全无影响 - YAML 里仍建议保留
port和targetPort，主要为语义清晰、工具链兼容（如kubectl describe svc显示可读信息）、以及未来可能切换回 ClusterIP - 别指望
port能做端口重映射：Headless 下port: 9000 / targetPort: 8081不会生效
Go 服务必须监听 0.0.0.0，不能只监听 127.0.0.1
这是最容易踩的坑。很多本地调试的 Go 服务习惯写 http.ListenAndServe("127.0.0.1:8080", handler)，在 Pod 里这会导致：
- 其他 Pod 可以解析到该 Pod IP，但连不上 —— 因为服务只绑定了 loopback 接口
- curl http://<pod-ip>:8080</pod-ip> 在另一 Pod 里直接 timeout
- 务必改成
http.ListenAndServe(":8080", handler)或http.ListenAndServe("0.0.0.0:8080", handler) - 验证方式：进目标 Pod 执行
netstat -tuln | grep 8080，看到*:8080才算正确绑定 - 如果用了
gin、echo等框架，同样检查启动代码是否隐式绑定了 127.0.0.1
StatefulSet + Headless 是稳定访问的前提
若你的 Go 服务需要每个实例有固定网络身份（比如做 Raft 成员、分片注册、WebSocket 会话亲和），必须搭配 StatefulSet 使用 Headless Service。否则：
- Deployment 创建的 Pod 名称随机，DNS 名称不稳定（go-service-xyz-abc 每次重建都变）
- 无法实现 go-0.go-service.default.svc.cluster.local 这类确定性域名
- 在
StatefulSet.spec.serviceName中指定已存在的 Headless Service 名称（如go-headless） - 确保
StatefulSet.spec.selector.matchLabels和Service.spec.selector完全一致 - DNS 解析结果会是：
go-0.go-headless.default.svc.cluster.local → 10.244.1.12，go-1.go-headless.default.svc.cluster.local → 10.244.2.33，依此类推 - 客户端可基于序号做一致性哈希或主从路由，而无需依赖外部注册中心
客户端如何安全获取并使用 Pod 地址
别在代码里写死 IP。推荐两种可靠方式：
-
DNS 轮询 + 连接池健康检查：用
net.LookupHost("go-headless.default.svc.cluster.local")获取全部 Pod IP，建立连接池，失败时自动剔除并重试其他节点（注意：Kubernetes CoreDNS 默认不支持 SRV 记录返回端口，所以端口仍需预设） -
结合 readinessProbe：在 Go 服务中暴露
/readyz，并在StatefulSet中配置readinessProbe；这样Endpoints对象只包含就绪 Pod，DNS 返回的地址才真正可用（需加publishNotReadyAddresses: false，默认就是 false） - 避免用
getent hosts或ping判断可用性 —— 它们不校验端口连通性，且 ICMP 可能被禁用
Headless 的本质是“去中介化”，它把服务发现的责任交还给应用层。端口、健康、路由、故障转移，都不再由 Kubernetes 代劳 —— 这不是缺陷，而是设计取舍。用错场景会很痛苦，用对了反而更轻、更快、更可控。
