Kubernetes CoreDNS 性能瓶颈与大促前 NodeLocal 改造

在基于 Kubernetes 构建的大型云原生微服务架构中，CoreDNS（集群内部 DNS 域名解析引擎） 是维系全站数千个微服务相互寻址与服务发现（Service Discovery）的“隐形中枢神经”。

无论微服务是通过 http://trade-order-service:8080 发起 Feign 调用，还是连接 mysql-master.db.svc.cluster.local，请求发出的第一纳秒，底层操作系统都必须先向 CoreDNS 发送 UDP 数据包以获取目标 Pod 的虚拟 Cluster IP。

然而，在多次大促备战的数十万 QPS 全链路高并发压测中，默认集中式部署的 CoreDNS 集群却频频沦为引发全网雪崩的“头号致命火源”：

• 压测流量刚翻倍，全站接口的响应延迟曲线上突然暴起数以千计的**“整整 5 秒（5000ms）超长毛刺”**；
• 紧接着，所有微服务的日志中疯狂涌出：java.net.UnknownHostException 与 i/o timeout 域名解析失败异常；
• 登录集群排查发现：集中式部署的 4 个 CoreDNS Pod 的 CPU 利用率直接被海量 UDP 请求打满至 100% 爆死，DNS 请求队列严重溢出并发生大规模丢包！

为什么看似极其轻量级的 DNS 解析会在大促高并发下演变为全网雪崩？

深入剖析 Linux glibc 解析器的 ndots:5 缺陷与内核 conntrack 竞态丢包机理，并在大促封网前全面落地 NodeLocal DNSCache 节点级缓存架构改造，是守卫云原生网络底座最关键的防线。

压垮 CoreDNS 的两大隐形物理杀手

[杀手 1: glibc 默认 ndots:5 引发的 "5 倍查询风暴 (Query Multiplication)"]
微服务发起调用: "api.alipay.com"
- 第 1 次无谓解析: api.alipay.com.trade.svc.cluster.local -> NXDOMAIN (不存在)
- 第 2 次无谓解析: api.alipay.com.svc.cluster.local       -> NXDOMAIN (不存在)
- 第 3 次无谓解析: api.alipay.com.cluster.local           -> NXDOMAIN (不存在)
- 第 4 次无谓解析: api.alipay.com.localdomain             -> NXDOMAIN (不存在)
- 第 5 次有效解析: api.alipay.com                         -> 203.0.113.1 (成功解析!)
--------------------------------------------------------------------------------------
-> 致命缺陷: 仅仅解析一个外部域名，竟然向 CoreDNS 连续狂轰了 5 次无谓的跨网络 UDP 请求!
   全网 100,000 QPS 流量瞬间被几何放大为整整 500,000 QPS 的 DNS 洪峰!

[杀手 2: Linux 内核 conntrack 竞态丢包 (致命的 5 秒超时毛刺)]
- glibc 在解析域名时，同时并发发送 A 记录与 AAAA 记录 (IPv6) 的 UDP 包;
- 两个 UDP 包在通过 Linux 内核 iptables / Netfilter 时，争抢插入 conntrack 表的同一哈希槽位;
- 发生内核哈希冲突 -> 其中一个 UDP 包被内核静默丢弃!
- 客户端在等待 5 秒超时后才发起重传! (导致全网高频突发 5000ms 延迟毛刺!)

工业级救赎方案：NodeLocal DNSCache 节点级分布式缓存

要彻底终结集中式 CoreDNS 的性能雪崩，最彻底的架构重构是将 DNS 解析从“跨网络集中式拉取”升级为“本地宿主机环回解析（Local Loopback DNS）”：

[传统集中式 CoreDNS 反模式]
Pod-1 (Node-1) ----+
Pod-2 (Node-1) ----+==== (跨物理网络向远端 CoreDNS 疯狂发送 UDP!) ====> [集中式 CoreDNS Pod] (CPU 100% 爆死!)
Pod-3 (Node-2) ----+

--------------------------------------------------------------------------------------

[NodeLocal DNSCache 现代架构 (极致性能)]
[Pod-1] -> (访问本地 169.254.20.10, 耗时 0.05ms!) -> [Node-1 本地 NodeLocal DNS Cache (DaemonSet)]
[Pod-2] -> (访问本地 169.254.20.10, 耗时 0.05ms!) -> [Node-1 本地 NodeLocal DNS Cache (DaemonSet)]
                                                                  |
                                                                  v (仅在本地未命中时，通过 TCP 向上游回源)
                                                       [集中式 CoreDNS (负载骤降 95%! 稳如泰山!)]

生产级 NodeLocal DNSCache 改造实施指南

在大促封网前，通过 Kubernetes DaemonSet 在全集群每一台物理宿主机上部署 NodeLocal DNSCache：

# NodeLocal DNSCache 生产级 DaemonSet 配置样板片段
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-local-dns
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: node-local-dns
  template:
    metadata:
      labels:
        k8s-app: node-local-dns
    spec:
      hostNetwork: true # 必须启用 hostNetwork，绑定宿主机网络空间！
      priorityClassName: system-node-critical # 系统最高优先级，防被驱逐
      containers:
      - name: node-cache
        image: registry.k8s.io/dns/k8s-dns-node-cache:1.22.28
        args:
        - -localip
        - 169.254.20.10 # 本地虚拟 IP (Link-Local IP)
        - -conf
        - /etc/Corefile
        - -upstreamsvc
        - coredns
        securityContext:
          capabilities:
            add:
            - NET_ADMIN

NodeLocal DNS 的三大降维打击优势：

1. 网络 RTT 压缩为 0：Pod 向本地 169.254.20.10 发送 DNS 查询，直接在宿主机本地内存命中返回，解析耗时从 3ms 骤降至 0.05ms！
2. 彻底消灭 5 秒内核丢包毛刺：NodeLocal 与远端 CoreDNS 之间全面采用 TCP 协议进行长连接保活通信，彻底绕过了 Linux 内核 Netfilter UDP conntrack 竞态冲突缺陷，全网 5 秒毛刺彻底绝迹！
3. CoreDNS 负载减轻 95%：95% 以上的微服务域名解析全部在宿主机本地内存被拦截并命中，集中式 CoreDNS 获得彻底解放。

辅助杀手锏：微服务 Pod 的 dnsConfig 深度调优

在业务 Deployment YAML 中，优化默认的 DNS 搜索域参数：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: trade-order-service
spec:
  template:
    spec:
      # 生产级 Pod DNS 客户端深度优化配置
      dnsPolicy: "ClusterFirst"
      dnsConfig:
        options:
        # 1. 将默认的 ndots:5 缩减为 ndots:2 (彻底阻断 5 倍无效域名查询放大!)
        - name: ndots
          value: "2"
        # 2. 解决 glibc 并发查询 A 与 AAAA 记录冲突问题
        - name: single-request-reopen
        # 3. 缩短客户端超时时间
        - name: timeout
          value: "1"
        - name: attempts
          value: "2"

改造实测战果

在大促 300,000 QPS 极限高并发压测实战中：

• 集中式 CoreDNS 服务端 CPU 负载：从原本的 98% 濒死状态断崖式回落并稳定在 6% 的绝对安全水位；
• 全站 DNS 域名解析平均延迟：从 2.8ms 压缩至 0.08ms（提速 35 倍！）；
• 全网 5 秒长尾延迟毛刺（Tail Latency）：从每小时发生数百次彻底降低为 0 次（彻底绝迹），为大促高并发云原生网络打通了最关键的一处脉络。