本文永久链接 – 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 所提供的那种级别的可靠性和持久性。

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

开辟新路：用 mem_etcd 绕行

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

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

1. 简化接口：通过对真实 K8s 流量的分析，作者发现 K8s 实际只使用了 etcd 接口中一个很小的子集。mem_etcd 只实现了这个最小必要子集，极大地降低了内部复杂性。
2. 优化数据结构：针对 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) 所有结果，选出全局最优的节点，并最终完成绑定。

峭壁上的“幽灵”

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

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

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

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

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

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

1. kube-apiserver 的 Watch 缓存：其内部基于 B-Tree 的 watchCache 实现，在高频更新下成为了新的锁争用点。
2. 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/10/19/flask-creator-choose-go

大家好，我是Tony Bai。

Armin Ronacher，这个名字在 Python 世界如雷贯耳。作为广受欢迎的 Web 框架 Flask 的创造者、Sentry 的首批工程师之一，他被公认为 Python 社区最具影响力的开发者之一。然而，最近在一场深度访谈中，他透露了一个足以让许多人感到惊讶的决定：

在他的新 AI 创业公司中，Go 成为了核心的后端语言。

为什么一位浸淫 Python 和 Rust 生态多年的顶尖开发者，会在 AI 创业的浪潮中，最终将信任票投给了 Go？这个选择的背后，并非一时兴起，而是一场关于务实主义、生态位和 AI 时代生产力的深刻权衡。

在这篇文章中，我们就来看看这位 Python 大师在 AI 时代技术选型的心路历程。

被放弃的“旧爱”——Python 的复杂性与 Rust 的“摩擦力”

要理解为什么选择 Go，我们必须先理解 Armin Ronacher 放弃了什么。他将自己比作一个拥有“分裂大脑”的程序员：一面是追求极致工艺的开源匠人，另一面是追求快速迭代的创业者。对于后者，他曾经深爱的 Python 和 Rust，都显得不再完美。

Python：深爱但日趋复杂

作为 Armin 的“母语”，Python 的务实和灵活性毋庸置疑，尤其是在数据处理和 ML 领域。但他坦言，随着时间的推移，Python 语言本身变得越来越复杂。“对于一众工程师来说，Go 反而比 Python 更容易写了，” 他在访谈中说道。对于一个需要快速构建、易于团队协作的后端服务来说，现代 Python 并非总是最佳选择。

Rust：开源世界的“瑞士腕表”，创业公司的“巨大摩擦力”

Armin 对 Rust 充满了敬意，称其为打造精密、高性能开源库的“瑞士腕表”。他在 Sentry 引入 Rust 处理二进制文件和解决性能瓶颈，取得了巨大成功。然而，当场景切换到需要快速迭代的初创公司时，Rust 的优点却可能转化为“摩擦力”：

• 极慢的编译速度：“这是一个巨大的因素。”
• 陡峭的学习曲线：借用检查器 (borrow checker) 等概念虽然强大，但也极大地增加了心智负担，拖慢了开发速度。“Rust 解决了许多‘Rust 形’的问题，” Armin 总结道，“但并非所有问题都是‘Rust 形’的。”

Go 的胜出——务实主义者的最终选择

正是在 Python 的日益复杂和 Rust 的高摩擦力之间，Go 以其独特的定位脱颖而出，成为了 Armin 创业之路上的务实之选。

精准的生态位：“为 Web 服务而生”

Armin 对 Go 的定位评价极其精准：

“我认为 Go 就是一门构建 Web 服务的好语言，而且基本上只专注于 Web 服务（可能还有一些命令行工具）。”

这看似一句“限制”，实则是一种褒奖。它意味着 Go 在其核心领域——网络编程和分布式系统——拥有一个高度专注、极其成熟且无与伦比的生态系统。对于一家构建网络服务的初创公司而言，这种专注性远比语言的“全能性”更有价值。

“它不会超级性感，” Armin 补充道，“但你可以期待它会长久存在。” 这种稳定性和可预测性，对于需要构建长期产品的公司来说，是至关重要的技术资产。

AI 时代的“超能力”：对 AI 编码助手更友好

这可能是整场访谈中最令人振奋的发现。作为一个重度 AI 编码工具的使用者，Armin 进行了一项实验：让 AI 用不同语言编写同一类程序，然后评估其成功率和代码质量。

他的结论是：Go 的表现远超 Python 和 Rust。

他分析其原因为：

“因为 Go 的抽象非常薄 (abstractions are very thin)。”

这句评价一语中的。Go 语言的小关键字集、简洁的语法、无隐式转换、明确的错误处理……所有这些被一些人批评为“不够强大”的设计，在 AI 模型眼中，恰恰成为了最清晰、最无歧义的指令。AI 更容易理解和生成地道的 Go 代码，因为语言本身留下的“灰色地带”和“魔法”最少。

在 AI 驱动开发的时代，Go 的“简单”，正从一种设计哲学，演变为一种实实在在的生产力优势。

Sentry 的教训——错误处理的隐性价值

Armin 在 Sentry 十年的经历，让他对错误处理有了深刻的理解。他指出，许多语言和运行时为了追求性能，往往会牺牲掉在生产环境中获取丰富错误信息的能力。

“许多语言的运行时经常忽略错误……它们没有携带正确的信息，而应用和库开发者也根本不考虑错误。”

这段话让我们不禁反思 Go 的 error 接口和错误包装 (error wrapping) 机制。虽然 if err != nil 常被诟病为冗长，但它强制开发者在每个环节都直面错误，并通过错误包装链，为我们提供了在生产环境中保留完整上下文的可能性。

Armin 的经验告诉我们，这种对错误信息的执着，并非“啰嗦”，而是在构建可观测、可维护系统时，一项极其宝贵的投资。

小结：为什么是 Go？

回到最初的问题：为什么是 Go？

Armin Ronacher 的选择，为我们提供了一个清晰的答案。他选择 Go，不是因为它拥有最前沿的特性，也不是因为它能解决所有问题。他选择 Go，是因为在一个充斥着复杂性和不确定性的 AI 创业时代，Go 提供了最宝贵的东西：

• 务实：它专注于解决 Web 服务的核心问题，不多也不少。
• 简洁：它的“薄抽象”使其在与 AI 协同工作时效率惊人。
• 健壮：它的错误处理哲学，以及在并发、部署上的优势，为构建可靠的系统奠定了基础。

一位来自 Python 世界的大师，最终用自己的技术选型，为 Go 的设计哲学投出了最宝贵的一票。这提醒我们，Go 的成功并非偶然，而是其核心设计原则在真实世界工程需求下，不断被验证的必然结果。

资料链接：https://www.youtube.com/watch?v=45kVol96IlM

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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