OpenAI 的 Kubernetes 集群故障分析

2024 年 12 月 11 日，OpenAI 遭遇了一次严重的生产环境故障。问题起源于一个新的遥测服务部署，该部署导致 Kubernetes 控制平面过载，引发了级联故障。本文从技术角度分析事故原因、应急响应及后续优化方案。

故障概览

• 故障时间: 2024-12-11 15:16 - 19:38 PST
• 影响范围: 所有 OpenAI 服务出现严重性能下降或完全不可用
• 恢复时间:
  • ChatGPT: 17:45 慢慢恢复, 19:01 完全恢复
  • API: 17:36 慢慢恢复, 19:38 完全恢复
  • Sora: 19:01 完全恢复

技术根因分析

直接原因

• 新部署的遥测服务在大规模集群中产生了大量 Kubernetes API 调用
• 控制平面过载导致 CoreDNS 服务不可用
• DNS 缓存 TTL 过期后服务发现机制崩溃

OpenAI 在全球范围内运行着数百个 Kubernetes 集群。每个集群包含一个负责集群管理的控制平面(Control Plane)和一个承载实际工作负载(如模型推理)的数据平面(Data Plane)。

作为可观测性改进计划的一部分，我们一直在优化集群监控工具以提升系统状态的可见性。在 PST 15:12，我们部署了一个新的遥测服务来采集 Kubernetes 控制平面的详细指标。

这个遥测服务的监控范围非常广泛，其配置导致每个集群中的所有节点都执行了高开销的 Kubernetes API 操作，且开销随集群规模线性增长。当数千个节点并发执行这些操作时，Kubernetes API Server 负载激增，导致大多数大型集群的控制平面不可用。由于这个问题在大规模集群中更为明显，我们的测试环境未能发现它，而 DNS 缓存机制又掩盖了这个问题的早期症状。

虽然 Kubernetes 数据平面可以在一定程度上独立于控制平面运行，但 DNS 解析依赖于控制平面 - 如果控制平面不可用，服务间的服务发现就会失效。

简而言之，根本原因是新遥测服务在大型集群中产生了过量的 API 请求，使控制平面过载并破坏了基于 CoreDNS 的服务发现机制。

测试与部署分析

该变更在 staging 环境测试时未发现异常。问题是因为只会在超过特定规模的集群中才会出现，且由于节点上的 DNS 缓存延迟了故障暴露时间，使得灰度发布得以继续。

部署前的可靠性评估主要关注了遥测服务的资源消耗，我们检查了所有集群的资源使用指标(CPU/Memory)以确保部署不会影响运行中的服务。虽然根据集群规模调整了资源请求，但未评估对 API Server 的负载影响。发布流程监控了服务健康状态，但缺乏完整的集群健康检查机制。

Kubernetes 数据平面的设计目标是可以独立于控制平面运行。然而，API Server 对 DNS 解析的支持是许多服务的关键依赖。

DNS 缓存通过提供 stale 记录暂时掩盖了问题。但随着缓存在 20 分钟内陆续过期，依赖实时 DNS 解析的服务开始失败。这个延迟时间点很关键，因为它推迟了问题的发现，导致在完全理解影响范围前继续发布。一旦 DNS 缓存全部过期，DNS 查询量激增，进一步加剧了控制平面的负载，使得故障恢复更加困难。

应急响应

监控部署并回滚有问题的变更通常是标准流程，我们有工具来检测和回滚错误的部署。这次我们的监控系统正常工作，在用户受影响前几分钟就检测到了异常。但修复需要访问 Kubernetes 控制平面 - 而此时由于 API Server 过载我们无法操作。

我们在几分钟内就定位了问题，并立即启动了多个并行方案来恢复集群：

1. 缩减集群规模：降低 API Server 总负载
2. 限制对 Kubernetes 管理 API 的网络访问：阻止新的高开销请求，给 API Server 恢复的时间窗口
3. 扩容 API Server：增加资源处理积压的请求，为应用修复创造条件

通过同时推进这三个方案，我们最终恢复了对集群的控制权并移除了问题服务。

一旦重新获得部分控制平面的访问权限，系统就开始显著恢复。我们将流量迁移到健康集群，同时继续修复其他集群。部分集群仍处于降级状态，因为大量服务同时拉取资源导致限流，需要人工干预。

这是多个系统和流程同时失效并产生复杂相互作用的结果：

• 测试环境未能发现变更对控制平面的影响
• DNS 缓存在变更部署和服务失败之间引入了延迟
• 由于死锁效应，修复措施进展缓慢

时间线

• 2024-12-10：遥测服务在 staging 环境部署并验证
• 2024-12-11 14:23：变更合并，触发部署流水线
• 14:51-15:20：变更推送至所有集群
• 15:13：监控告警触发
• 15:16：开始出现用户影响
• 15:16：确认根因
• 15:27：开始流量迁移
• 15:40：影响达到峰值
• 16:36：首个集群恢复
• 19:38：所有集群恢复

技术优化措施

为防止类似事件，我们计划实施以下技术改进：

1. 强化灰度发布机制

改进基础设施变更的灰度发布流程，加强监控覆盖，确保故障影响可控且能及早发现。所有基础设施配置变更将遵循严格的灰度发布协议，通过增强的实时监控确保服务工作负载和集群(包括控制平面)的健康状态。

2. 混沌工程测试

增强 Kubernetes 数据平面在控制平面不可用时的生存能力，引入针对性的故障测试。同时实施错误配置注入测试，验证系统的自动检测和回滚能力。

3. 控制平面应急通道

实现在数据平面过载控制平面时的应急访问机制。建立独立的管理通道，确保 SRE 团队在任何情况下都能访问 API Server。

4. 服务发现解耦

重构对 Kubernetes DNS 的依赖，解耦数据平面和控制平面，避免控制平面承担关键路径服务的负担。考虑引入其他服务发现机制作为备份。

5. 快速恢复能力

优化集群启动所需资源的缓存策略和动态限流机制，定期演练快速切换集群的能力。建立明确的恢复时间目标(RTO)。

总结

我们为此次事故给用户带来的影响深表歉意。作为一个技术驱动的组织，我们深知服务可靠性的重要性。我们将优先实施上述技术改进，持续提升系统的可靠性和可用性。感谢社区在此次事故期间的理解和支持。

原文地址：https://status.openai.com/incidents/ctrsv3lwd797

微信公众号

扫描下面的二维码关注我们的微信公众帐号，在微信公众帐号中回复◉加群◉即可加入到我们的 kubernetes 讨论群里面共同学习。