Chaos Mesh 注入 DNS 解析故障：检验 CoreDNS 抖动时本地缓存与客户端连接池健壮性-育师

Chaos Mesh 注入 DNS 解析故障：检验 CoreDNS 抖动时本地缓存与客户端连接池健壮性

在 Kubernetes 云原生集群的稳定性版图上，CoreDNS 常常被称为“最不起眼、却能一击毙命的致命死穴”。

平时的系统架构图上，大家都在津津乐道服务网格、分布式事务、分库分表和多级缓存，很少有人会把目光投向那几个默默运行在kube-system命名空间下的 CoreDNS Pod。然而，一旦大促期间瞬时涌入数十万 QPS，如果应用层的域名解析与连接池设计存在隐患，最先倒下的往往就是 CoreDNS：
上游微服务每发起一次微小的 RPC 或 HTTP 调用，竟然都在硬生生地向 CoreDNS 发起一次全新的 UDP 域名解析请求！在千万级并发的冲击下，CoreDNS Pod 的 CPU 会在两秒钟内被 UDP 数据包直接打满，紧接着引发 Linux 内核的conntrack连接跟踪表溢出。

随着 CoreDNS 发生丢包，整个集群瞬间爆发灾难性的多米诺骨牌效应：
几乎所有业务 Pod 同时抛出dial tcp: lookup order-core.production.svc.cluster.local: i/o timeout，原本健康的微服务因为解析不到下游数据库和缓存的 IP 地址而全线瘫痪。

为了在大促实战前彻底逼出各业务服务在域名解析维度的脆弱性，我们利用Chaos Mesh 的DNSChaos故障注入能力，对生产集群的 DNS 链路发起了一场针对性的极限压力演练。

为什么说默认的 K8s DNS 解析是一场灾难

在深入演练之前，我们必须清醒地认识到 Kubernetes 默认 DNS 机制在面对高并发时存在的三大先天缺陷：

ndots:5带来的放大风暴：
Kubernetes 默认给每个 Pod 注入的/etc/resolv.conf中包含options ndots:5。当应用尝试访问一个普通的外部域名（例如api.alipay.com）时，由于点号数量小于 5，解析器会强制在末尾拼接集群内部搜索域（Search Domains）进行盲目轮询：
先查api.alipay.com.production.svc.cluster.local（失败 NXDOMAIN）；
再查api.alipay.com.svc.cluster.local（失败 NXDOMAIN）；
接着查api.alipay.com.cluster.local（失败 NXDOMAIN）；
最后才去公网递归查询真实域名！原本 1 次 DNS 解析，被无端放大了整整 4 到 5 倍！
应用进程缺乏本地 DNS 缓存：
许多基于 Go 或 Python 编写的微服务，默认的 HTTP Client 根本不自带内存 DNS 缓存。只要代码没有复用底层 TCP 连接池，每一次发起http.Get()，Go 运行时的纯 Go Resolver 就会老老实实通过 UDP 53 端口向 CoreDNS 发起一次网络握手。
UDP 协议面对丢包时的指数退避惩罚：
标准的 glibc DNS 解析器在遭遇 UDP 丢包时，超时重试间隔通常是 5 秒（timeout:5）。这意味着仅仅 1% 的偶发丢包，就会直接导致上千个用户请求被挂起 5 秒以上，瞬间拖垮上游网关。

Chaos Mesh 注入 DNS 故障的生产级编排实战

通过 Chaos Mesh，我们可以在不需要搞挂 CoreDNS 实例的前提下，极其精准地模拟客户端在解析特定域名时的错误与延迟。

1. 模拟核心数据库域名解析硬阻断（dns-chaos-error.yaml）

以下配置用于模拟当订单微服务尝试解析下游数据库域名mysql-primary.db.svc.cluster.local时，强制拦截并返回NXDOMAIN错误，检验业务连接池是否能够优雅降级使用备用 IP：

apiVersion: chaos-mesh.org/v1alpha1 kind: DNSChaos metadata: name: database-dns-failure-chaos namespace: chaos-testing spec: action: error # 强制返回 DNS 解析错误 mode: fixed value: "3" # 随机作用于 3 个目标业务 Pod selector: namespaces: - production labelSelectors: app: order-fulfillment patterns: - "mysql-primary.db.svc.cluster.local" # 精确匹配目标域名，不误伤其他服务 duration: "10m" # 持续 10 分钟

2. 模拟网络抖动引发的 30% 随机解析丢包（dns-chaos-random.yaml）

以下配置用于模拟 CoreDNS 在高负载下发生 30% 随机 UDP 丢包与截断的亚健康状态，检验客户端重试机制：

apiVersion: chaos-mesh.org/v1alpha1 kind: DNSChaos metadata: name: coredns-flapping-chaos namespace: chaos-testing spec: action: random # 随机注入故障 mode: all selector: namespaces: - production labelSelectors: tier: backend patterns: - "*.svc.cluster.local" # 拦截所有内部服务域名解析 duration: "5m"

生产级防御加固的四大核心手段

演练暴露出大量问题后，我们必须在集群基础设施与应用代码层面完成系统级防御加固：

全量落地 NodeLocal DNSCache：
这是解决 CoreDNS 压力的终极武器。在集群每个计算节点上以 DaemonSet 运行一个本地轻量级 DNS 缓存代理（监听节点回环 IP169.254.20.10）。Pod 的所有 DNS 请求直接在宿主机本地内存命中，缓存未命中时由代理通过稳定的 TCP 长连接向中心 CoreDNS 转发，直接消灭 95% 的跨节点 UDP 流量。
优化 Pod 内部的ndots参数：
在经常调用外部第三方 API 的微服务 Deployment 中，显式通过dnsConfig将ndots从默认的 5 压降为 2：
```
spec: dnsConfig: options: - name: ndots value: "2" - name: timeout value: "1" - name: attempts value: "2"
```
应用层强制开启 TCP 连接池复用（Keep-Alive）：
推动业务研发在初始化 HTTP / RPC 客户端时，强制开启长连接复用（MaxIdleConnsPerHost: 100，IdleConnTimeout: 90s）。只要长连接不断开，后续成千上万次数据传输直接复用已有 TCP 套接字，彻底绕过 DNS 解析流程。
CoreDNS 自动水平伸缩（DNS Horizontal Autoscaler）：
在集群中配置基于集群节点数与 Core 核心数联动的自动扩容机制。集群每增加 16 个工作节点，CoreDNS 自动扩容 1 个副本，确保在大促节点激增时 DNS 算力始终走在前面。