# 我们从OpenAI全球宕机事件中，总结了什么？ > 作者/来源: UCloud官方/历史归档 > 发布时间: 2024-12-20T03:05:43.000Z > 分类: 解决方案 > 标签: Kubernetes, 故障分析, 可观测性 > 原文链接: http://117.50.162.249:3000/yun/articles/2630 --- OpenAI停摆：故障报告分析 12月11日，OpenAI的所有服务（包括ChatGPT、API和Sora）在下午3:16PST至7:38PST期间经历了严重的性能下降和完全不可用的情况。**此次故障源于新部署的遥测服务配置错误，导致全球数百个 Kubernetes（K8S）集群的控制平面超载，进而引发关键系统的连锁故障。** **造成影响** - ChatGPT：在下午5:45 PST开始显著恢复，7:01 PST完全恢复。 - API：在下午5:36 PST开始显著恢复，7:38 PST所有模型完全恢复。 - Sora：在下午7:01 PST完全恢复。 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/0ed31329a45843a1.jpg) **故障原因** OpenAI在全球运营数百个Kubernetes集群。此次事件的根本原因是新部署的遥测服务配置错误，导致每个集群中的所有节点同时执行资源密集型的 Kubernetes API操作，尤其在大型集群中影响显著。 这些操作过载了Kubernetes API服务器，瘫痪了控制平面，并且由于数据面的DNS服务依赖于控制面，最终导致数据面依赖的服务无法正常运行，系统进入雪崩式故障。 **此次事故的主要原因包括：** **1.服务解耦不足：**数据面的核心服务依赖于控制面的存活，导致控制面故障时数据面无法正常运作。 **2.配置错误：**新遥测服务的配置导致每个节点同时进行高负载的API操作，超载了Kubernetes API服务器。 **3.部署流程不完善：**缺乏阶段性部署的健壮机制，未能有效控制新服务对现有系统的影响。 **4.缺乏容错测试：**未进行充分的错误注入测试和故障演练，导致在控制面失效时无法迅速响应。 **5.紧急访问受限：**在控制面失效时，工程师无法通过控制面进行快速回滚操作，形成“锁死”效应，延长了故障恢复时间。 **应急措施** 尽管监测工具及时检测到问题，但由于Kubernetes控制平面负载过重，工程师无法迅速访问控制平面进行修复。为恢复服务，团队同时采取了以下措施： **1.缩减集群规模：**减少Kubernetes API负载。 **2.阻断对Kubernetes管理API的网络访问：**防止新的高负载请求。 **3.扩展Kubernetes API服务器：**增加资源以处理待处理请求。 **4.移除有问题的遥测服务：**防止进一步的负载增加。 **5.将流量转移出受影响集群：**减轻负载，逐步恢复正常服务。 通过并行实施这些措施，最终恢复了控制平面，逐步恢复了所有集群的正常运行。 # # 我们能做些什么？ 在应对类似问题时，优刻得团队认为以下策略能够更有效地解决和预防此类事件的发生。**结合OpenAI披露的信息、社区的最佳实践以及OpenAI处理事故的思路，UCloud UK8S开发团队提出以下几点建议：** **01** **建立全面可观测性体系** 在故障注入的对立面，我们需要建立完善的可观测性考量，来观测故障的发生，并进一步做出决策。 成熟且可靠的团队（如银行和金融行业）通常会为系统的各个方面建立可观测性组件，并通过故障注入、测试和故障演练来准备应对大量的风险场景。这不仅有助于在故障发生时迅速定位问题，还能在日常运营中持续优化系统性能和稳定性。 **我们建议从下面三个方面建立可观测性考量：** **1.API Server观测** **监控指标：**实时监控API Server的请求延迟、内存、CPU占用，包括请求的响应时间和处理时间。通过收集和分析这些指标，可以及时发现性能瓶颈和异常情况。 **可视化工具：**利用Grafana等可视化工具，构建仪表盘展示API Server的延迟情况，帮助运维团队直观了解系统健康状态。 **报警机制：**设置延迟阈值，当请求延迟阈值、CPU使用率阈值或内存使用率等阈值超过预设值时，触发报警，确保工程师能够在第一时间介入处理。 **2.CoreDNS观测** **DNS查询性能：**监控CoreDNS的查询响应时间和失败率，确保DNS解析服务的稳定性和高可用性。 **资源使用情况：**跟踪CoreDNS的CPU和内存使用情况，防止资源耗尽导致的服务中断。 **日志分析：**收集和分析CoreDNS的日志，识别潜在的配置问题和异常请求模式，提升DNS服务的可靠性。 **UCloud UK8S产品已经集成了这些功能：** **集成监控服务：**利用UCloud提供的监控解决方案，整合Kubernetes集群的各项性能指标，提升整体可观测性。 **自动化报警和响应：**配置UCloud的自动化报警系统，根据监控数据自动触发响应措施，减少人工干预时间。 **02** **实施故障注入** 在针对故障的测试过程中，故障注入是一种通过故意引入故障来验证系统弹性和恢复能力的方法。然而，许多团队尚未广泛实践这一方法。我们都知道Kuberenetes的控制面，是一个会因压力发生损坏的东西，各式各样的友商都对扩展控制面做出过很多努力。 针对此次故障，我们团队建议针对以下两个场景进行故障注入： **1. 控制面故障：**在一个小型集群中，关闭控制面机器，辅助可观测性工具观察后果，进行预演。 **2. DNS故障：**针对本地DNS以及其他DNS服务，进行故障注入，并观测DNS状态，进行预演。 **03** **控制集群规模** 有效的集群规模管理是确保Kubernetes集群稳定运行的关键，也是最为简单的容错方案。 **UCloud UK8S团队提出以下建议：** **1. 小集群与多集群管理** **小集群策略：**将工作负载分散到多个小规模集群中，减少单个集群的复杂性和资源竞争，提升整体系统的稳定性和可维护性。 **多集群管理：**采购UK8S集群，实现对多个Kubernetes集群的集中管理和统一监控，简化运维流程。 **2. 集群规模建议及Master资源配置** **集群规模建议：**根据实际业务需求和工作负载，合理规划每个 Kubernetes 集群的节点数量和资源分配。建议集群节点数控制在资源负载范围内，以平衡性能和管理复杂性。 **Master节点资源配置：**为Master节点配置充足的CPU、内存和存储资源，确保其在高负载情况下依然能够高效处理API请求和控制平面操作。推荐在100个节点内至少用4核CPU、8GB内存及40GB SSD存储，在更大的集群节点数下需要等比例更好的配置。 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/e3b2dbce6ca00948.jpg) # # AI场景下的其他挑战与容器解决方案 在AI应用场景中，除了上述通用问题外，还存在以下特有挑战，UCloud UK8S团队结合最佳实践提出相应解决方案： ** 拉镜像速度慢的问题** ## **问题描述：**在大规模部署AI模型时，镜像拉取速度慢会导致部署延迟，影响整体系统的响应时间。 **解决方案：**引入**镜像加速器**（如Docker镜像加速服务），优化镜像存储和分发架构，缩短镜像拉取时间。此外，使用本地缓存和预拉取策略，确保节点能够快速获取所需镜像。 此前，优刻得容器服务UK8S推出了[**容器镜像加速**](https://mp.weixin.qq.com/s?__biz=MjM5NDE0MjI4MA==&mid=2656320492&idx=1&sn=edc54b30f03862c795b43ba2482bb35e&scene=21#wechat_redirect)（点击了解详情🔎）功能，旨在提升AI业务应用过程中的部署速度和运行效率，欢迎体验。 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/wechat/images/8ee0059522efd7b4.png) ** Stable Diffusion场景下CPU性能提升** **与****GPU使用率优化的问题** **问题描述：**在生图模型（Stable Diffusion）场景下，CPU性能不足会限制GPU的利用率，影响整体训练效率。 **解决方案：**优化CPU策略，通过增加CPU核数和提升主频，提升整体计算性能。同时，优化任务调度算法，确保GPU资源能够充分利用，减少CPU 瓶颈对训练任务的影响。详情可进入**UCloud文档中心**查询了解。 文档中心链接地址： https://docs.ucloud.cn/uk8s/administercluster/gpu-node?id=裸金属云主机绑核 ** 推理延迟的问题** **问题描述：**AI模型的推理过程对延迟要求较高，过高的推理延迟会影响用户体验和实时性需求。 **解决方案：**引入高效的消息队列系统（如Kafka），优化负载均衡（LB）策略，确保推理请求能够快速分发到后端的Pod。通过水平扩展和自动伸缩机制，动态调整Pod数量，满足不同负载下的推理需求，降低整体延迟。