etcd - Tony Bai

标签 etcd 下的文章

13万节点！Google 如何打破 Kubernetes 的物理极限，构建全球最大集群

十一月 26, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/26/how-google-built-a-130000-node-k8s-cluster

大家好，我是Tony Bai。

Kubernetes 的官方支持上限通常被认为是 5,000 到 15,000 节点。然而，在 AI 时代的算力军备竞赛中，这个数字显得有些“捉襟见肘”。

近日，Google Cloud 发布了一份重磅技术报告，揭示了他们如何在 GKE (Google Kubernetes Engine) 上成功运行了一个130,000 节点的超大规模集群——这是目前已知全球最大的 Kubernetes 集群，其规模是 GKE 官方支持上限（65,000 节点）的两倍，更是开源 Kubernetes 社区上限的近十倍。

这不是一次规模的堆砌，而是一次涉及控制平面、调度器、存储和网络的系统级工程实践，极具参考价值。Google 是如何做到的？让我们深入其架构内部，一探究竟。

背景：AI 时代的“巨兽”需求

推动这一极限挑战的核心动力，是日益庞大的 AI 工作负载。随着大模型训练对算力需求的指数级增长，客户不再满足于万卡集群，而是向着 10万节点 的规模进军。

在这个量级下，挑战不仅来自芯片的短缺，更来自电力和数据中心的物理限制。一个拥有数万块高性能 GPU 的集群，其功耗可能高达数百兆瓦，必须跨越多个数据中心部署。这要求 Kubernetes 不仅要管理庞大的资源，还要具备跨故障域、跨数据中心的极致编排能力。

核心创新：四大技术支柱

为了支撑起这座“13万节点”的摩天大楼，Google 对 Kubernetes 的底层架构进行了四项关键的“手术”。

1. 读操作的极致优化：一致性缓存

在 13 万节点的集群中，数以百万计的 Pod 和对象会产生海量的 API 请求。如果所有读请求都直接打到 etcd（或 GKE 使用的 Spanner），数据库瞬间就会被压垮。

Google 的解决方案是：让 API Server 直接从内存缓存中服务读请求，同时保证强一致性。

具体来说，就是通过引入 Consistent Reads from Cache (KEP-2340)，API Server 可以利用其内存中的 Watch Cache 来服务 GET 和 LIST 请求。

系统会确保缓存中的数据在服务请求前是可验证的最新状态（verifiably up-to-date），从而在不牺牲一致性的前提下，大幅降低了底层数据库的压力。

同时，通过 Snapshottable API Server Cache (KEP-4988)，API Server 甚至可以直接从内存中构建 B-tree 快照，来服务带有 resourceVersion 的历史数据查询，彻底消除了“读放大”问题。

2. 存储后端的无限扩展：基于 Spanner 的分布式键值存储

标准的 Kubernetes 使用 etcd 作为存储后端，但在 13 万节点的规模下，etcd 的容量和吞吐量成为了瓶颈。

GKE 替换了这一层，使用了一个基于 Google Spanner 的专有键值存储系统。

性能数据：在测试中，该存储系统轻松支撑了 13,000 QPS 的租约 (Lease) 更新操作，确保了 13 万个节点的健康检查心跳畅通无阻。
容量：在峰值时，数据库中存储了超过 100 万个 Kubernetes 对象，依然保持了极低的延迟和极高的稳定性。

3. 调度器的进化：Kueue 与工作负载感知

默认的 Kubernetes 调度器是“Pod 中心”的，它一个个地调度 Pod。但这对于 AI 训练任务来说远远不够——AI 任务通常需要“全有或全无” (All-or-Nothing) 的调度保证（即 Gang Scheduling）。

Google 引入了 Kueue，一个构建在原生调度器之上的作业级 (Job-level) 队列管理器。Kueue 负责决定何时接纳一个作业，基于配额、优先级和公平策略进行裁决。它实现了Gang Scheduling，确保一个训练任务的所有 Pod 要么全部启动，要么全部排队，避免了资源死锁。

4. 数据访问的加速：GCS FUSE 与本地化缓存

