OpenAI 史上最长宕机：自研 K8s 成“拦路虎”，导致数小时无法修复

本周四，OpenAI 旗下 AI 聊天机器人平台 ChatGPT、视频生成工具 Sora 及其面向开发人员的 API 自太平洋时间下午 3 点左右起发生严重中断。

OpenAI 最近宕机频繁。上个月，ChatGPT 突发故障，导致服务中断近半小时，超过 19,000 人受到影响。OpenAI CEO Sam Altman 随后在社交媒体 X 上公开致歉。他表示，公司在可靠性方面比以往有了很大的进步，但仍有许多工作要做。最后他还加了一句：“根据 Similarweb 的数据，它现在是全球第八大网站”。

没想到仅仅一个月时间后，又发生了全球性服务中断事件。

OpenAI 很快承认问题的存在并着手修复，但仍耗费约三个小时才顺利恢复所有服务。

在周五发布的一份事后报告中，OpenAI 写道，此番宕机并非源自安全事件或者近期产品发布，而是因周四部署的用于收集 Kubernetes 指标的监控服务所引发。Kubernetes 是一款开源程序，可帮助管理容器以及在隔离环境下运行软件的应用程序包与相关文件。

OpenAI 在事后报告中写道，“监控服务覆盖的范围非常广泛，因此这项新服务的配置无意间导致……资源密集的 Kubernetes API 操作。我们的 Kubernetes API 服务器不堪重负，导致我们的大多数规模 Kubernets 集群中的控制平面陷入瘫痪。”

OpenAI 提到，在客户感受到影响的“几分钟”内，公司就检测到了该问题；但由于必须绕过不堪重负的 Kubernetes 服务器，因此无法快速实施修复。

该公司写道，“这是多个系统和流程同时发生故障，并以意想不到的方式相互影响的结果。我们的测试未能捕捉到变更对于 Kubernetes 控制平面的影响，并且由于锁定效应，补救措施的实施非常缓慢。”

OpenAI 表示，该公司将采取多项措施防止未来发生类似事件，包括改进登台发布、更好地监控基础设施变化，以及采用新机制以确保 OpenAI 工程师在任何情况下都能访问公司的 Kubernetes API 服务器。

OpenAI 自研了基于 K8s 的管理软件

 基础设施团队负责构建和维护了一个复杂而高效的计算环境，以支持研究人员进行实验和开发。这个环境从上到下包括：研究代码、训练算法、各种工具、以及基于 TensorFlow 和 PyTorch 等框架的底层基础设施。

为了管理这些复杂的系统，团队使用了内部开发的框架（如 Rapid 和 Rcall）以及开源的框架（如 Ray、Kubeflow）。基础设施团队需要负责容器管理和集群调度，而主机和 OS 的编排则使用的是 Chef 和 Terraform。基础设施需要在多个平台上运行，从 Kubernetes 到 Azure 和 Google 服务器。这意味着我们需要控制平面管理集群，处理回调请求，以及调用一些外部服务如 Datadog 等工具。

从堆栈描述中我们可以看出，基础设施团队实际上帮助调试和管理了几乎所有内容，确保与研究相关的工作顺利进行。

Kubernetes 在过去几年中取得了显著进步，现在官方建议的最大集群规模是 5000 节点，然而，由于 Kubernetes 的扩展性能无法完全满足 OpenAI 的需求，基础设施团队于前几年开始开发了一款名为 Rapid 的框架。

Rapid 抽象了平台 API，并将虚拟机视为分布在大型机群中的类似 pod 的单一工作单元，有点像 Kubernetes pod。

在 Rapid 的配置中，每个实验都是独立准备和启动的，与其他实验完全隔离，避免共享数据存储来统一写入实验结果。这种高度隔离的设计非常契合研究人员对系统的使用需求，使他们的实验不会因资源竞争或服务中断而受影响，从而可以专注于自己的研究工作。

Rapid 框架同时也将大模型训练工作抽象成了三类：部署工作者（rollout workers）、优化器（optimizers） 和评估工作者（evaluation workers）。部署工作者负责运行模拟环境，采集观察数据，并将这些样本发送给优化器。优化器是训练模型的核心模块，根据接收到的数据进行参数优化，并生成模型输出。这些输出参数被反馈给部署工作者以完成训练循环，同时被发送给评估工作者，用于判断新版本模型是否优于旧版本。

得益于框架的抽象化设计，OpenAI 的基础设施团队在项目进行中能够轻松应对变化。例如，在项目中期，团队抓住机会，将实验从一个云服务提供商迁移到另一个平台，以便获取不同的硬件和不同的容量。为了应对 GPU 节点频繁维护对训练造成的影响，还需要通过提前检查主机状态，避免将实验部署到即将维护的节点上。

