headless service 实现 pod 级精准寻址需设 clusterip: none、selector 精确匹配，dns 返回多 a 记录；客户端须自行处理多 ip 负载均衡，结合 statefulset 可获稳定 dns 名（如 kafka-0.kafka-hs.default.svc.cluster.local）。
直接用 Headless Service + CoreDNS 就能实现 Pod 级别的精准寻址，关键不在“配得多”，而在“配得准”——尤其是 DNS 解析行为和客户端调用逻辑要对齐。
明确 Headless Service 的核心配置
必须将 clusterIP: None 写死在 Service 清单中，这是触发 DNS 行为切换的开关。仅靠类型设为 ClusterIP 或省略 clusterIP 字段都不生效。
- 标签选择器（spec.selector）需精确匹配目标 Pod 的 labels，否则 DNS 不会返回任何 IP
- 端口定义（ports）可精简，只要协议和 port/targetPort 对齐即可，不参与 DNS 解析
- 若关联 StatefulSet，建议命名规范：Service 名、StatefulSet 名、Pod 模板 labels 保持语义一致，便于推导 DNS 名（如 es-0.elasticsearch-headless.default.svc.cluster.local）
验证 CoreDNS 是否按预期返回 Pod IP 列表
普通 Service 查 service-name.namespace.svc.cluster.local 返回一个 ClusterIP；Headless Service 同名查询应返回多个 A 记录。
- 进任意 Pod 执行：
nslookup your-headless-svc.default.svc.cluster.local - 预期输出是多行
A记录，每行一个后端 Pod 的实际 IP（不是 ClusterIP） - 若只返回 NXDOMAIN 或空结果，优先检查：CoreDNS 是否运行正常、Service selector 是否匹配 Pod、Pod 是否处于 Running+Ready 状态
客户端需适配无负载均衡的访问模式
Headless Service 不经过 kube-proxy，流量不会自动分发。客户端必须自行处理多 IP 场景。
- Nginx 反向代理需显式配置 resolver 并启用变量解析：
resolver kube-dns.kube-system.svc.cluster.local valid=5s;set $upstream "your-headless-svc.default.svc.cluster.local";proxy_pass http://$upstream; - Java 应用建议用 ServiceComb 或 Spring Cloud Kubernetes 自动监听 Endpoints 变更
- 自研客户端应定期轮询 DNS（TTL 控制刷新频率），缓存 IP 列表并实现本地轮询/随机/权重策略
结合 StatefulSet 实现稳定拓扑标识
当需要节点身份固化（如 Kafka broker ID、ZooKeeper myid），必须搭配 StatefulSet 使用。
- 每个 Pod 获得固定 DNS 名：
<pod-name>.<svc-name>.<namespace>.svc.cluster.local</namespace></svc-name></pod-name> - 例如三副本 StatefulSet
kafka关联 Headless Servicekafka-hs，则 DNS 名为：kafka-0.kafka-hs.default.svc.cluster.localkafka-1.kafka-hs.default.svc.cluster.localkafka-2.kafka-hs.default.svc.cluster.local - 这种命名在 Pod 重建、调度迁移后仍保持不变，上层应用可据此建立静态拓扑关系