对于 AI 训练，数据加载速度至关重要。GKE 利用 Cloud Storage FUSE 配合并行下载和区域性缓存 (Anywhere Cache)，让存储在 GCS 对象存储中的海量数据，能像本地文件系统一样被 Pod 高速访问。这使得数据加载延迟降低了 70%，确保了 GPU 不会因为等待数据而空转。

实战演练：一场 13 万节点的压力测试

为了验证这套架构，Google 设计了一个包含四个阶段的极限压力测试，模拟了真实的 AI 生产环境。下图展示了整个测试的时间线和四个关键阶段。

图注：13万节点压力测试的完整执行时间线

阶段一：基线测试 —— 1000 Pods/秒的狂飙

在一个空集群中，一次性启动 130,000 个 Pod 的大规模训练任务。结果显示，控制平面极其稳定，支撑了高达 1,000 Pods/秒 的创建和调度吞吐量。

图注：控制平面的吞吐量监控

阶段二：混合负载与争抢 —— Kueue 的“铁腕”

测试引入了大量低优先级的批处理作业填满集群，然后突然提交高优先级的微调任务。此时，Kueue 展现了惊人的动态调整能力：它在 93 秒内精准抢占了 39,000 个低优 Pod，瞬间腾出资源给高优任务。

图注：Kueue 正在进行资源调度

阶段三与四：突发流量与弹性恢复

在第三阶段，模拟了“双十一”式的流量洪峰，提交最高优先级的推理服务。系统再次平稳应对，甚至在极高负载下，推理 Pod 的 P99 启动延迟仍控制在 10 秒左右，这对于对延迟敏感的在线服务至关重要。

图注：不同负载类型下的 Pod 启动延迟

最后，当流量退去，系统自动释放资源，重新接纳之前被挂起的低优任务，实现了资源的完美闭环和极致利用。

小结：这就是未来的基础设施

Google 的这次 13 万节点实验，不仅是秀肌肉，更是为整个云原生社区指明了方向。它证明了 Kubernetes 在经过合理的架构优化后，完全有能力承载 AI 时代最苛刻的算力需求。

从内存一致性缓存到工作负载感知的调度，这些在极限场景下打磨出的技术创新，最终都会反哺到普通的 GKE 集群，甚至回馈给开源社区（如 Kueue 和 KEP 提案）。

对于我们每一位架构师而言，这都是生动的一课：真正的可扩展性，不仅仅是堆砌硬件，更是对系统每一个环节——从读写路径到调度逻辑——进行极致的工程优化。

资料链接：https://cloud.google.com/blog/products/containers-kubernetes/how-we-built-a-130000-node-gke-cluster/

聊聊你对“规模极限”的看法

Google的13万节点集群，为我们展示了云原生技术栈在AI时代的巨大潜力。在你看来，Kubernetes或其他云原生技术的下一个“物理极限”会是什么？除了Google提到的这四项优化，你认为还有哪些关键技术能帮助我们突破规模的瓶颈？或者，你在自己的工作中，遇到过哪些有趣的“规模化”挑战和解决方案？

欢迎在评论区留下你的真知灼见，让我们一起探讨未来基础设施的模样！

如果这篇文章让你对大规模系统设计有了新的启发，别忘了点个【赞】和【在看】，并分享给更多对技术极限充满好奇的同伴！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

一个 Kubernetes 集群的“珠峰攀登”：从 10 万到 100 万节点的极限探索

十月 20, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/10/20/k8s-1m-intro

大家好，我是Tony Bai。

在云原生的世界里，Kubernetes 集群的规模，如同一座待征服的高峰。业界巨头 AWS 已将旗帜插在了 10 万节点的高度，这曾被认为是云的“天际线”。然而，一位前OpenAI工程师(曾参与OpenAI 7.5k节点的Kubernetes集群的建设)发起了一个更雄心勃勃、甚至堪称“疯狂”的个人项目：k8s-1m。他的目标，是向着那座从未有人登顶的、充满未知险峻的“百万节点”之巅，发起一次单枪匹马的极限攀登。

