容器中域名解析流程以及不同dnsPolicy对域名解析影响

一、容器域名解析的底层逻辑

容器环境中的域名解析是连接应用与网络服务的关键环节，其核心流程可分为三个阶段：

1. 本地缓存查询
   容器内的应用首先查询本地DNS缓存（通过/etc/hosts文件和内存缓存），若存在匹配记录则直接返回IP地址。例如，当容器内应用访问my-service.default.svc.cluster.local时，会优先检查本地缓存。

2. DNS解析器处理
   若缓存未命中，请求会转发至容器内配置的DNS解析器（通常为/etc/resolv.conf中指定的nameserver）。在Kubernetes环境中，此解析器默认指向kube-dns或CoreDNS服务（IP为10.96.0.10）。

3. 上游DNS查询
   解析器根据域名后缀决定查询路径：

   • 集群内部域名（如.svc.cluster.local）：直接查询Kubernetes DNS服务，通过ETCD存储的Service记录解析。
   • 外部域名（如example.com）：若配置了ndots（默认5），且域名中点数少于阈值，会优先尝试集群DNS；否则通过/etc/resolv.conf中的nameserver转发至外部DNS（如8.8.8.8）。

关键验证点：
通过strace -e open,connect nslookup my-service可跟踪解析过程，确认是否优先查询集群DNS。

二、dnsPolicy的四种模式详解

Kubernetes通过dnsPolicy字段控制容器的DNS行为，四种模式对解析流程的影响如下：

1. ClusterFirst（默认模式）

• 行为：优先查询集群DNS（kube-dns/CoreDNS），外部域名通过/etc/resolv.conf的nameserver转发。
• 适用场景：大多数集群内服务通信。
• 配置示例：

  apiVersion: v1
  kind: Pod
  metadata:
    name: default-policy
  spec:
    containers:
    - name: nginx
      image: nginx
    dnsPolicy: ClusterFirst  # 默认值，可省略

• 潜在问题：若集群DNS故障，外部域名解析可能超时。建议配置dnsConfig.nameservers作为备用。

2. ClusterFirstWithHostNet

• 行为：当容器使用hostNetwork: true时，强制继承宿主机的DNS配置，但优先查询集群DNS。
• 适用场景：需要访问宿主机网络且依赖集群服务（如DaemonSet）。
• 配置示例：

  apiVersion: v1
  kind: Pod
  metadata:
    name: host-network
  spec:
    hostNetwork: true
    dnsPolicy: ClusterFirstWithHostNet
    containers:
    - name: busybox
      image: busybox

• 验证方法：进入容器执行cat /etc/resolv.conf，确认包含集群DNS和宿主机DNS。

3. Default

• 行为：直接继承节点（Node）的DNS配置（/etc/resolv.conf），不经过集群DNS。
• 适用场景：容器需完全绕过Kubernetes DNS体系（如访问外部专用DNS）。
• 风险点：无法解析集群内部域名（如.svc.cluster.local），可能导致服务间通信失败。
• 配置示例：

  apiVersion: v1
  kind: Pod
  metadata:
    name: default-policy
  spec:
    containers:
    - name: nginx
      image: nginx
    dnsPolicy: Default  # 显式声明

4. None

• 行为：完全忽略节点和集群DNS，需通过dnsConfig手动指定所有DNS参数。
• 适用场景：需要自定义DNS服务器、搜索域或选项（如ndots调整）。
• 配置示例：

  apiVersion: v1
  kind: Pod
  metadata:
    name: custom-dns
  spec:
    containers:
    - name: nginx
      image: nginx
    dnsPolicy: None
    dnsConfig:
      nameservers:
      - "8.8.8.8"
      - "1.1.1.1"
      searches:
      - "custom.domain.com"
      options:
      - name: ndots
        value: "2"

• 优化建议：结合ndots: 2可减少外部域名查询的集群DNS转发，提升性能。

三、性能优化与故障排查

1. 解析延迟优化

• 调整ndots：默认ndots:5可能导致不必要的集群DNS查询。对于外部域名较多的应用，建议设置为ndots:2。

  dnsConfig:
    options:
    - name: ndots
      value: "2"

• 本地缓存：在容器内运行nscd或dnsmasq缓存DNS结果，减少重复查询。

2. 常见问题排查

• 问题1：集群内部域名无法解析
  原因：dnsPolicy设置为Default或集群DNS服务异常。
  解决：检查Pod的dnsPolicy，确认kube-dns/CoreDNS的Endpoint是否健康。

• 问题2：外部域名解析超时
  原因：上游DNS服务器不可达或ndots设置过高。
  解决：通过kubectl exec进入容器，手动执行nslookup example.com验证解析路径；调整dnsConfig.nameservers或ndots。

四、最佳实践总结

1. 默认场景：使用ClusterFirst，无需额外配置。
2. 外部服务为主：采用dnsPolicy: None + 自定义nameservers和ndots:2。
3. 监控与告警：通过Prometheus监控coredns_dns_request_duration_seconds指标，及时发现解析异常。
4. 安全加固：限制dnsConfig.nameservers为可信DNS（如168.95.1.1），防止DNS劫持。

通过合理选择dnsPolicy并优化配置，可显著提升容器应用的网络稳定性和性能。开发者应根据实际场景权衡灵活性（如None）与便利性（如ClusterFirst），避免因DNS配置不当导致服务中断。