Kubernetes Service DNS 解析全解析：格式、规则与实战指南

在 Kubernetes 微服务架构中，服务发现是通信的基石。而 DNS 机制正是 Kubernetes 实现“服务即域名”理念的核心——无需硬编码 IP，只需一个简洁域名，即可优雅定位服务。本文将带你彻底掌握 Service DNS 的命名逻辑、解析规则与实战技巧。

---

🌐 一、DNS 服务：集群的“电话簿”

Kubernetes 集群默认部署 CoreDNS（旧版为 kube-dns）作为内部 DNS 服务器：

• 所有 Pod 的 /etc/resolv.conf 自动配置集群 DNS 地址
• 搜索域（search domains）通常包含：
  default.svc.cluster.local svc.cluster.local cluster.local
• 这使得在 Pod 内可使用简短名称（如 web）而非完整 FQDN 访问服务

💡 提示：可通过 kubectl get configmap coredns -n kube-system -o yaml 查看 CoreDNS 配置

---

📛 二、Service DNS 标准格式（核心公式）

<service-name>.<namespace>.svc.<cluster-domain>

组成部分	说明	示例
service-name	Service 的 metadata.name	nginx-service
namespace	Service 所在命名空间	production
svc	固定标识，表示 Service 资源	—
cluster-domain	集群域名（默认 cluster.local）	cluster.local

✅ 完整 FQDN 示例：
nginx-service.production.svc.cluster.local

⚠️ 注意：集群域名可通过 kubelet --cluster-domain 参数自定义（如 k8s.local），需与 CoreDNS 配置一致

---

🔍 三、多场景解析规则详解

✅ 场景 1：同命名空间内访问

# 在 production 命名空间的 Pod 中
curl http://nginx-service:80
# 自动补全为：nginx-service.production.svc.cluster.local

✅ 推荐：直接使用 Service 名，简洁高效

✅ 场景 2：跨命名空间访问

# 在 default 命名空间访问 production 中的 nginx-service
curl http://nginx-service.production:80
# 补全逻辑：nginx-service.production.svc.cluster.local

✅ 推荐：<service>.<namespace> 格式，清晰且兼容搜索域

✅ 场景 3：Headless Service（无头服务）

当 spec.clusterIP: None 时：

• DNS 不返回 ClusterIP，而是直接返回所有匹配 Pod 的 IP 列表（多条 A 记录）
• 适用于 StatefulSet、需要直连 Pod 的场景（如数据库集群）

nslookup headless-db.default.svc.cluster.local
# 返回：
# Name: headless-db.default.svc.cluster.local
# Address: 10.244.1.5
# Address: 10.244.2.8
# Address: 10.244.3.12

✅ 场景 4：SRV 记录——动态端口发现

为 Service 中命名端口生成 SRV 记录：

_<port-name>._<protocol>.<service-name>.<namespace>.svc.cluster.local

# Service 定义了 name: http, port: 8080
nslookup -type=SRV _http._tcp.myapp.default.svc.cluster.local
# 返回：0 100 8080 myapp.default.svc.cluster.local.

✅ 适用：客户端需动态获取端口号的场景（如 gRPC 服务发现）

---

🧪 四、实战验证（附命令）

1. 部署测试 Service

# test-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: demo-svc
  namespace: demo
spec:
  selector:
    app: demo-app
  ports:
    - name: http
      port: 8080
      targetPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: debug-pod
  namespace: default
spec:
  containers:
  - name: dnsutils
    image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3
    command: ["sleep", "3600"]

2. 进入调试 Pod 验证

kubectl exec -it debug-pod -- sh

# 同命名空间访问（需在 demo 命名空间内测试）
nslookup demo-svc.demo          # 跨 ns 简写
nslookup demo-svc.demo.svc.cluster.local  # 完整 FQDN

# SRV 记录查询
nslookup -type=SRV _http._tcp.demo-svc.demo.svc.cluster.local

# Headless Service 验证（部署后）
nslookup headless-svc.test      # 观察返回多个 IP

---

⚠️ 五、避坑指南 & 最佳实践

问题	建议
名称含特殊字符	Service/NS 名仅用小写字母、数字、-，避免 _（DNS 非法字符）
环境变量过时	优先用 DNS！环境变量在 Pod 启动时注入，无法感知后续创建的 Service
DNS 策略异常	检查 Pod dnsPolicy（默认 ClusterFirst），HostNetwork Pod 需设为 ClusterFirstWithHostNet
解析失败排查	1. 检查 Service 是否存在 kubectl get svc -n <ns> 2. 进入 Pod 用 nslookup/dig 测试 3. 检查 CoreDNS 日志 kubectl logs -l k8s-app=kube-dns -n kube-system
自定义集群域名	确保 kubelet、CoreDNS、kube-proxy 配置统一

---

💎 总结

Kubernetes Service DNS 是微服务通信的“隐形桥梁”：

• 标准格式：<svc>.<ns>.svc.<domain> 是理解一切的基础
• 智能补全：搜索域机制让跨命名空间调用简洁优雅
• 场景全覆盖：ClusterIP、Headless、SRV 记录满足不同架构需求
• 优于环境变量：动态、跨命名空间、符合云原生设计哲学

掌握 DNS 规则，不仅能提升开发效率，更是排查服务通信问题的关键能力。下次当你写下 curl user-service.auth 时，你会知道——背后是 Kubernetes 精巧的 DNS 机制在默默护航 🌟

📚 延伸阅读

• Kubernetes 官方文档：DNS for Services and Pods
• CoreDNS 配置最佳实践
• 《Kubernetes in Action》第 5 章：服务与网络

本文基于 Kubernetes v1.25+ 验证，集群配置可能存在差异，请以实际环境为准。