单集群 5 万节点：腾讯云 TKE 如何突破 etcd 大规模性能瓶颈

摘要：

本文从 etcd 性能瓶颈的本质、TKE 的优化方案、控制面架构演进及最佳实践四个维度，深度解析腾讯云 TKE 如何实现单集群 5 万 + 节点的稳定运行，为企业大规模容器集群建设提供技术参考。

一、Kubernetes 大规模化的核心挑战

随着企业容器化程度的不断深入，集群规模的增长已成为必然趋势。从数十节点到数千节点，再到数万节点，每一次规模跃升都对 Kubernetes 控制面提出了新的挑战。作为 Kubernetes 的核心存储后端，etcd 的性能直接决定了整个集群的扩展上限。

在原生 Kubernetes 架构中，所有集群状态数据都存储在 etcd 中——包括 Pod、Node、Service、ConfigMap 等资源对象及其变更历史。当集群规模达到一定量级后，etcd 面临的压力主要来自三个方面：Watch 事件的海量推送、List 操作的全量读取以及频繁的资源变更写入。任何一环出现瓶颈，都可能导致 API Server 响应延迟飙升，进而影响调度器的决策效率。

二、etcd 性能瓶颈的技术本质

2.1 Watch 事件的放大效应

在 Kubernetes 集群中，调度器、Controller Manager、kubelet 等组件通过 Watch 机制监听 etcd 中的数据变更。当一个 Node 上的 Pod 状态发生变化时，etcd 需要向所有 Watch 该资源的客户端推送事件。在万节点规模的集群中，这种一对多的事件分发会产生显著的放大效应——单次 Pod 更新可能触发数千个 Watch 事件的推送。

2.2 List 操作的穿透风险

当用户或控制器发起不带 ResourceVersion 参数的 List 请求时，API Server 会直接向 etcd 发起全量查询。在大规模集群中，这类请求一旦穿透到 etcd，会消耗大量数据库资源。特别是在故障排查场景下，运维人员习惯性执行的 kubectl get pod --all-namespaces 命令，可能在瞬间将 etcd 打垮。

2.3 序列化与反序列化的 CPU 开销

Kubernetes 的资源对象以 Protobuf 格式存储在 etcd 中，每次读写都需要进行序列化和反序列化操作。当集群中存在大量 CRD（Custom Resource Definition）或其他大型资源对象时，这些操作的 CPU 开销不容忽视。

三、TKE 的 etcd 性能优化方案

3.1 调度器 Go 重构与事件流解耦

针对原生调度器在大规模场景下的性能瓶颈，TKE 团队对调度器核心模块进行了深度优化。通过将关键路径从解释型语言重构成高性能 Go 实现，并引入事件流解耦机制，实现了 etcd Watch 事件吞吐量的显著提升。

具体而言，TKE 将单一的 Watch 通道拆分为按变更类型分级的优先级队列——Node 和 NodeStatus 变更走高优先级环形缓冲区，Pod 和 PVC 等资源走带背压控制的 Channel 池。通过 sync.Pool 复用 watch.Event 结构体，有效降低了 GC 压力。同时，将单 Watch 连接拆分为多个并行 Watch 流，按资源类型哈希分片，规避了单连接 TCP 窗口瓶颈。

3.2 etcd 过载保护机制

TKE 研发了 etcd 过载保护相关特性，包括 ReadCache 和 SkipLimit 两项核心能力。ReadCache 能够让 List 请求直接走 API Server 缓存，避免流量层层穿透到 etcd；SkipLimit 则对异常的大量 List 请求进行限速和熔断，保障控制面的稳定性。

这些策略可以通过 ConfigMap 方式一键下发，覆盖客户使用的主流 TKE 版本，无需业务方修改代码或重启 Pod。对于存量业务无法快速适配的场景，这一能力尤为重要。

3.3 API Server 胖瘦分离

在超大规模集群中，TKE 采用了 API Server 胖瘦分离的架构设计。将不同类型的请求路由到不同的 API Server 实例组——高频的读请求由轻量级的"瘦"API Server 处理，复杂的写操作和资源创建由功能完整的"胖"API Server 承担。这种分离架构有效避免了读写干扰，提升了整体吞吐量。

3.4 控制面组件按需伸缩

TKE 的控制面组件支持根据数据面规模进行按需伸缩。当集群中的 Pod 数量、CRD 数量或 Event 写入频率增长时，系统会自动评估当前控制面容量，并在必要时进行扩容。这种弹性能力确保了控制面始终具备足够的处理能力来应对数据面的变化。

四、大规模集群的选购配置建议

4.1 集群规格选型

TKE 提供了从 L5 到 L5000 共 9 档集群规格，每档对应不同的最大管理节点数和 Pod 数。选购时应根据业务实际情况选择合适的规格——例如计划部署 50 个节点、2,000 个 Pod，应选用 L100 而非 L50 的集群规格。

4.2 资源对象大小控制

建议每种资源类型的所有对象总和不超过 800MiB，每个资源对象大小不超过 100KB。过大的资源对象不仅占用更多 etcd 存储空间，还会增加序列化和网络传输的开销。

4.3 避免滥用 List 操作

应尽量避免对资源数量较多的集群发起类 List 操作，避免把 TKE 集群当数据库使用。如有查询集群全量资源的需求，建议使用 K8s 的 Informer 机制通过本地 Cache 查询，或使用带分页参数的请求方式。

五、典型大规模场景实践

5.1 超大规模在线业务

某头部互联网企业需要在单个集群内管理上万个节点、数十万个 Pod。通过采用 TKE 的大规模集群方案，结合 etcd 过载保护和 API Server 胖瘦分离架构，实现了控制面在高负载下的稳定运行。API 响应延迟保持在毫秒级，调度决策时间从分钟级缩短至秒级。

5.2 多租户平台场景

某云服务商需要在一个物理集群中为数百个租户提供隔离的命名空间。通过合理设置 ResourceQuota 和 LimitRange，配合 TKE 的控制面扩展能力，成功支撑了高密度多租户场景下的稳定运行。

六、监控与告警建议

在大规模集群的日常运维中，建议重点关注以下指标：

• etcd 的 leader 选举频率和任期长度
• API Server 的请求延迟分布（P50/P90/P99）
• etcd 的磁盘写入延迟和压缩状态
• 各控制面组件的 CPU 和内存使用率
• Watch 连接数和事件推送速率

TKE 提供了集群控制面组件的监控能力，集群管理员可以查看 Kubernetes 控制面性能，快速发现、排查和修复问题。

七、总结

TKE 通过调度器重构、etcd 过载保护、API Server 胖瘦分离和控制面按需伸缩等一系列技术手段，成功突破了原生 etcd 在大规模场景下的性能瓶颈，实现了单集群 5 万 + 节点的稳定运行，控制面吞吐量提升 10 倍以上，API 响应延迟降低至毫秒级。

对于正在规划大规模容器集群的企业而言，建议在方案设计阶段就充分考虑控制面的扩展能力，选择经过大规模生产验证的平台，并结合实际业务特征进行合理的规格选型和参数调优。

当你的业务增长到万级节点规模时，控制面的每一个毫秒延迟都会被放大。了解 TKE 如何通过调度器重构和 etcd 过载保护，支撑单集群 5 万 + 节点的稳定运行 → https://cloud.tencent.com/product/tke