故障复盘：AI代理负载骤增导致的CoreDNS连接池枯竭

故障概述

2026年7月8日 14:15 UTC，我们的主生产 Kubernetes 集群 (prod-core-svcs) 发生集群范围的域名解析服务中断，导致多个微服务出现域名解析超时。尝试解析数据库 DNS 端点、外部支付 API 以及同级微服务的内部服务纷纷超时，最终引发面向用户的 Web 网关级联故障。

该事故是由我们新部署的 AI 智能代理编排服务 (aops-agent-scheduler) 突然涌入的大量自治 API 查询触发的。瞬时负载洪峰直接耗尽了核心 DNS 转发器的连接池限制。

在调整 CoreDNS 缓存设置、水平扩容副本数，并在 AI 代理的 HTTP 客户端内实施连接复用策略后，服务于 14:52 UTC 全面恢复（持续时间：37 分钟）。

故障时间线

时间 (UTC)	事件 / 响应动作
14:12	AI 智能代理编排调度器启动了一批 5,000 个并发容器健康状况审计任务。
14:15	PagerDuty 触发高警报：`APIGatewayErrorRate > 5%`。
14:18	SRE 值班工程师介入。初步怀疑：数据库连接耗尽。
14:22	检查发现数据库连接指标正常。然而，应用日志中出现数据库超时错误：`Dial tcp: lookup db-prod.internal: i/o timeout`。
14:25	检查 CoreDNS Pod 日志发现警告：`[WARNING] plugin/forward: dial tcp 10.x.x.x:53: i/o timeout`（上游转发器连接池溢出/枯竭）。
14:30	紧急规避措施：将 CoreDNS 副本数从 3 个扩容至 10 个。但异常的高频查询依然持续让 Pod 过载。
14:35	定位到 `aops-agent-scheduler` 是本次查询风暴的源头。SRE 临时限流挂起该调度器的 Deployment。
14:40	应用 CoreDNS 配置更新，启用激进缓存策略（提前获取 prefetch 和延长 TTL）。
14:45	重新启用并恢复代理调度器。CoreDNS 的 CPU 和查询指标保持平稳。
14:52	所有网关错误告警清除。故障后持续监视确认集群完全康复。

技术根因分析 (RCA)

为了厘清为何一个 5,000 任务的审计并发能直接压垮整个集群的域名解析，SRE 深入追踪了网络链路。

该 AI 代理调度器被配置为审计 5,000 个模拟微服务。由于该代理的 Go 语言 HTTP 客户端中的编码缺陷，它为每一个审计任务都实例化了一个全新的 HTTP Transport，而没有共享该传输对象。这彻底绕过了 HTTP 连接复用（Keep-Alive）机制，导致瞬时在操作系统内打开了 5,000 个并发套接字 (Sockets)。

sequenceDiagram
    participant AI as AI 代理调度器
    participant KNS as Kube-DNS (CoreDNS)
    participant UP as 上游 DNS (10.x.x.x)

    Note over AI: 每次审计都新建 Transport
    AI->>KNS: 5,000 个并发域名解析请求
    Note over KNS: 缓存未命中（新子域名）
    KNS->>UP: 将 5,000 个解析请求转发至上游转发器
    Note over UP: 上游连接池上限溢出
    UP-->>KNS: 丢包 / i/o timeout
    KNS-->>AI: i/o timeout (解析失败)

在 DNS 层面上：

由于微服务的目标域名没有使用缓存的通配符路由，CoreDNS 必须将所有查询全部转发给上游服务器。
因为 Go 网络解析器内的 DNS 客户端会同时发起并发的 A 和 AAAA 解析请求，5,000 次 API 审计直接转化为 10,000 个并发 UDP 数据包在 3 秒窗口内冲击 DNS 系统。
CoreDNS 上游转发器连接池达到了描述符限制，从而开始静默丢弃 UDP 数据包。
这种静默丢包引发了严重的域名解析延迟，导致其他关键工作负载（例如数据库连接器）因无法解析 DNS 域名而发生崩溃。

改进与系统加固措施

为避免未来再次发生同类故障，我们实施了以下结构性的优化：

1. HTTP 客户端连接复用（代码修复）

AI 代理调度器代码已修改为使用单例模式共享的 HTTP 客户端：

// 修复前（存在缺陷）
func AuditService(url string) {
    client := &http.Client{Transport: &http.Transport{}} // 套接字枯竭
    client.Get(url)
}

// 修复后（已解决）
var SharedClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 20,
        IdleConnTimeout:     90 * time.Second,
    },
}

2. CoreDNS 配置加固

我们更新了 CoreDNS 的 Corefile 配置，启用了 prefetch 并调大了 Cache 缓存空间。这使得 CoreDNS 能够直接从缓存中返回高频查询，同时在后台异步刷新即将过期的记录，极大减少了向上游转发的请求比例。

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . 10.x.x.x {
        max_concurrent 1000
    }
    cache 30 {
        success 9984 30
        denial 9984 5
        prefetch 10 10m 10%
    }
    loop
    reload
    loadbalance
}

3. DNS 副本弹性伸缩 (KEDA)

我们引入了 Kubernetes 事件驱动自动伸缩器（KEDA）与 CoreDNS 进行集成。根据 CoreDNS CPU 负载和上游丢包率动态调整 CoreDNS Pod 副本数，确保在连接池达到过载临界点之前完成水平扩容。

经验总结

本次故障充分证明了 SRE 的核心意义不仅仅是保证服务器在线，更是去管理应用层代码设计与底层基础架构物理限制之间的共生关系。当我们在生产环境中构建高并发的自治 AI 智能体时，开发者必须以设计高并发 SRE 系统级工具的严苛标准来对待 HTTP 以及网络连接管理。