一、容器域名解析的基础流程

容器内的域名解析遵循标准的DNS查询协议，但受限于网络命名空间和Kubernetes的集群环境，其具体实现存在特殊性。解析流程可分为以下四个阶段：

1. 本地缓存查询

当容器内应用发起DNS查询时，首先会检查本地DNS缓存（通常由/etc/hosts文件和内核DNS缓存组成）。若目标域名存在于缓存中，则直接返回对应的IP地址，无需发起网络请求。此阶段的优化点在于：

• 合理配置/etc/hosts文件，将高频访问的服务域名静态映射
• 使用dnsmasq等工具增强本地缓存能力（需通过hostNetwork或自定义DNS配置实现）

2. 容器内DNS解析器

若缓存未命中，解析请求会转发至容器内配置的DNS解析器。在Kubernetes环境中，默认通过kubelet注入的resolv.conf文件指定DNS服务器，典型配置如下：

nameserver 10.96.0.10  # kube-dns服务地址
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

其中ndots:5表示若域名中包含的点数少于5个，则优先在search路径中补全后查询。例如访问mysql会被解析为mysql.default.svc.cluster.local。

3. 上游DNS服务器查询

当容器内DNS解析器无法直接返回结果时，会将请求转发至上游DNS服务器。根据dnsPolicy配置的不同，上游服务器可能为：

• 集群内部DNS（如CoreDNS）：处理svc.cluster.local等集群内域名
• 节点级DNS（如/etc/resolv.conf中的服务器）：处理外部域名
• 自定义DNS：通过dnsConfig指定的外部服务器

4. 递归查询与结果返回

上游DNS服务器可能发起多级递归查询，直至获取权威DNS服务器的响应。最终结果会沿原路径返回至容器内应用，并缓存至本地DNS缓存。

二、dnsPolicy的四种模式详解

Kubernetes通过dnsPolicy字段控制Pod的DNS解析行为，支持以下四种模式：

1. Default：继承节点DNS配置

apiVersion: v1
kind: Pod
metadata:
  name: default-dns-pod
spec:
  containers:
  - name: nginx
    image: nginx
  dnsPolicy: Default  # 显式声明（可省略，默认为此模式）

行为特征：

• 直接使用节点/etc/resolv.conf中的DNS配置
• 适用于需要访问外部域名且不依赖集群DNS的场景
• 风险点：节点DNS配置变更会影响所有继承的Pod

2. ClusterFirst：优先集群内部解析（推荐模式）

spec:
  dnsPolicy: ClusterFirst  # 默认推荐模式
  containers:
  - name: app
    image: my-app

行为特征：

• 优先将查询发送至集群DNS服务（如CoreDNS）
• 若域名匹配search路径中的后缀（如.svc.cluster.local），则由集群DNS处理
• 外部域名（如example.com）会被转发至上游DNS服务器
• 优化建议：配合ndots参数调整，避免不必要的集群DNS查询

3. ClusterFirstWithHostNet：主机网络模式下的集群优先

spec:
  dnsPolicy: ClusterFirstWithHostNet
  hostNetwork: true
  containers:
  - name: host-app
    image: my-app

行为特征：

• 专为hostNetwork: true的Pod设计
• 合并节点DNS配置与集群DNS配置
• 查询顺序：本地缓存 → 集群DNS → 节点DNS
• 典型场景：需要访问主机网络资源同时又要解析集群内服务的DaemonSet

4. None：完全自定义DNS配置

spec:
  dnsPolicy: None
  dnsConfig:
    nameservers:
    - 8.8.8.8
    - 1.1.1.1
    searches:
    - my.domain.com
    options:
    - name: ndots
      value: "2"

行为特征：

• 忽略节点和集群DNS配置
• 完全依赖dnsConfig指定的服务器
• 适用于需要严格隔离DNS环境或使用特定DNS服务商的场景
• 注意事项：需确保自定义DNS能正确解析集群内服务（如通过StubDomains配置）

三、不同dnsPolicy的性能对比与选型建议

性能测试数据（基于1000次DNS查询）

选型决策树

1. 需要访问集群内服务 → 优先选择ClusterFirst
2. 使用主机网络 → 选择ClusterFirstWithHostNet
3. 需要完全控制DNS → 选择None并配置StubDomains
4. 仅访问外部域名 → 可使用Default简化配置

四、常见问题与解决方案

问题1：集群内域名解析超时

原因：CoreDNS资源不足或网络策略阻断
解决方案：

• 调整CoreDNS的副本数和资源限制
• 检查NetworkPolicy是否放行DNS端口（53/udp,53/tcp）

问题2：外部域名解析失败

原因：节点DNS配置错误或自定义DNS不可达
解决方案：

• 对于ClusterFirst模式，检查节点/etc/resolv.conf
• 对于None模式，验证nameservers的连通性

问题3：ndots导致的性能下降

现象：简单域名解析延迟显著高于预期
优化方法：

• 在Pod的dnsConfig中设置ndots:2
• 或在应用代码中使用完全限定域名（FQDN）

五、最佳实践总结

1. 生产环境推荐：90%场景使用ClusterFirst，配合合理的ndots设置
2. 自定义DNS场景：通过dnsConfig的searches和options实现精细控制
3. 监控建议：通过Prometheus监控CoreDNS的请求延迟和错误率
4. 安全加固：限制DNS查询的目标范围，防止DNS投毒攻击

通过深入理解容器域名解析流程和dnsPolicy的影响机制，开发者可以更高效地诊断DNS相关问题，并根据业务需求选择最优的配置方案。