4. DNS故障场景分类:CoreDNS Pod故障、网络策略阻断、集群DNS配置错误、上游DNS不可达
在Kubernetes集群中,DNS解析是服务发现与通信的基石。当DNS链路出现故障时,Pod之间的通信、Service的域名解析、甚至集群自身的健康检查都会受到影响。本章将DNS故障划分为四大类,分别对应集群内部组件、网络控制层、配置管理层以及外部依赖层。理解这些故障的根因与表现,是后续进行Helm部署架构适配的前提。
4.1 故障分类总览
下表从故障层次、典型表现、影响范围三个维度对四类DNS故障进行对比,帮助快速建立全局认知。
| 故障类别 | 故障层次 | 典型表现 | 影响范围 |
|---|---|---|---|
| CoreDNS Pod故障 | 集群内部组件 | Pod CrashLoopBackOff、OOM、就绪探针失败 | 整个集群或特定命名空间的DNS解析中断 |
| 网络策略阻断 | 网络控制层 | Pod无法访问CoreDNS Service IP、DNS查询超时 | 被NetworkPolicy选中的Pod或命名空间 |
| 集群DNS配置错误 | 配置管理层 | Pod的resolv.conf中nameserver指向错误、search域缺失 | 新创建的Pod或特定工作负载 |
| 上游DNS不可达 | 外部依赖层 | 外部域名解析失败、CoreDNS日志显示连接超时 | 需要解析集群外部域名的所有Pod |
4.2 CoreDNS Pod故障
CoreDNS作为集群内部的DNS服务器,通常以Deployment形式运行在kube-system命名空间中。Pod级别的故障是最直接的DNS中断原因,常见于以下场景:
- 资源耗尽(OOM):当集群中Pod数量激增或DNS查询量突增时,CoreDNS Pod的内存限制设置过低会导致OOMKilled。
- 配置语法错误:通过Helm升级CoreDNS时,若
Corefile配置段存在语法错误,CoreDNS进程将无法启动。 - 就绪探针失败:CoreDNS的
readinessProbe依赖插件响应,若插件挂起或死锁,Pod会被标记为未就绪,从Service Endpoints中移除。
排查要点: 使用
kubectl get pods -n kube-system -l k8s-app=kube-dns 查看Pod状态;通过 kubectl logs -n kube-system <coredns-pod> 检查日志中的插件错误或OOM事件。
4.3 网络策略阻断
Kubernetes NetworkPolicy 可以精细控制Pod之间的网络流量。当NetworkPolicy规则配置不当或过于严格时,会阻断Pod到CoreDNS Service的DNS查询流量。
- 出站规则缺失:应用Pod的命名空间若定义了出站NetworkPolicy,但未显式允许访问
kube-system命名空间中CoreDNS Service的UDP/TCP 53端口,DNS查询将被丢弃。 - 入站规则缺失:CoreDNS Pod所在命名空间若配置了入站NetworkPolicy,但未允许来自其他命名空间的DNS查询流量,同样会导致解析失败。
- CIDR限制:使用基于IP段的策略时,若Pod的IP不在允许范围内,也会被阻断。
常见误区: 很多团队只关注应用层的NetworkPolicy,却忽略了
kube-system命名空间自身的入站策略。在零信任网络模型中,必须为CoreDNS显式添加允许所有命名空间访问53端口的入站规则。
4.4 集群DNS配置错误
集群DNS配置错误通常发生在Pod的resolv.conf生成阶段,由kubelet或集群管理工具(如Helm)的配置不当引起。
- nameserver指向错误:Pod的
/etc/resolv.conf中nameserver字段应指向CoreDNS Service的Cluster IP(通常为10.96.0.10)。若被错误修改为其他IP,DNS解析将指向错误的服务器。 - search域缺失:默认情况下,Pod的
search域应包含<namespace>.svc.cluster.local、svc.cluster.local等。若search域配置不完整,短域名(如my-service)将无法被正确解析。 - ndots值异常:
ndots参数控制域名中“.”的数量阈值,默认值为5。若被错误设置为0或过大,会导致DNS查询路径异常,增加解析延迟或失败概率。
Helm部署建议: 在Helm Chart的values中,可以通过
global.dns.nameservers 和 global.dns.searchDomains 参数统一控制Pod的DNS配置。务必在部署前验证这些值是否与集群实际DNS Service IP一致。
4.5 上游DNS不可达
CoreDNS支持将无法解析的集群内部域名转发到上游DNS服务器(如云厂商的VPC DNS、自建BIND等)。当上游DNS不可达时,所有外部域名的解析都会失败。
- 上游服务器宕机:上游DNS服务器因维护、故障或过载而无法响应。
- 网络连通性问题:CoreDNS Pod所在节点到上游DNS服务器的网络路径中断,例如防火墙规则、路由表错误或VPN隧道断开。
- 转发配置错误:CoreDNS的
forward插件配置中,上游地址写错、端口错误或使用了不支持的协议。
下图展示了四类DNS故障在集群架构中的位置与影响路径:
4.6 故障影响对比
不同故障类型对集群的影响范围与恢复手段存在显著差异。下表从影响范围、恢复手段、Helm适配策略三个维度进行对比:
| 故障类型 | 影响范围 | 典型恢复手段 | Helm适配策略 |
|---|---|---|---|
| CoreDNS Pod故障 | 全局或命名空间级 | 调整资源限制、回滚Corefile配置、重启Pod | 设置PodDisruptionBudget、配置资源请求/限制、启用HPA |
| 网络策略阻断 | 特定Pod或命名空间 | 修改NetworkPolicy规则、添加允许规则 | 在Helm Chart中预置DNS访问策略模板 |
| 集群DNS配置错误 | 新创建的Pod | 修正kubelet配置、更新Pod的dnsConfig | 通过values统一管理dnsPolicy和dnsConfig |
| 上游DNS不可达 | 外部域名解析 | 修复网络连通性、更换上游DNS地址 | 配置多个上游DNS、启用缓存插件 |
4.7 故障诊断命令速查
以下命令可用于快速定位上述四类DNS故障:
# 检查CoreDNS Pod状态
kubectl get pods -n kube-system -l k8s-app=kube-dns
# 查看CoreDNS日志
kubectl logs -n kube-system deployment/coredns --tail=50
# 测试Pod内DNS解析
kubectl run test-dns --image=busybox:1.28 --rm -it -- nslookup kubernetes.default.svc.cluster.local
# 检查NetworkPolicy是否阻断
kubectl describe networkpolicy -n <namespace>
# 查看Pod的resolv.conf
kubectl exec <pod-name> -- cat /etc/resolv.conf
# 测试上游DNS连通性(从CoreDNS Pod内)
kubectl exec -n kube-system <coredns-pod> -- nslookup www.baidu.com
最佳实践: 在Helm部署的values中,建议将CoreDNS的副本数设置为至少2个,并配置反亲和性策略,避免单点故障。同时,为CoreDNS启用
cache插件,可以在上游DNS短暂不可用时提供缓存解析,提升容错能力。