kube-dns高可用故障咨询：节点宕机引发DNS请求失败的非应用层缓解方案

针对你遇到的kube-dns节点宕机后约1/3请求失败的问题，这里有几个无需修改业务代码的非应用层缓解方案，直接从集群或容器层面调整即可：

1. 缩短节点故障检测与端点更新周期 #

Kubernetes默认需要约60秒（node-monitor-grace-period默认40s + 端点同步延迟）才会移除失效节点上的kube-dns端点。你可以通过调整核心组件参数来压缩这个时间窗口：

• 修改kube-controller-manager的启动参数：
  • 降低--node-monitor-grace-period（默认40s）至20s：这是控制器等待节点状态更新的最长时限，超时后会直接标记节点为NotReady
  • 降低--node-status-update-frequency（默认10s）至5s：让kubelet更频繁地向集群上报节点状态
• 同步调整kube-proxy的--sync-period（默认30s）至10s：加快kube-proxy同步端点变化到iptables规则的速度，减少请求命中失效端点的概率

注意：不要把这些值设得过低，避免因网络波动导致误判节点故障。

2. 配置容器DNS客户端的重试与超时策略 #

容器默认的DNS配置（resolv.conf）重试次数有限，你可以全局或针对Pod调整参数，让客户端自动重试失效的DNS请求：

• 全局配置：修改kubelet的--resolv-conf参数，指向自定义的resolv.conf文件，添加options timeout:2 attempts:3，让DNS请求在2秒超时后最多重试3次，覆盖到可用的kube-dns端点
• 单Pod配置：在Pod的spec中添加dnsConfig字段，精准控制该Pod的DNS行为：

  dnsConfig:
    options:
      - name: timeout
        value: "2"
      - name: attempts
        value: "3"
  

这样即使第一次请求打到失效的kube-dns端点，客户端会自动重试其他健康节点，大幅降低失败概率。

3. 给kube-dns配置探针与Pod中断预算 #

虽然节点宕机时kubelet无法执行探针，但给kube-dns Pod配置ReadinessProbe和LivenessProbe，能确保Pod自身故障时快速从Service端点中移除；再配合PodDisruptionBudget，保障始终有足够的可用副本：

• 给kube-dns的Deployment添加探针配置：

  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
      scheme: HTTP
    initialDelaySeconds: 60
    timeoutSeconds: 5
    periodSeconds: 10
    failureThreshold: 5
  readinessProbe:
    httpGet:
      path: /readiness
      port: 8081
      scheme: HTTP
    initialDelaySeconds: 30
    timeoutSeconds: 5
    periodSeconds: 10
  

• 配置PodDisruptionBudget：

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: kube-dns-pdb
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        k8s-app: kube-dns
  

4. 切换到CoreDNS（可选） #

如果你的集群仍在使用kube-dns，建议切换到CoreDNS（当前K8s默认的DNS组件）。CoreDNS内置了更智能的负载均衡和故障转移机制，比如loadbalance插件会自动跳过失效后端，默认重试策略也更友好，能从根源上降低节点宕机时的DNS请求失败率。

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