这不简单是一个节点数量级的提升，更像是一场对 Kubernetes 核心架构的极限压力测试。虽然我们绝大多数人永远不会需要如此规模的集群，但这次“攀登”的日志，却为我们绘制了一份无价的地图。它用第一性原理，系统性地拆解和挑战了 Kubernetes 的每一个核心瓶颈，并给出了极具创意的解决方案。

对于每一位 Go 和云原生开发者而言，这既是一场技术盛宴，也是一次关于系统设计与工程哲学的深刻洗礼。

穿越“昆布冰瀑”——征服 etcd 瓶颈

在任何一次珠峰攀登中，登山者遇到的第一个、最著名、也最危险的障碍，是变幻莫测的“昆布冰瀑”。在 k8s-1m 的征途中，etcd 扮演了同样的角色。

无法逾越的冰墙

一个百万节点的集群，仅仅是为了维持所有节点的“存活”状态（通过 Lease 对象的心跳更新，默认每 10 秒一次），每秒就需要产生 10 万次写操作。算上 Pod 创建、Event 上报等其他资源的不断变化，系统需要稳定支撑的是每秒数十万次的写入 QPS。

然而，项目的发起者使用 etcd-benchmark 工具进行的基准测试表明，一个部署在 NVMe 存储上的单节点 etcd 实例，其写入能力也仅有 50K QPS 左右。更糟糕的是，由于 Raft 协议的一致性要求，增加 etcd 副本反而会线性降低写吞吐量。

由此来看，etcd，这座看似坚不可摧的冰墙，以其当前为强持久性和一致性而设计的架构，在性能上与百万节点集群的需求存在着数量级的差距。

登山者的智慧：我们真的需要硬闯冰瀑吗？

面对这个看似无解的矛盾，作者没有选择渐进式优化，而是提出了一个极具颠覆性的观点：大多数 Kubernetes 集群，并不需要 etcd 所提供的那种级别的可靠性和持久性。

临时资源的主导：集群中的绝大多数写入，都是针对临时资源 (ephemeral resources)，如 Events 和 Leases。即使这些数据在灾难中丢失，其影响也微乎其微。
声明式 API 的韧性：Kubernetes 的声明式 API 和控制器模式，使其天生具备强大的自愈能力。即使部分状态丢失，控制器也会自动地将系统调谐回期望的状态。
GitOps 时代的“牛群”哲学：在现代 GitOps 流程中，集群的状态真理之源是 Terraform、Helm 或 Git 仓库。在极端情况下，重建一个集群，往往比从备份中恢复一个精确到毫秒的状态要容易得多。

开辟新路：用 mem_etcd 绕行

基于以上洞察，作者没有硬闯“冰瀑”，而是构建了一条全新的、更高效的“绕行路线”——mem_etcd。它并非一个“更好的 etcd”，而是一个被“阉割”和“魔改”的 etcd：

放弃强持久性：mem_etcd 将 fsync 的决策权完全交给使用者。通过内存存储或带缓冲的 WAL 日志，它将写入性能提升了数个数量级。基准测试结果显示，在关闭 fsync 的情况下，mem_etcd 的吞吐量可轻松超过 1M QPS，而延迟则降低到几乎可以忽略不计。

简化接口：通过对真实 K8s 流量的分析，作者发现 K8s 实际只使用了 etcd 接口中一个很小的子集。mem_etcd 只实现了这个最小必要子集，极大地降低了内部复杂性。
优化数据结构：针对 K8s 的键空间结构，mem_etcd 采用了全局哈希表 + 分区 B-Tree 的混合数据结构，实现了 O(1) 的键更新和 O(log n) 的范围查询。

通过替换 etcd 这个“心脏”，作者成功穿越了第一个、也是最大的障碍，通往更高海拔的道路豁然开朗。

开辟“希拉里台阶”——重构分布式调度器

成功穿越“冰瀑”后，登山者面临的是更具技术挑战的垂直岩壁，如同珠峰顶下的“希拉里台阶”。在这里，Kubernetes 的“大脑”——kube-scheduler——成为了新的瓶颈。

无法攀登的峭壁

