Kubernetes Service 怎样选择 headless 服务发现

Kubernetes Service 要不要选择 headless，先看客户端需要的是“一个稳定的虚拟入口”，还是“直接拿到每个 Pod 的地址”。如果需要 kube-proxy 代理、ClusterIP 和平台层负载均衡，保留普通的 ClusterIP；如果客户端或外部服务发现机制必须看到 Pod IP，就把 spec.clusterIP 明确设为 None。后续还要根据后端是否由 Kubernetes selector 管理，决定保留还是去掉 selector。

官方地址：https://kubernetes.io/docs/concepts/services-networking/service/

headless Service 不是“性能更高的 ClusterIP”，而是取消虚拟 IP、代理和平台负载均衡，让集群 DNS 返回后端 Pod 的地址。选择前先确认客户端能处理多地址，以及连接、重试和摘除逻辑由谁负责。

headless Service 的选择先看流量模型

现场触发信号通常是 StatefulSet、数据库节点或自带服务发现的客户端要求“看到每个实例”，而不是只访问一个虚拟地址。普通 Service 会分配 ClusterIP，由 kube-proxy 或集群中的等价实现完成转发；headless Service 不分配 ClusterIP，也不配置平台代理和负载均衡，DNS 直接暴露后端 Pod 地址。

因此，选择前先问三个问题：客户端能否轮询多个 A 或 AAAA 记录；它是否自己负责连接重试和节点摘除；后端是否必须由 Kubernetes 的 label selector 自动跟踪。只要客户端只接受一个固定地址，或者希望由平台统一做服务级转发，就不要为了“少一层”贸然改成 headless。

用 clusterIP: None 明确配置，并决定是否保留 selector

有 selector 的场景适合由 Deployment 或 StatefulSet 管理 Pod。下面的配置让 Service 按 app: catalog 找到后端，DNS 再返回这些 Pod 的地址：

apiVersion: v1
kind: Service
metadata:
  name: catalog-peer
spec:
  # None 是 headless 的显式值，不是省略 clusterIP。
  clusterIP: None
  selector:
    # 这个标签必须与后端 Pod 的 metadata.labels 对齐。
    app: catalog
  ports:
    - name: peer
      protocol: TCP
      port: 8080
      targetPort: 8080

如果地址由集群外部系统、手工维护的 IP 或其他服务发现机制提供，则可以去掉 selector，改由 EndpointSlice 或可用的外部端点关系承载。无 selector 的 headless Service 不能依赖控制器自动从 Pod 标签推导地址；另外，官方文档明确要求这种配置的 port 与 targetPort 相同。

用 EndpointSlice 和 DNS 确认选择生效

先看 Service 的实际规格，再看后端是否有就绪地址。命令输出在这里是排查方法示例，不是线上运行截图：

# 先确认 clusterIP、selector 和端口没有被渲染工具改写。
kubectl -n default get svc catalog-peer -o yaml

# 有 selector 时，按 Service 名称过滤 EndpointSlice。
kubectl -n default get endpointslice \
  -l kubernetes.io/service-name=catalog-peer -o wide

# 从集群内临时诊断 Pod 查询完整服务名，观察是否返回多个地址。
kubectl -n default run dns-check --rm -it --restart=Never \
  --image=busybox:1.36 -- nslookup catalog-peer.default.svc.cluster.local

有 selector 时，EndpointSlice 没有地址通常先查 Pod 标签和 readiness，而不是先重启 CoreDNS。DNS 解析成功但连接失败，则继续核对容器监听地址、NetworkPolicy 和 Service 端口。无 selector 时，检查 ready endpoint 是否存在、地址类型是否正确，以及 port 和 targetPort 是否一致。

回滚路径：先恢复单一入口，再处理客户端缓存

headless 切换造成故障时，回滚不是只把 None 删除。先把 Service 恢复为普通 ClusterIP，并确认客户端使用的端口与 selector 不变：

# 回滚前保存当前定义，便于复盘差异和恢复原端口。
kubectl -n default get svc catalog-peer -o yaml > /tmp/catalog-peer.before.yaml

# 恢复普通 Service，让集群重新分配虚拟IP；生产环境先走变更审批。
kubectl -n default patch svc catalog-peer \
  --type=merge -p '{"spec":{"clusterIP":null}}'

# 观察新的 ClusterIP 与端点，避免只看 Service 对象存在。
kubectl -n default get svc catalog-peer
kubectl -n default get endpointslice \
  -l kubernetes.io/service-name=catalog-peer -o wide

实际回滚方式要结合资源是否允许重建、客户端 DNS 缓存和控制器管理策略；不要在生产集群直接照抄 patch。若客户端已经缓存多个 Pod 地址，切回 ClusterIP 后仍可能短时间命中旧结果，应配合连接池刷新或应用重启窗口。

告警确认与复盘清单

复盘至少记录：为什么需要直连 Pod、selector 是否仍由控制器管理、客户端是否支持多地址、EndpointSlice 变化是否有监控、回滚是否会受 DNS 缓存影响。这样下次遇到“解析正常但请求失败”，能快速区分发现层、网络层和应用层。

相关问题

clusterIP 留空能不能得到 headless Service

不能。headless 需要显式写 clusterIP: None；留空表示让 Kubernetes 按普通 Service 规则处理。

headless Service 会不会自动做负载均衡

不会。平台不提供虚拟IP代理和 Service 级负载均衡，客户端或上层服务发现组件需要自行处理多地址、重试和摘除。

没有 selector 时为什么要检查 port 和 targetPort

无 selector 的 headless Service 没有 Pod 标签控制器替你对齐目标端口，官方规则要求两者匹配，否则 DNS 有地址也可能连不上正确的端口。

最终判断可以压缩成一句话：需要平台代理就选普通 ClusterIP，需要直接发现实例就选 clusterIP: None；选定后，再用 selector、EndpointSlice 和 DNS 三层证据确认它真的指向了预期后端。