OpenAI 宕机思考｜Kubernetes 复杂度带来的服务发现系统的风险和应对措施
12月11日，OpenAI 旗下 AI 聊天机器人平台 ChatGPT、视频生成工具 Sora 及其面向开发人员的 API 自太平洋时间下午 3 点左右起发生严重中断，耗费约三个小时才顺利恢复所有服务。
OpenAI 在事后报告中写道，“该问题源自新部署的遥测服务，此项服务无意间压垮了 Kubernetes 控制平面，导致关键系统发生连锁故障。 引发事故的根本原因就是新的遥测服务配置意外在大规模集群中产生了大量 Kubernetes API 负载，导致控制平面不堪重负并破坏了基于 DNS 的服务发现能力。”
可见，即使如实力强大的OpenAI，面对复杂Kubernetes架构，也不能很好处理Kubernetes服务发现和控制面解耦的问题。造成这个问题的关键原因在于容器调度和业务关键服务发现链路耦合在一起，互相干扰，Kubernetes控制面故障影响了业务服务发现链路。那么，Kubernetes体系下应如何选择服务发现系统，进一步提升业务稳定性呢？笔者认为，大型业务的服务发现系统应该具备高可靠性，高可伸缩性，高性能及高可维护性等特点，采用独立服务发现系统是一种相对较好的方案。本文以社区主流服务发现系统Nacos为例，从可靠性、可伸缩性、高性能、可维护性等4个方面探讨如何提升Kubernetes中微服务应用的稳定性。
一、如何提升系统可靠性
产品、系统在规定的条件下，规定的时间内，完成规定功能的能力称为可靠性。