headless service 不支持多端口暴露：它不处理端口转发，dns 仅解析出 pod 的 ip 列表（a 记录），端口需客户端自行指定；其 spec.clusterip 必须设为 none，不创建 iptables/ipvs 规则，也不生成按端口区分的 dns 记录。
Headless Service不支持多端口暴露
直接说结论：Headless Service 本身无法通过 ports 字段定义多个端口并让 DNS 同时解析出多个端口映射 —— 它压根不处理端口转发逻辑。Kubernetes 的 DNS 系统（CoreDNS）对 Headless Service 只做一件事：把服务名解析为后端 Pod 的 IP 列表（A 记录），每个 Pod 的端口仍需由客户端自行指定。
常见误解是以为像 ClusterIP Service 那样写多个 port 条目，就能在 DNS 中拿到 port:8080 和 port:9090 的区分结果，实际不会发生。DNS 返回的只是 IP，端口必须硬编码或通过其他机制协商。
- Headless Service 的
spec.clusterIP必须设为None，它不创建 iptables/IPVS 规则，也不做任何端口代理 - DNS 解析行为由
EndpointSlice驱动：每个 Pod 的每个容器端口（containerPort）会被记录，但 CoreDNS 不按端口生成不同子域名 - 如果你看到类似
pod-0.my-svc.default.svc.cluster.local这样的名字，它的 A 记录只对应一个 IP，不是“IP+端口”组合
想让 Go 服务暴露多个端口？得靠 Pod 自身多端口声明
真正起作用的是 Pod 模板里的 containers[].ports —— Headless Service 只是把所有这些端口“透传”给 DNS 发现，但不参与路由。Go 应用自己得监听多个端口，比如 HTTP API 在 8080、metrics 在 9090、healthz 在 8081。
示例中 Deployment 的容器定义要显式列出：
containers:
- name: go-app
image: my-registry/go-app:v1
ports:
- containerPort: 8080
name: http
- containerPort: 9090
name: metrics
- containerPort: 8081
name: healthz
- 这些
containerPort名称（http、metrics）仅用于标识和调试，不影响 DNS 解析结果 - 客户端访问时仍需手动拼接：比如调用 metrics 就得用
http://<pod-ip>:9090/metrics</pod-ip>，不能靠 DNS 返回带端口的 SRV 记录（除非你额外配置了publishNotReadyAddresses: true+ 手动维护 SRV） - Go 代码里要用
net/http分别启动多个http.Server实例，绑定不同端口，别指望单个 listener 自动分发
需要按端口发现？用 Endpoints + 自定义 DNS 或客户端逻辑
原生 Kubernetes 不提供 “按端口查 Pod” 的 DNS 能力。如果你确实需要根据用途（如只找 metrics 端口）筛选 Pod，有两条路：
- 不依赖 DNS：用
kubectl get endpointslices -n <ns><svc-name></svc-name></ns>查看原始EndpointSlice对象，里面包含每个端点的ports[]数组，可脚本化提取目标端口的 IP - 加一层抽象：在 Go 应用启动时，主动向 ConfigMap/etcd 注册自己的端口映射（如
{"http": "8080", "metrics": "9090"}），其他服务通过该配置发现 —— 这绕开了 DNS 限制，也更可控 - 避免误用 SRV 记录：虽然理论上可以给每个端口配 SRV，但 Kubernetes 默认不生成；强行手写会破坏声明式管理，且
kube-dns/ CoreDNS 对 SRV 的支持不稳定，生产环境慎用
Headless + StatefulSet 是唯一推荐组合
Headless Service 单独搭配 Deployment 几乎没意义：Deployment 下的 Pod 是无状态、可互换的，DNS 返回一堆随机 IP，客户端无法稳定寻址。真要用 Headless，必须配 StatefulSet。
原因很简单：只有 StatefulSet 才会给每个 Pod 分配固定序号（pod-0、pod-1）和稳定 DNS 名（pod-0.my-headless.default.svc.cluster.local）。你的 Go 服务若需节点间直连（比如 Raft 成员列表、gRPC peer discovery），这才是唯一可靠路径。
- StatefulSet 的
serviceName字段必须指向你的 Headless Service 名，否则 DNS 不生效 - Pod 内部可通过
hostname获取自身序号，再拼出完整集群 DNS 名，实现自发现 - 别忘了在 Headless Service 的
selector中匹配 StatefulSet 的标签，否则EndpointSlice不会收录任何 Pod
多端口这件事，本质是 Go 应用自身职责；Headless Service 只负责“让 Pod 地址可被发现”，至于怎么用、用哪个端口，得你自己设计清楚。混淆这两层，部署后就会遇到 DNS 解析出来却连不上端口的问题。
