【网络实战】CCE集群DNS解析偶发5秒超时：NodeLocal DNSCache的工程解法

在 K8s/CCE 环境压测时，业务日志中常会出现间歇性的外部 API 调用超时。抓包排查后往往会发现一个反直觉的现象：并非网络不通，而是 DNS 解析耗费了整整 5 秒。

核心痛点： 这是 K8s 极经典的底层网络陷阱。容器默认的 resolv.conf 中包含 ndots:5，意味着查询任何包含点号少于 5 个的域名（如 api.weixin.qq.com），系统都会疯狂拼接集群内部的 Search Domain 发起多次无效查询。更致命的是，高并发下的 Linux Conntrack（连接跟踪）表容易溢出，导致 DNS 基础的 UDP 报文被内核默默丢弃，而 UDP 丢包的默认重试等待时间刚好是 5 秒。

标准的云原生工程解法是：抛弃集中式的 CoreDNS，在每个宿主机节点下放一个本地 DNS 缓存代理。

1. 部署 NodeLocal DNSCache (DaemonSet)

不要试图去修改数千个业务 Pod 的网络配置。直接在 CCE 集群中以 DaemonSet 模式部署 node-local-dns。它会在每个 ECS 工作节点上监听一个本地虚拟 IP（通常为 169.254.20.10）。

# 精简版 NodeLocal 配置示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-local-dns
  namespace: kube-system
spec:
  template:
    spec:
      hostNetwork: true # 占用宿主机网络命名空间
      containers:
      - name: node-cache
        image: registry.k8s.io/dns/k8s-dns-node-cache:1.22.20
        args:
        # 拦截本地 DNS 请求，未命中缓存时向上游 CoreDNS 转发
        - -localip
        - 169.254.20.10
        - -setupinterface=false

2. 将 UDP 强制升级为 TCP

UDP 的无连接特性是丢包重试慢的罪魁祸首。NodeLocal DNS 的核心优势在于，同节点的 Pod 依然使用 UDP 极速查询本地 Cache；但当 Cache 未命中、需要跨节点向核心 CoreDNS 请求时，代理底层会自动将协议升级为 TCP。TCP 拥有的滑动窗口与快速重传机制，直接在内核层绝杀了 5 秒超时的可能性。

3. 优化特定工作负载的 ndots 阈值

作为防爆兜底，对于重度依赖公网请求（如纯粹的爬虫集群或外网回调网关）的 Deployment，可以直接在 YAML 中覆写 DNS 策略，斩断无效的内部搜索：

      dnsPolicy: "None"
      dnsConfig:
        nameservers:
          - 169.254.20.10 # 指向本地缓存节点
        options:
          - name: ndots
            value: "2"    # 降低阈值，大幅减少无效查询

总结： DNS 作为微服务调用的第一跳，其稳定性直接决定了全局业务的 P99 延迟。通过部署 NodeLocal 缓存组件，我们将解析压力均摊到了每个边缘 ECS 节点，不仅保护了脆弱的核心 CoreDNS，更用 TCP 替代 UDP 解决了最棘手的丢包延迟，是云原生大规模集群不可或缺的网络基石。