K8S坚决不背锅，OPEN AI宕机事件背后的技术内幕

虽然 OPEN AI 在人工智能领域首屈一指，但是在自己不擅长的云计算领域，同样是一群草台班子在修修补补。12 月 11 日下午 3:16 至下午 7:38 期间，ChatGPT，API，Sora等核心服务开始出现不可用问题，整个过程经历了近 4 个小时，可谓持续时间之长，文末有具体的故障报告，可以参考。其中以下几点值得我们学习和改进。

背景是 OPEN AI 为了提高集群整体的可靠性，部署一套监控指标采集服务，该监控指标采集服务需要依赖 Kubernetes 控制面的 API Server，指标采集一般运行在数据面，这里数据面可以简单理解为做计算的节点，控制面是做配置管理的节点，具体介绍可以见：Kubernetes入门培训（内含PPT）A Big Picture of Kubernetes

问题就出在运行在各个计算节点上的指标采集服务（OPEN AI官方没有披露这样做的具体原因，我推测需要通过 Kubernetes API Server 来获取集群的资源信息），频繁访问API Server，直接把控制面的 master 节点负载拉的很高；相当于就是自己数据面的 Node 节点攻击了控制面的 master 节点。CNCF 官方听了都直呼内行，太了解我们了，不过要自己背锅。

这本身也没什么，最起码不影响数据面的 POD 运行，关键是还有 DNS 解析服务依赖了 Kubernetes 控制面，控制面挂了影响了 DNS 解析服务，进而影响了数据面的 POD 运行。

可能有些人要问了，DNS 解析服务本质上运行在数据节点，为什么要访问控制面？

可能在某些配置中，DNS 可能会被设置为查询外部 DNS 服务器，而这些外部 DNS 服务器的配置可能存储在 Kubernetes 中（例如，ConfigMap），DNS 可能需要访问 API Server 来获取这些配置。为什么做这些 OPENAI 并没有详细说明。

针对这些问题，作为运维从业者的一员，我们应该如何避免呢？

首先对于有规模的集群，要做到控制面和数据面分离，即控制面只专注于管理工作，而不要参与到数据面，一旦出现问题，就会互相影响。侧面影响恢复时间。

然后对于 OPEN AI 这种需要频繁查询 master 节点的场景，建议考虑使用缓存或者 Watch 机制（一种事件推送机制，一旦 Watch 请求成功，API Server 会开始监控指定资源的变化。当资源发生变化（如创建、更新或删除）时，API Server 会将这些事件以 JSON 格式推送到客户端。）来减少对 API Server 的直接查询。同样要保证控制面的 API Server 高可用，确保 coreDNS 能够访问多个 API Server 实例，以避免单点故障。针对 OPEN AI 这种场景也可以考虑使用 NodeLocal DNSCache 机制，降低 DNS 查询次数。

最后 Kubernetes 从 1.13 版本开始支持各种级别的限流机制，比如 APF（兼顾了 API 优先级和公平性） 这样避免了一个错误的客户端发送大量请求可能造成其他客户端请求异常，也不支持突发流量。互联网环境下，无论任何场景都要配置限流，因为你根本不知道业务有哪些骚操作。

另外要质疑下 OPEN AI 的基础设施团队，难道没有灰度发布吗？正常情况下的集群操作变更时间都是在一周左右，甚至更长（一般都是以天为级别1%、5%、15%、50%、80%、100%），OPEN AI 只用了一天就完成了所有集群的变更和运行。

原创不易，随手关注或者”在看“，诚挚感谢！