OpenAI 宕机思考｜Kubernetes 复杂度带来的服务发现系统的风险和应对措施

王建伟，Nacos committer

12月11日，OpenAI 旗下 AI 聊天机器人平台 ChatGPT、视频生成工具 Sora 及其面向开发人员的 API 自太平洋时间下午 3 点左右起发生严重中断，耗费约三个小时才顺利恢复所有服务。 

OpenAI 在事后报告中写道，“该问题源自新部署的遥测服务，此项服务无意间压垮了 Kubernetes 控制平面，导致关键系统发生连锁故障。 引发事故的根本原因就是新的遥测服务配置意外在大规模集群中产生了大量 Kubernetes API 负载，导致控制平面不堪重负并破坏了基于 DNS 的服务发现能力。” 

可见，即使如实力强大的OpenAI，面对复杂Kubernetes架构，也不能很好处理Kubernetes服务发现和控制面解耦的问题。造成这个问题的关键原因在于容器调度和业务关键服务发现链路耦合在一起，互相干扰，Kubernetes控制面故障影响了业务服务发现链路。那么，Kubernetes体系下应如何选择服务发现系统，进一步提升业务稳定性呢？笔者认为，大型业务的服务发现系统应该具备高可靠性，高可伸缩性，高性能及高可维护性等特点，采用独立服务发现系统是一种相对较好的方案。本文以社区主流服务发现系统Nacos为例，从可靠性、可伸缩性、高性能、可维护性等4个方面探讨如何提升Kubernetes中微服务应用的稳定性。 

一、如何提升系统可靠性 

产品、系统在规定的条件下，规定的时间内，完成规定功能的能力称为可靠性。 

解耦控制面与运行时 

众所周知，Kubernetes主要工作资源调度，更偏向运维系统一些。从架构合理性上讲，运行时与控制面的系统不应耦合在一起， 甚至即使运维系统挂了也不会影响运行时。服务发现是运行时需求，而Kubernetes服务发现与运维系统绑定，一旦Kubernetes故障，上层运行态应用会受到致命影响。 

Kubernetes服务发现依赖API Server，而API Server被非常多的组件调用，任何组件异常调用都有可能把 API Server打挂，进而影响服务发现。以OpenAI这次故障为例，本来是要增强系统的可观测性， 但因可观测组件的大量调用把API Server打挂了，导致系统DNS解析发生故障。如果服务发现体系相对独立，不依赖或弱依赖Kubernetes控制面，本次故障是可以避免的。 

Nacos作为独立注册配置中心，可以不依赖Kubernetes独立部署，面向运行时设计，且有遵循多项面向失败原则，帮助业务服务发现与底层运维系统结构隔离，做到运维态系统故障不影响运行态系统，大大提高系统可靠性。 

提升系统容灾能力 

首先，Nacos可以帮助提升部署在Kubernetes上微服务体系的容灾能力。先讲一个实际案例，2023年11月，国内某头部出行服务公司的app突然出现大面积报错，导致长达几十个小时的服务不可用，影响大量用户正常出行。据官方发布通过，此次故障原因是底层软件异常导致（据推测为Kubernetes升级出现异常）。 

对于大规模微服务系统，Kubernetes集群容灾是系统稳定性非常重要的一环。通常，为了实现Kubernetes集群级别容灾，我们通常会把应用部署在多个Kubernetes上。这样，即使一个Kubernetes集群出现问题，还有另一个集群可以提供服务。但因