Kubernetes Pod中/etc/resolv.conf的rotate选项不生效问题

核心原因 #

你的resolv.conf配置本身无语法问题，但始终仅使用第一个nameserver的情况，主要来自三个方面：测试工具的局限性、K8s对resolv.conf的管理逻辑、以及DNS解析的触发条件。

1. 测试工具nslookup的行为限制 #

多数版本的nslookup并不遵循resolv.conf的rotate选项——它默认只会调用列表中的第一个nameserver发起请求，不会自动执行轮询逻辑。要验证rotate是否真的生效，建议换用以下方式：

• 使用dig +rotate example.com：+rotate参数会强制dig遵循轮询策略，多次执行后可观察到请求交替发送到两个nameserver。
• 编写简单测试脚本：通过调用遵循resolv.conf配置的标准解析接口（如libc的getaddrinfo），例如：

  import socket
  for _ in range(5):
      print(socket.getaddrinfo("example.com", 80))
  

  多次执行后，查看返回结果中的解析服务器是否轮询切换。

2. K8s对Pod resolv.conf的自动覆盖 #

如果是手动修改Pod内的resolv.conf，Pod重启后配置会被K8s自动重置——K8s会根据Pod的dnsPolicy和dnsConfig字段重新生成配置文件。要确保rotate和多nameserver配置持久生效，必须在Pod的Deployment/StatefulSet定义中添加dnsConfig：

spec:
  containers:
  - name: your-container
    # ... 其他容器配置
  dnsConfig:
    nameservers:
      - 10.96.0.10
      - 8.8.8.8
    searches:
      - measurement.svc.cluster.local
      - svc.cluster.local
      - cluster.local
    options:
      - name: rotate
      - name: timeout
        value: "1"
      - name: ndots
        value: "5"

应用该配置后，K8s会自动生成符合要求的resolv.conf，且Pod重启后配置不会丢失。

3. DNS解析的触发逻辑 #

rotate选项的作用是轮询选择第一个尝试的nameserver，但如果第一个nameserver能正常返回解析结果（比如你的集群CoreDNS可解析绝大多数域名），系统不会尝试第二个nameserver。只有当第一个nameserver超时（你的配置是timeout:1，即1秒超时）或返回错误时，才会切换到第二个。

要验证这一点，可以：

• 解析一个CoreDNS无法处理的外部小众域名，观察是否会触发第二个nameserver。
• 临时停止一个CoreDNS Pod，模拟第一个nameserver不可用的场景，测试解析是否会切换到8.8.8.8。

与CoreDNS的关系 #

CoreDNS本身不会干扰resolv.conf的rotate策略——它只是作为第一个nameserver提供解析服务。只有当CoreDNS无法响应时，rotate配置才会触发第二个nameserver的使用。如果你的测试场景中CoreDNS总能正常返回结果，自然不会用到第二个nameserver。

内容的提问来源于stack exchange，提问作者Bhavya Sharma