为何K8s中跨命名空间DNS可达性依赖Pod定义类型？

差异产生的核心原因 #

1. DNS记录类型与维护逻辑不同 #

• 普通Pod+NodePort Service的DNS（如mongo.mongo.ns0.svc.cluster.local）对应Service的ClusterIP A记录，由KubeDNS/CoreDNS在集群全局DNS域下维护，所有命名空间默认都能直接解析——因为Service是集群级的流量入口，不管后端Pod状态如何，该DNS记录始终存在。
• StatefulSet Pod的专属DNS（如mongo-0.mongo.ns0.svc.cluster.local）是Headless Service关联的Pod A记录，它的生成依赖两个关键条件：
  • 必须存在与StatefulSet的subdomain字段匹配的Headless Service（即spec.clusterIP: None）；
  • 该A记录仅在Pod所属命名空间的DNS域下生成，且默认仅当Pod处于Ready状态时才会被CoreDNS发布到集群DNS中。

2. Headless Service的默认行为限制 #

Headless Service默认只会将就绪（Ready）状态的Pod的DNS记录同步到集群DNS。如果你的Mongo Pod还在副本集初始化阶段（未进入Ready状态），那么只有本命名空间内的Pod可以通过Pod IP直接访问（同命名空间内Kubernetes有本地DNS解析逻辑），但跨命名空间无法通过DNS解析到该Pod。而普通Service不管Pod是否就绪，都会指向固定的ClusterIP，流量由kube-proxy转发。

实现稳定跨命名空间访问的解决方案 #

1. 配置Headless Service并开启未就绪Pod的DNS发布 #

修改Headless Service的配置，添加publishNotReadyAddresses: true，这样即使Pod未就绪，CoreDNS也会生成对应的A记录，确保跨命名空间能解析到：

apiVersion: v1
kind: Service
metadata:
  name: mongo
  namespace: ns0
spec:
  clusterIP: None
  publishNotReadyAddresses: true # 关键配置
  ports:
    - port: 27017
      targetPort: 27017
  selector:
    app: mongo # 匹配StatefulSet的Pod标签

2. 验证跨命名空间解析 #

在ns1的任意Pod中执行以下命令验证解析：

nslookup mongo-0.mongo.ns0.svc.cluster.local

若仍无法解析，检查CoreDNS的ConfigMap配置，确保未被修改为限制跨命名空间解析的规则（默认CoreDNS配置允许完整域名的跨命名空间解析）。

3. 可选：为单个Pod创建独立Service（非负载均衡） #

如果需要更简洁的DNS名称，可以为每个StatefulSet Pod创建单独的ClusterIP Service（无负载均衡），示例配置如下：

apiVersion: v1
kind: Service
metadata:
  name: mongo-0
  namespace: ns0
spec:
  type: ClusterIP
  ports:
    - port: 27017
      targetPort: 27017
  selector:
    statefulset.kubernetes.io/pod-name: mongo-0 # 精准匹配单个Pod

该Service的DNSmongo-0.ns0.svc.cluster.local可直接跨命名空间访问，但需要手动维护每个Pod对应的Service，适合节点数量固定的场景。

内容的提问来源于stack exchange，提问作者JimmyJames