GPT-2 则使用了 OpenAI 研究人员开发的一套名为 Rcall 框架。这一框架同时支持 Kubernetes 和云服务后端，使研究人员能够在 OpenAI 不断扩展的 Kubernetes 集群中测试和调试任务，随后根据需要迁移到物理机、虚拟机或其他硬件环境。有点像中间派，但是比 Rapid 更轻量级的抽象，Rapid 主要处理整个 VM 大小。

2021 年，在训练 GPT-3 时，OpenAI 已经能管理 7500 个节点，并表示他们不太依赖 Kubernetes 的负载均衡，同时他们放弃 Flannel 组件转而使用 Azure VMSS 的本地 Pod 网络技术和相关 CNI 插件来配置 IP。此外，OpenAI 还使用 Prometheus 收集大量指标数据，并使用 Grafana 进行图形、仪表板和警报。

另外，随着研究实验的复杂性不断增加，快速定位问题一直是个大挑战。尤其是当实验失败时，研究人员往往需要花费大量时间去翻阅日志（在 DataDog 中）。为了提高问题排查效率，OpenAI 的基础设施团队不断的开发监控相关的软件，满足各种不同的查询要求，比如输入简单的查询，比如“为什么这个 pod 失败了”，研究人员就能快速得到详细的故障原因分析，例如“该 pod 所在的主机因维护事件被移除”。

而本周的这次故障，直接原因是他们又新部署了一套监控系统，导致 Kubernetes 控制面临的负担加重。随后，由于控制面的故障（依赖于 DNS 和 K8S），无法直接回滚此次发布，进一步放大了故障影响，导致长时间不可用。

此次，OpenAI 罕见地发布了一份完整的故障报告。我们翻译了原文：

OpenAI 故障复盘原文

此份事后分析报告，详细回顾了 2024 年 12 月 11 日发生的一起意外事故，OpenAI 旗下所有服务均经历长时间宕机。该问题源自新部署的遥测服务，此项服务无意间压垮了 Kubernetes 控制平面，导致关键系统发生连锁故障。在这篇文章中，我们将分析其根本原因，概述补救措施、分享后续防范方案以避免类似事件再次重演。

事件影响

2024 年 12 月 11 是太平洋标准时间下午 3：16 至晚 7：38 之间，所有 OpenAI 服务均经历了严重降级甚至完全不可用。此次事件源自在整个产品组合中推出新的遥测服务这一重大变更所引发，与安全事件或近期发布的新产品无关。所有产品均于下午 3：16 开始遭遇降级。

• ChatGPT：下午 5：45 服务基本恢复，太平洋标准时间下午 7：01 完全恢复。

• API：下午 5：36 服务基本恢复，太平洋标准时间下午 7：38 所有模型均已恢复。

• Sora：太平洋标准时间下午 7：01 完全恢复。

根本原因

OpenAI 在全球运营有数百个 Kubernetes 集群。Kubernetes 拥有一个负责集群管理的控制平面，外加实际为模型推理等工作负载提供服务的数据平面。

作为提高组织整体可靠性的保障性举措的一部分，我们一直在努力改进自身集群范围内的可观察性工具，以增强我们系统状态的可见性。太平洋标准时间下午 3：12，我们部署了一项新的遥测服务用以收集 Kubernetes 控制平面的详细指标。

这些遥测服务的覆盖范围极广，因此新服务的配置无意中使得各个集群中的每个节点均须执行资源密集的 Kubernetes API 操作，其成本还会随集群规模而同步扩大。由于数千个节点同时执行这些操作，导致 Kubernetes API 服务器不堪重负，进而令大部分规模集群中的 Kubernetes 控制平面陷入瘫痪。这个问题在我们体量最大的集群中表现最为明显，但由于 DNS 缓存在该服务的大规模部署之前掩盖了问题，致使我们的测试未能及时发现。

Kubernetes 数据平面在很大程度上可以独立于控制平面运行，但 DNS 依赖于控制平面——具体来讲，各服务无法在缺少 Kubernetes 控制平面的情况下相互通信。

简言之，引发事故的根本原因就是新的遥测服务配置意外在大规模集群中产生了大量 Kubernetes API 负载，导致控制平面不堪重负并破坏了基于 DNS 的服务发现能力。

测试与部署

此番变更在登台集群内进行了测试，但没有观察到任何问题。只有规模超过一定水平的集群才会受到影响，而我们各个节点上的 DNS 缓存则大大延后了故障被观察到的时间，因此部署工作仍在如常推进。

部署之前，我们最关注的可靠性问题就是新遥测服务的资源消耗。在部署之前，我们评估了所有集群（CPU/内存）方面的资源利用率指标，以确保部署不会中断正在运行的服务。尽管资源请求会按集群进行调整，但我们没有采取任何预防措施来评估 Kubernetes API 服务器负载。另外，部署流程虽然会监控服务运行状况，但未充分配备集群运行状况监控协议。

Kubernetes 数据平台（负责处理用户请求）在设计上能够独立于控制平面运行，但 DNS 解析仍须借助 Kubernetes API 服务器——事实上，DNS 解析在我们的许多服务中均属于关键依赖项。

