OpenAI 故障复盘 - 阿里云容器服务与可观测产品如何保障大规模 K8s 集群稳定性

原创

于 2025-01-08 11:20:19 发布 · 1.4k 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#阿里云 #kubernetes #云计算 #容器 #AI #openai

OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性

本文作者：

容器服务团队：刘佳旭、冯诗淳

可观测团队：竺夏栋、麻嘉豪、隋吉智

一、前言

Kubernetes(K8s)架构已经是当今 IT 架构的主流与事实标准（CNCF Survey[1]）。随着承接的业务规模越来越大，用户也在使用越来越大的 K8s 集群。Kubernetes 官方建议的最大集群规模是 5000 节点。甚至，如 OpenAI 通过技术优化，曾将 K8s 集群扩展至 7500 节点（Scaling Kubernetes to 7,500 nodes[2]）。这种千级别节点的大规模 K8s 集群，会容易引起分布式系统内部瓶颈，但也增加了系统的脆弱性。

1.1 OpenAI 故障复盘分析

近日 OpenAI 旗下 AI 聊天机器人平台 ChatGPT、视频生成工具 Sora 及其面向开发人员的 API 自太平洋时间 12 月 11 日下午 3 点左右起发生严重中断。故障的根因是在上线获取集群控制面监控数据的新的新可观测功能时，可观测的组件会在每个集群节点上对 K8s Resource API 发起访问，突发造成巨大的 Kubernetes API 负载，导致 K8s 控制平面瘫痪，进而使 DNS 服务发现功能中断，最终影响到了业务。（OpenAI 故障报告[3]）

1.2 阿里云如何保障大规模 K8s 集群稳定性，以应对如此故障

这次故障在阿里云产品体系中直接相关的是阿里云容器服务（Kubernetes），以及阿里云可观测产品（Prometheus、Telemetry）产品。

故，我们对本次 OpenAI 故障高度重视，希望借此机会介绍我们在大规模 K8s 场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案：包括在 K8s 和 Prometheus 的高可用架构设计方面、事前事后的稳定性保障体系方面。

阿里云容器服务团队(负责 Kubernetes 云产品)与阿里云可观测团队(负责 Prometheus 云产品)旨在为用户提供稳定可靠的 K8s 集群环境，以及使用可观测体系帮助用户构建全面的稳定性保障体系。我们的客户也有非常多上千节点的大规模 K8s 集群环境，在大规模 K8s 集群的稳定性保障体系方面有一定经验沉淀。

OpenAI 的大规模集群故障也是我们很好的学习案例，这里本文想借助这次案例为契机：

1. 介绍阿里云容器服务（K8s）、可观测团队（Prometheus）的大规模集群稳定性建设。

2. 以及用户在大规模 K8s 集群场景下的最佳实践，用户也需要采用正确的使用方式才能一起保障大规模 K8s 集群的稳定性。

二、当 K8s 集群规模过大会遇到哪些风险与挑战

K8s 集群控制面/数据面数据流图

2.1 K8s 集群的本质是分布式系统，剖析其中瓶颈才能对症下药

首先我们要简单介绍下 K8s 集群控制面、数据面的大致架构：

控制面负责集群的 API 层、调度、资源管理、云资源管理等控制面功能，K8s 组件：

apiserver/etcd/scheduler/kube-controller-manger/cloud-controller-manager

数据面负责集群的节点管理、Pod 生命周期管理、Service 实现等数据面功能，承载业务 Pod 的主体。包含：K8s 组件，kubelet/kube-proxy；系统组件，日志、监控、安全等组件；其他组件，用户业务组件。

控制面、数据面和云资源是有机结合的整体！集群的全链路中，任何一个组件、子链路成为瓶颈，都可能影响到集群的整体稳定性。

我们需要从 K8s 系统中发现瓶颈、治理以及优化瓶颈，最终实现 K8s 系统在给定云资源情况下的稳定、高效的利用。

三、稳定性增强-阿里云在大规模 K8s 集群场景的保障增强

3.1 大规模容器服务 ACK 集群的稳定性保障机制增强

大规模 ACK 集群通过高可用配置、托管组件稳定性增强和系统组件优化等综合技术，对集群的的稳定性进行全面优化和提升。

通过控制面可用区级别和节点级别的高可用配置，全部控制面组件实现高可用打散。以 APIServer 为例，多副本跨 AZ、跨节点高可用部署方式，任何一个 AZ 失效不影响服务可用性。在 3AZ 地域，ACK 托管集群控制面的 SLA 是 99.95%。对于不具备 3AZ 的地域，ACK 托管集群控制面 SLA 是 99.5%（不具备单可用区的故障容忍）。

托管核心组件进行弹性、资源隔离、限流、请求处理能力等方面的稳定性优化，例如：APIServer 支持自动弹性 VPA+HPA、etcd 支持基于推荐资源画像的 VPA、APIServer 的动态限流等等。

ACK 系统组件严格按照最佳规范进行优化和改造，降低对控制面的压力，包括：对控制面的 LIST 请求、消除对控制面资源消耗大的请求；对非 CRD 资源的 API 序列化协议不使用 JSON，统一使用 Protobuf 等等。