今天的调度器，其核心算法复杂度约为 O(n*p)（n 是节点数，p 是 Pod 数）。在百万节点、百万 Pod 的场景下，这意味着 1 万亿次级别的计算。作者的基准测试显示，在 5 万节点上调度 5 万个 Pod，就需要 4.5 分钟，这距离“1 分钟调度 100 万 Pod”的目标相去甚远。

新的攀登技术：Scatter-Gather

作者没有试图让一个调度器“爬得更快”，而是借鉴了分布式搜索系统的经典“分片-聚合”(Scatter-Gather) 模式，让成百上千个“登山队员”同时向上攀登。

核心思想：将 100 万个节点视为搜索引擎中的 100 万篇“文档”，将待调度的 Pod 视为一次“搜索查询”。
架构：
1. 引入一个或多个 Relay（中继）层，负责接收新的 Pod 请求。
2. Relay 将 Pod “分发” (Scatter) 给成百上千个并行的 Scheduler 实例。
3. 每个 Scheduler 实例只负责对一小部分节点（一个“分片”）进行过滤和打分。
4. 所有 Scheduler 将各自的最优解返回给 Relay。
5. Relay “聚合” (Gather) 所有结果，选出全局最优的节点，并最终完成绑定。

峭壁上的“幽灵”

这个优雅的架构在现实中遇到了两大“幽灵”般的挑战：

长尾延迟 (Long-tail Latency)：作者引用了 Jeff Dean 的著名论文《The Tail at Scale》，指出在需要数千个调度器紧密协调的系统中，你永远要为那最慢的 1% 付出代价。这个延迟“毛刺”的主要来源，正是 Go 的垃圾回收 (GC)。
Watch Stream 的“饥饿”问题：作者发现，在高吞吐量下，apiserver 的 Watch Stream 会出现长达数十秒的“失速”，导致 Relay 无法及时获取到新的待调度 Pod。

为了对抗这些“幽灵”，作者采取了一系列极限优化手段：从绑定 CPU、激进的 GC 调优 (GOGC=800)，到做出一个极端的接口变更——用 ValidatingWebhook 替代 Watch，将 Pod 的发现延迟降到了最低。

挺进“死亡地带”——直面 Go GC 的终极挑战

当架构层面的两大峭壁被征服后，攀登进入了海拔 8000 米以上的“死亡地带”。这里的敌人不再是具象的冰川或岩壁，而是“稀薄的空气”——那些看不见、摸不着，却能瞬间让最强壮的登山者倒下的系统性瓶颈。

当 etcd 被替换、scheduler 被分片后，瓶颈最终会转移到哪里？作者给出了一个对 Go 社区极具启发性的答案：

kube-apiserver 的 Watch 缓存：其内部基于 B-Tree 的 watchCache 实现，在高频更新下成为了新的锁争用点。
Go 的垃圾回收器 (GC)：这被认为是最终的、最根本的聚合限制器。在极限规模下，kube-apiserver 会产生并丢弃海量的小对象（在解析和解码资源时），这种巨大的内存流失 (churn) 会给 GC 带来无法承受的压力。增加 apiserver 的副本也无济于事。

结论：在超大规模场景下，Go 的 GC 成为了那个最后的、最稀薄的“空气”。

小结：登顶之后 — 地图的价值

k8s-1m 项目，与其说是一个工程实现，不如说是一次勇敢的“思想实验”和极限探索。它成功地将旗帜插在了“百万节点”的顶峰，但其真正的价值，是为后来的“登山者”（其他工程师）绘制了一份详尽的地图。

这份地图向我们揭示了：

第一性原理的力量：勇敢地质疑系统中那些“理所当然”的核心假设，是通往数量级提升的唯一路径。
瓶颈的迁移：系统优化的过程，就是不断将瓶颈从一个组件推向另一个组件的过程。
Go 的伟大与局限：Go 是构建 Kubernetes 这样的云原生巨兽的理想语言，但即便是 Go，在绝对的规模面前，其核心特性（如 GC）也终将面临极限。

这个项目如同一面棱镜，不仅折射出 Kubernetes 架构的未来演进方向，也为我们每一位使用 Go 构建大规模系统的工程师，提供了无价的洞察与启示。