etcd - Tony Bai

本文永久链接 – 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 构建大规模系统的工程师，提供了无价的洞察与启示。

资料链接：https://bchess.github.io/k8s-1m/
项目链接：https://github.com/bchess/k8s-1m

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/09/26/self-reliant-programmer

大家好，我是Tony Bai。

“当代多数软件，对其用户而言是一种耻辱。”

最近，一篇措辞激烈、观点鲜明的《自立程序员宣言》（Self-Reliant Programmer Manifesto）在技术圈流传开来。它以一种近乎愤怒的姿态，抨击了现代软件开发中日益增长的复杂性、对臃肿工具的过度依赖以及脆弱的供应链。

对于许多沉浸在复杂框架和无尽工具链中的开发者来说，这份宣言可能显得有些“原教旨主义”。然而，在我们Go社区，当这篇文章被转发和讨论时，一种奇特的、会心一笑的共鸣油然而生。我们中的许多人看完后的第一反应是：“这不就是我们一直在说的Go语言哲学吗？”

这份宣言的核心呼吁——相信简单、最小化依赖、并勇于编写自己的工具——听起来就像是Go社区日常交流的“黑话”。

本文将和你一起解读这份“檄文”，并逐一印证，为什么它所倡导的“自立”之道，早已深深烙印在Go语言的DNA之中。

Go语言哲学：我们一直在坚持什么？

在解读宣言之前，让我们先回顾一下Go社区长期以来所珍视的一些核心价值观：

少即是多 (Less is exponentially more)：Go语言刻意保持规范的微小，避免引入带有额外认知负荷的特性。
清晰优于聪明 (Clear is better than clever)：代码首先是写给人读的，显式的错误处理、简单的控制流远比“魔法般”的语法糖更受推崇。
“自带电池” (Batteries Included)：一个强大的标准库，是我们抵御外部依赖泛滥的第一道，也是最重要的一道防线。
“一点复制胜过一点依赖” (A little copying is better than a little dependency)：这句社区谚语，体现了我们对引入新依赖的极度审慎。

现在，让我们带着这些“Go味十足”的理念，去看看《自立程序员宣言》都说了些什么。

宣言的核心法则 vs. Go的内在基因

法则一：“简单即是善” (Simple is good)

宣言说：“一切复杂的事物，都是由简单的东西构成的……你不需要四十二层抽象来实现一些简单的事情。”

这不就是我们所说的“少即是多”吗？ Go的设计哲学正是建立在对“简单性”的极致追求之上。它通过减少语言特性，来降低程序员的心智负担。当你在阅读一段Go代码时，你很少需要去猜测这段代码背后隐藏着什么复杂的继承链或元编程魔法。你所见即所得。

宣言强调：“理解事物的工作原理能帮助你建立更好的心智模型。” Go的显式错误处理 (if err != nil)虽然常被诟病冗长，但它强迫我们直面每一个可能出错的环节，而不是将其隐藏在try-catch的便利之下。这正是帮助我们建立健壮心智模型的绝佳实践。

法则二：“最小化依赖” (Minimises their dependencies)

宣言说：“更少的依赖意味着更少被包管理器的供应链攻击所伤害……更简单的代码意味着更好地理解你实际在使用的东西。”

这不就是我们“自带电池”和“一点复制胜过一点依赖”的实践吗？ Go强大的标准库，让我们在构建高性能Web服务、处理并发、加解密等无数场景下，都无需第一时间就去go get一个外部模块。

当确实需要外部功能时，社区文化也鼓励我们保持克制。与其为了一个简单的辅助函数就引入一个庞大的库及其数十个传递依赖，我们更倾向于将那几行代码直接复制到自己的项目中。这看似“原始”，却完美地践行了宣言的精神：完全掌控你自己的代码，并深刻理解它的每一行。

法则三：“编写自己的工具” (Writes their own tools)

宣言说：“更简单的工具意味着你可以独自工作……你无需依赖臃肿的CI、Docker、Kubernetes……”

这不就是Go语言被创造出来的核心目的之一吗？Go本身就是一门为构建工具和基础设施而生的语言。

静态编译与单二进制文件：go build产生的单一静态二进制文件，是分发和部署工具的终极形态。没有运行时依赖，没有复杂的安装脚本。
云原生世界的基石：Docker, Kubernetes, Terraform, Prometheus, etcd……这些定义了现代基础设施的工具，几乎无一例外都是用Go编写的。

我们Gopher不仅用Go构建应用，更用Go构建了我们赖以工作的整个世界。我们不满足于使用别人提供的、充满黑盒的工具，我们选择用我们自己的语言，为我们自己打造称手的兵器。这正是“自立程序员”精神的最高体现。