k8s查看dns

Kubernetes（K8s）查看DNS详解

理解K8s中的DNS机制

在Kubernetes集群中，DNS服务是实现服务发现的核心组件，它允许Pod通过域名而非IP地址相互访问，简化了内部通信的复杂性，默认情况下，K8s使用CoreDNS（旧版本为kubedns）作为集群范围内的DNS解析系统，每个Service会被自动分配一个格式为<servicename>.<namespace>.svc.cluster.local的内部域名，该域名最终解析到对应的Cluster IP地址上,以下是详细的查看和验证步骤：

检查DNS组件状态

1. 查看DNS Pod运行情况
   执行命令列出kubesystem命名空间下标记为k8sapp=kubedns的所有Pod：

   kubectl get pods n kubesystem l k8sapp=kubedns

   正常输出应显示状态为Running且READY值为1/1，若状态异常,需进一步排查日志或事件原因。

   NAME                    READY   STATUS    RESTARTS   AGE
   coredns5c98db65d42j6kq   1/1     Running   0          7d

2. 确认DNS Service配置
   通过以下命令获取名为kubedns的服务详情，重点关注其ClusterIP（即集群内所有Pod使用的DNS服务器地址）：

   kubectl get svc n kubesystem kubedns

   典型结果如下：

   NAME       TYPE        CLUSTERIP    EXTERNALIP   PORT(S)         AGE
   kubedns   ClusterIP   10.96.0.10    <none>        53/UDP,53/TCP   30d

   这里的96.0.10即为集群内部的DNS入口点。

分析CoreDNS配置

CoreDNS的行为由ConfigMap定义,可通过以下命令查看完整配置：

kubectl get configmap n kubesystem coredns o yaml

关键段落如：

data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local inaddr.arpa ip6.arpa {
            pods insecure
            fallthrough inaddr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

重点关注两个参数：

• forward . /etc/resolv.conf：表示继承节点宿主机的上游DNS服务器设置；
• kubernetes cluster.local插件：确保对cluster.local域内的Service进行正确解析。

验证DNS解析功能

1. 临时Pod测试法
   启动一个带有交互终端的BusyBox容器，直接执行nslookup命令测试特定服务的解析：

   kubectl run it rm restart=Never dnstest image=busybox:1.28 nslookup kubernetes.default

   预期输出类似：

   Server:    10.96.0.10
   Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

   此结果表明成功将kubernetes.default解析为对应的Cluster IP。

2. 使用专用工具镜像深度检测
   若需更专业的诊断，可采用包含dig命令的专用镜像（如gcr.io/kubernetese2etestimages/dnsutils:1.3）：

   kubectl run it rm restart=Never dnsutils image=gcr.io/kubernetese2etestimages/dnsutils:1.3 dig kubernetes.default.svc.cluster.local

   该命令不仅能验证基础连通性，还能展示完整的DNS应答包结构，便于排查TTL、授权记录等高级属性。

检查Pod层面的DNS策略

每个Pod均可独立配置DNS行为，常见策略包括：
| 策略类型 | 说明 | 适用场景 |
||||
| Default | 继承宿主机的/etc/resolv.conf | 未指定时的默认行为 |
| ClusterFirst | 优先使用集群内DNS，失败后回退至宿主机解析 | 绝大多数常规应用 |
| None | 完全忽略集群DNS，仅依赖自定义配置（需配合spec.dnsConfig字段使用） | 特殊网络隔离需求的场景 |

查看具体Pod的配置可用：

kubectl get pod <podname> o yaml | grep i dns

输出示例：

dnsPolicy: ClusterFirst
dnsConfig: null

对于需要自定义解析规则的场景,可在Pod规约中添加如下片段：

spec:
  dnsPolicy: None
  dnsConfig:
    nameservers: [ "8.8.8.8", "8.8.4.4" ]
    searches: ["example.com"]
    options: [{"name": "ndots", "value": "2"}]

此配置将强制Pod使用指定的公共DNS服务器,并调整搜索后缀优先级。

排查常见问题指南

当遇到DNS解析失败时,建议按以下顺序进行故障排除：

1. 确认CoreDNS容器健康状态：检查Pod是否存活及重启次数；
2. 校验上游传递链：确保forward配置指向有效的外部DNS；
3. 审查网络策略限制：某些CNI插件可能阻断53端口通信；
4. 比对宿主机配置：节点上的/etc/resolv.conf会影响CoreDNS的转发能力；
5. 启用调试日志：临时修改Corefile增加log插件以记录详细查询轨迹。

相关问题与解答

Q1: 如果修改了Node的/etc/resolv.conf文件会影响哪些组件？如何安全更新？
A: 由于CoreDNS的forward配置默认读取节点的解析文件，变更会影响所有依赖集群DNS的服务，建议通过修改ConfigMap中的forward条目统一管理上游DNS，避免直接改动宿主机配置，例如将forward . /etc/resolv.conf改为forward . 8.8.8.8可固定使用谷歌公共DNS作为上游服务器。

Q2: Headless Service的DNS行为为什么不同于普通Service？
A: Headless Service不分配Cluster IP，而是直接返回目标Pod的IP列表，这类服务的DNS记录类型为SRV而非A记录，适用于需要直接连接多个后端实例的场景（如StatefulSet控制的数据库主从复制），可通过kubectl get svc myheadless o jsonpath='{.spec.clusterIP}'验证其IP值为