DNS 缓存能够提供过时但可正常运行的 DNS 记录，也正是这项功能缓解了性能影响。然而，随着缓存记录在接下来的 20 分钟内过期，服务实时 DNS 解析的服务开始出现故障。这个时间窗口至关重要，因为其延后了问题被发现的时间，导致我们在未了解问题全貌之前继续推进部署。当 DNS 缓存为空之后，DNS 服务器上的负载开始成倍增加，这进一步增加了控制平面的负载，也大大增加了即时缓解工作的实施难度。

补救措施

监控部署并恢复引发问题的变更一般非常简单，我们有专门的工具以检测并回滚错误部署。在此次事件中，我们的检测工具成功发挥作用，在客户受到实际影响前的几分钟就检测到了问题。但要想解决问题，我们需要删除引发问题的服务，而这要求我们访问 Kubernetes 控制平面——但随着 Kubernetes API 服务器负载的增加，访问操作根本无法进行。

我们在几分钟内就确定了问题，并立即启动了多个工作流，以探索快速恢复集群的不同方法：

1. 缩小集群规模：降低总 Kubernetes API 负载。

2. 阻止对 Kubernetes 管理员 API 的网络访问：阻止新的高资源成本请求，让 API 服务器有时间恢复正常。

3. 扩展 Kubernetes API 服务器：增加可用资源以消化待处理请求，借此为修复操作留出空间。

通过同时推进这三项工作，我们最终夺回了控制权，得以删除存在问题的服务。

在重新获得对部分 Kubernetes 控制平面的访问权限之后，恢复工作立即步入了正轨。在可能的情况下，我们尝试将流量转移至健康集群，同时对其他 集群进行修复。由于大量服务尝试同时下载资源，资源限制开始饱和并需要额外的手动干预，且部分集群仍处于性能降级状态。

可以看到，此次事件属于多个系统及流程同时发生故障并以意外方式相互影响的结果。具体来讲——

• 我们的测试未能捕捉到变更对于 Kubernetes 控制平面的影响。

• DNS 缓存的存在，延长了执行变更及服务开始发生故障之间的间隔。

• 由于锁定效应，补救措施推进缓慢。

时间线

• 2024 年 12 月 10 日：新的遥测服务被部署至登台集群，并在验证流程中符合预期。

• 2024 年 12 月 11 日下午 2：23：引入新服务的变更被纳入部署管线并开始执行。

• 下午 2：51 至 3：20：变更被应用于所有集群。

• 下午 3：13：发出警报，通知工程师。

• 下午 3：16：开始对客户产生轻微影响。

• 下午 3：16：确定根本原因。

• 下午 3：27：工程师开始将流量从受影响的集群中移出。

• 下午 3：40：对客户的影响达到峰值。

• 下午 4：36：首个集群成功恢复。

• 下午 7：38：所有集群均已恢复。

预防措施

为了防止后续再次发生类似事件，我们正着手实施以下举措：

1. 稳健的登台发布机制

我们将继续改进登台发布机制，更好地监控所有基础设施的变化，以确保任何故障均不会造成太大影响且可被及早发现。今后一切与基础设施相关的配置变更，都将遵循稳健的登台发布流程；同时持续监控机制也将得到改进，确保服务工作负载和集群（包括 Kubernetes 控制平面）始终健康。

2. 故障注入测试

Kubernetes 数据平面应可在控制平面中断的情况下运行更长时间，我们也将明确针对这类情况运行测试。我们还将在测试中涵盖恶意变更状况，确保我们的系统能够检测到问题并适时回滚。

3. 应急 Kubernetes 控制平面访问

当数据平面对控制平面施加过大压力时，我们应当确保仍可正常访问 API 服务器。为此我们将实施应急机制，以保证工程师在任何情况下均可访问 Kubernetes API 服务器。

4. 对 Kubernetes 数据平面与控制平面进行解耦

我们负责服务发现的 Kubernetes DNS 中的依赖项，导致 Kubernetes 数据平面与控制平面之间建立了链接。我们正投入资源将 Kubernetes 数据平面与控制平面相互解耦，借此保证控制平面无需承担处理关键任务服务及产品工作负载等责任。

5. 加快恢复速度

我们将为集群启动所必需的资源提供经过改进的缓存及动态速率限制器，同时定期组织演习以保证快速、正确启动目标，实现对整体集群的快速替换。

总结

对于此次事件对全体客户造成的影响，我们深表歉意——包括各位 ChatGPT 用户、开发人员乃至依赖 OpenAI 产品的企业。我们未能履行自己的预期与承诺。我们意识到为大家提供高可靠性服务的重要意义，并将着力推动上述预防措施，希望继续提高可靠性。感谢您在此次中断期间的耐心等待。

参考链接：

https://www.infoq.cn/article/g9tuotodp20n1ltzjsjw

https://www.datadoghq.com/videos/scaling-ai-infra/

https://status.openai.com/incidents/ctrsv3lwd797