100年后 K8s 还会存在吗？创始人 Brendan Burns：它将像 Linux 一样消失在 AI 之下

软件的宿命，最终都是走向死亡。（The inevitable trajectory of software is death.）

编译 | 王启隆

出品丨AI 科技大本营（ID：rgznai100）

K8s 最早的 MVP，大概花了不到一周就写出来了。

几个人，几台机器，一个很粗糙的 demo：能把容器分发出去，能做最基础的负载均衡，进程挂了能自动拉起，升级时能从 v1 切到 v2。放到今天看，这样的开场甚至有点寒酸。很难把它和后来那个改写了云原生格局、几乎重塑了整个云计算语言体系的Kubernetes联系在一起。

但这段历史最值得回看的，恰恰不是 Kubernetes 后来如何成为事实标准，而是它在最开始为什么必须被做出来，而且必须被开源。

今天看到Brendan Burns（Kubernetes 联合创始人，后来参与创办了 Heptio，如今在微软 Azure 担任 Technical Fellow / CVP）的最新访谈，最有意思的地方，不是他又复述了一遍 Kubernetes 的成功史，而是他把很多人默认已经写进历史的事情，重新拉回到了那个还没有结果的时刻：

• Kubernetes 最初只是一个几天拼出来的 demo，但 Brendan Burns 当时就已经意识到：这种东西不可能永远只属于一家云厂商
  

• Google 开源 Kubernetes，不是因为理想主义，而是因为最现实的判断：你不做，别人也会做，而且你会失去定义它的机会
  

• Kubernetes 后来统一了整个云原生生态，但在 Brendan 看来，它最值得回看的，反而不是崛起，而是它总有一天也会退场
  

• 真正成熟的基础设施，往往不是突然死掉，而是像 Linux 一样，活着，却越来越少被人单独讨论
  

• AI 时代最可能发生的，不是 Kubernetes 被正面击败，而是它被埋进更深的一层，变成默认存在、但不再被看见的系统地基

以下为这场对话的全文翻译。

Google 为什么非做 Kubernetes 不可?

Q：如果当年你要向 Google 管理层解释，为什么要为整个行业去做 Kubernetes，你会怎么说？

Brendan Burns：其实早期最难的部分，不是把项目做出来，而是把这件事讲明白。

在我们自己脑子里，这件事很清楚，但怎么把它说到足够有说服力，让别人也认同，并不容易。我们当时大概是从几个角度去讲。

一个很重要的背景，是MapReduce 的教训。那时候 Hadoop 和所谓的大数据革命都很热。Google 写了最早的 MapReduce 白皮书，但后来真正被行业广泛采用的，是 Hadoop 这个开源实现。Google 提出了最初的想法，可生态并没有围着 Google 转。别人读了你的论文，做了一个相似但不完全相同的系统，最后真正跑起来、真正被大规模使用的，不是你的东西。

所以当时一个核心判断就是：如果 Google 只是继续发白皮书，而不把东西做成一个别人真的能跑、能部署、能用的系统，那就不可能真正站在技术演进的驾驶位上。

再往下，就是为什么会是容器，而不是继续围绕虚拟机做文章。我们的判断是，随着软件越来越成为关键基础设施，大家一定会需要一种“自动驾驶”式的系统去管理应用。我们在 Google 内部已经很清楚，想把复杂软件稳定跑起来，不能只靠人盯着，必须有系统帮你处理部署、调度、恢复这些事。这个需求不是可有可无，而是软件复杂度走到一定阶段后，一定会出现的东西。

真正最有意思的，是最后那个问题：为什么一定要开源？

很多人会说，你已经说服我这东西值得做了，那为什么不把它做成 Google Cloud 独占的能力？这样不是更有商业价值吗？

可我们的判断恰恰相反。因为如果你把它做成一个只在自己平台上能用的东西，你反而赢不了。这个世界上还有很多用户不在你的平台上，他们在别的云上，也可能在本地机房里。如果你把这些人全挡在外面，他们不会等你，他们只会自己再做一个替代品。

开源生态之所以经常能赢，就是因为它能在更多地方运行。Linux 为什么能赢？很重要的一点，就是它可以去任何地方。对 Google Cloud 来说，如果你本来就不是市场第一，就更不能把这种东西做成封闭武器。你得让所有人都能用它，再确保它在你的平台上最好用。这样即便别人不在你的平台上，他们也会先听你怎么定义问题、怎么讲这个方向。

说得再直接一点：反正这个世界一定会出现一个开源版本。问题只是，这个开源版本到底是你做，还是别人做。

Q：所以从商业上说，Google 当时是想借 Kubernetes 改变云计算的竞争格局？

Brendan Burns：对，这是很重要的一部分。

如果市场上已经有人把虚拟机这套东西做成主流，而你能讲出的故事只是“我们也有一套类似的，只是在某些地方更好一点”，那其实很难。你会一直活在别人的叙事里，一直在追别人的尾灯。

但如果你定义了一块新战场，情况就完全不一样了。你不再只是追赶别人，而是开始由你来组织问题、组织语言。即便别人最后没有直接跑在你的平台上，他们也会先把注意力放到你这里，因为这个方向是你先讲出来、先做出来的。

这种“话语权”很难量化，但它非常重要。它改变的是整个市场里谁在定义未来，谁在主导叙事。

当然，今天回头看，Google Cloud 也没有因为 Kubernetes 一下子变成市场第一，所以你不能把这件事讲成一个简单的商业胜利故事。但 Kubernetes 的确把 Google 放到了云原生时代最核心的话语位置上，这一点我觉得没什么可争议的。

Q：你们最早做出来的那个 demo，到底是什么样子？

Brendan Burns：其实非常简单。

大概就是一个最基础的控制界面，能把容器部署出去，能把它分发到几台机器上，也能做一点很基础的负载均衡。比如你访问同一个入口，它会告诉你“我是副本 1”，刷新一下可能又变成“我是副本 3”，借这个让你看到，它确实已经被复制并且分散到不同机器上了。

另外还有很基础的健康检查。你把进程杀掉，它能重新拉起来。再加上一个很初级的版本升级演示，能从 v1 切到 v2。差不多就是这些。

今天回头看，这当然很原始，谈不上什么完整产品。但对说服别人来说已经够了。因为那不是一页 PPT，也不是一份概念文档，而是一个真实能跑起来的东西。

一个不到一周做出的 demo，后来改写了云计算

Q：这个最初的 MVP，花了多久做出来？

Brendan Burns：不到一周吧，大概四五天。

当然，那真的是一个“能省的都省了”的版本。所有能走的捷径都走了。很多底层能力也不是从零开始自己造，而是尽量借助现成的开源项目，把能拿来的东西拿来，再用一些 glue code 把它们粘起来，先让系统具备基本的样子。

我过去一直比较擅长的一件事，就是看怎么把已有的开源组件整合成一个新的系统。这种能力在 Kubernetes 最早那个阶段特别关键。因为早期原型的价值，从来不是优雅，而是尽快让别人看到：这件事是成立的，是跑得起来的。

Q：你当时不是也有自己的正式工作吗？这种项目怎么腾出时间做？

Brendan Burns：我不会说自己把原来的工作完全扔了，但在那么短的时间尺度里，其实是可以挪出空间的。

我一直有一句有点“危险”的建议：我相信，大多数人都能从自己的工作里“藏出”大概 10% 的精力，而不被管理层真正察觉。

我的意思不是让人偷懒，而是说，在大多数组织里，你其实总能保留一点点自由度，去做一些没人明确让你做、但你自己觉得重要的事。很多真正有影响力的想法，都是从这种空间里长出来的。

当然，这背后也有一个前提：你得接受失败。

你去做这种 side project，很多时候不会成功。你可能投入了时间，最后什么都没发生；你也可能因为把精力押在一件不确定的事上，而少做了一些更容易被看见、被评价的工作。你得接受这种风险，接受“试五次，成一次，但那一次的回报可能远远大于前面四次”的逻辑。

有些人适合这样做，有些人不适合，这都很正常。

还有一个更直接、也更现实的事实是，很多人会说自己没有时间做这些额外项目，但他们一周里很可能还是会花十几个小时打游戏、刷 YouTube、看 Netflix。那最后其实不是有没有时间的问题，而是你愿不愿意为了自己真正相信的事，放弃什么。

我不是那种鼓吹天天熬夜工作的人，但如果你真的觉得某件事重要，那有时候就意味着，你会在一段时间里少看点视频，少做点别的娱乐。

Q：所以你的方法不是先写文档争取许可，而是先把东西做出来？

Brendan Burns：对，差不多就是这样。

很多事情很难靠文档解释清楚。你可以写一份策略说明，也可以做一套 PowerPoint，但真正有效的方式，往往还是先拿出一个能跑的东西。只要它开始运行，讨论的性质就会发生变化。

如果你什么都还没做，管理层面对的问题是：要不要把时间和资源押给这件事。但如果你已经把东西做出来了，哪怕还很粗糙，问题就会变成：这个东西值不值得继续推进、值不值得发布。

这两种讨论，完全不是一回事。

前者讨论的是资源分配，后者讨论的是这个想法本身是不是成立。对很多新项目来说，从前一种问题切换到后一种问题，本身就是一个决定性的进展。

当然，这里面依然有失败风险。你可能花了时间把东西做出来，最后大家并不买账。但如果你要做这种事，就得把这一点一起吞下去。你不能只接受成功的可能性，却不接受失败的代价。

Brendan Burns 的工程方法论，其实比 Kubernetes 本身更值钱

Q：从那个原型，到真正能让别人拿来试用，中间隔了多久？

Brendan Burns：大概半年。

从一个非常 hacky 的原型，到一个我们觉得别人真的可以拿去尝试的系统，中间还有大量基础工作要补。很多看起来不起眼的细节，最后都得一项项做扎实。

但那个阶段其实也很珍贵。因为你几乎是在一个“干净房间”里重做一套系统。很多后来加入的人，本来就在别的地方做过类似系统，脑子里早就积累了一堆“如果让我重来一次，我会怎么设计”的想法。

可现实世界里，很少有工程师真的能得到这种机会。

更多时候，你接手的是一个已经上线、有大量用户、有既有包袱的系统。你每天都在修 bug、兼容历史问题、给旧设计打补丁。真正从零开始、在历史债务相对少的情况下重建一套系统，是工程职业里非常稀缺的时刻。Kubernetes 早期恰好有这样一个窗口。

Q：今天很多工程师听这种故事，第一反应可能是：这毕竟是 Google，我在现实里哪有这样的空间？

Brendan Burns：组织环境当然会有差异，但这里面也有一个个人选择的问题。

很多人会把“没有空间”理解成一个绝对条件，可现实更像是：空间很小，风险很高，而且没有人会保证你做的事一定值得。你得自己判断，自己下注，自己承担不成的后果。

而且从职业发展上看，越往上走，这种能力反而越重要。因为在更高层级里，很少还有人会把一个足够让你完成跃迁的项目，包装好、定义好、直接交到你手上。更多时候，真正重要的项目，是你自己看到、自己提炼、自己把它推出来的。

从这个角度看，所谓 side project，不只是“业余爱好”，它其实也是在训练一种更主动的工程视角和职业能力。

K8s 也会死，只是死法可能和你想的不一样

Q：Kubernetes 今天已经成了事实标准，它会不会也有自己的上限？

Brendan Burns：当然会有，但关键在于你怎么理解这个“上限”。

Kubernetes 的很多组件，本质上都可以横向扩展。请求变多了，可以加 API Server；调度压力大了，可以加调度器。很多部分都可以通过 scale out 来解决。

真正更难的，还是底层存储层。因为在 Kubernetes 的架构里，大量状态最终都会回到那里，真正不那么容易无限扩展的，也往往是这一层。今天大家熟悉的是 etcd，如果未来规模继续往上推一个数量级，就得重新回答：它还能不能承受？还是说，需要一个保留相同核心特性、但扩展能力更强的方案来替代它？

我不认为 Kubernetes 在设计上存在一个天然写死的天花板，阻止它继续扩展。但系统一旦跨过一个数量级，问题就会迁移。原先最显眼的瓶颈，可能突然变得不再重要，新的瓶颈会在别的地方浮出来。你原先受制于 CPU，后来可能变成受制于网络；你原先受制于内存，后来可能变成受制于存储。每跨过一个数量级，真正的问题都会移动。

Q：你说过一句话，软件的宿命是死亡。那 Kubernetes 也会死吗？

Brendan Burns：我完全认同这句话。

不过更完整的说法其实是：你最好别爱上自己的软件，因为软件不可避免的轨迹就是死亡。真正想表达的是，不要因为“这是我写的”就舍不得放手。当它该被替代的时候，你就应该愿意把它扔掉。

从行业历史来看，这几乎是普遍规律。哪怕在 Kubernetes 内部，我当年写的很多代码，后来也已经被重写很多次了。

至于 Kubernetes 会怎么“死”，未必一定是突然被另一个新系统彻底替代。有时候，一个系统并不会真的消失，而是会变得越来越底层、越来越隐形。就像今天 Linux 还在，但大多数人不会天天讨论 Linux；处理器架构也还在，但不是所有开发者都时刻盯着它。

Kubernetes 也可能走向这种状态：它还在，只是被更上层的系统盖住了，被新的交互方式包起来了，最后人们越来越少直接感知它。

尤其在 AI 时代，很多注意力已经转向模型、推理框架和应用接口，Kubernetes 可能慢慢退到底层，成为那个默认存在、但不再是主角的能力。

当然，如果把时间拉到足够长，比如一百年后，我会非常惊讶 Kubernetes 还能原封不动地存在。技术世界变化太快了，很多今天看起来坚固的东西，几年后就可能开始松动。未来最大的问题，从来不是你没预测到变化，而是变化来得比你想象更快，或者根本不是你以为的那个方向。

关键是“记好笔记”

Q：你怎么看读 PhD 这件事？很多人会纠结到底值不值。

Brendan Burns：这是别人最常问我的问题之一。

如果只从职业回报率来看，我可以讲一个很现实的故事。我后来在同一家公司里遇到过一个本科同学。我们同年毕业，他去创业、进工业界，我去读了 PhD，后来又回到工业界。结果我们最后在公司的层级是一样的。

所以如果你问我，读 PhD 会不会让你在职业发展上显著领先，我的答案大概是：未必。很多时候，其实差别没那么大。

但如果反过来问，这段经历值不值，我又会说：对我来说值，因为我玩得很开心，而且学到了很多非常有用的能力。

比如写作和表达。博士训练和导师对我的影响，让我学会了怎么把一个复杂想法写清楚、讲清楚。后来 Kubernetes 早期那段时间，我们花了很久去推动、去说服、去争取内部支持，这种能力其实非常重要。

另外，我后来还做过几年教授。给完全不懂计算机的人上课，会逼着你去思考：你到底该怎么把一个复杂系统讲到别人能懂。Kubernetes 早期也一样，很多人会问：什么是容器？什么是 orchestration？我为什么需要它？这些问题都不是你把代码写出来就自动解决了的，你必须会教，必须会解释。

所以如果你问我，我会说：PhD 不一定让你在头衔上更快领先，但它可能会给你一些长期非常有价值的能力。

Q：年轻工程师最常问你的另一个问题是什么？

Brendan Burns：另一个很常见的问题是：我到底该学什么？

比如现在 AI 很热，但有些人自己更喜欢系统，就会来问我：那我是不是应该放弃系统去学 AI？我的回答通常是，我没那么在乎你学的具体是什么，我更在乎你是不是在持续学习。

如果你对 AI 根本没热情，只因为它热门就硬学，那你多半也学不好。反过来，如果你真的喜欢系统，你会投入更多时间和注意力进去，而这种持续投入更有可能转化成真正的能力。行业也永远不会不需要优秀的系统工程师。

我能感受到，很多年轻人特别害怕“选错方向”。但说实话，我自己从来没有一条严密的人生规划。我一直都是看什么东西有意思、有价值，就去追。

当然，这种方式也可能有风险，但我也想提醒大家：很多你事后觉得是在绕路的经历，最后恰恰可能变成最重要的养分。只要你一直在学，通常就不会太差。

Q：有没有哪本书，对你的职业影响特别大？

Brendan Burns：如果是在工程师阶段，对我影响很大的一本书是《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是大家熟悉的 GoF《设计模式》。

后来随着角色变化，开始带更大的团队，我会更推荐另外两本：一本是《Leadership on the Line》，另一本是《The Five Dysfunctions of a Team》。

前者更偏领导力，后者更偏团队协作。大致可以这么理解：如果你现在主要还是工程师，先读《设计模式》；如果你已经开始做管理或者组织领导，后两本会更有帮助。

Q：如果回到刚大学毕业的时候，你会给当时的自己什么建议？

Brendan Burns：记更好的笔记。

我一直觉得，Kubernetes 这一路的经历，其实完全值得写成一本书，甚至能写出一篇很好的商业案例。但问题是，我当年没有留下足够完整的记录。

代码当然还在，但真正容易消失的，往往不是代码，而是那些关键时刻的讨论、伙伴之间的拉扯、组织内部的推动、人与人之间的判断和博弈。这些我现在还记得一部分，但已经记不全了。

如果当年能留下更完整的笔记，今天回头看，一定会很有价值。

原视频链接：youtu.be/FKijpCEH9D8

（投稿或寻求报道：zhanghy@csdn.net）

"48 小时，与 50+ 位大厂技术决策者，共探 AI 落地真路径"

由 CSDN&奇点智能研究院联合举办的「全球机器学习技术大会」正式升级为「奇点智能技术大会」。

2026 奇点智能技术大会将于 4 月 17-18 日在上海环球港凯悦酒店正式召开，大会聚焦大模型技术演进、智能体系统工程、OpenClaw 生态实践及 AI 行业落地等十二大专题板块，特邀来自BAT、京东、微软、小红书、美团等头部企业的 50+ 位技术决策者分享实战案例。旨在帮助技术管理者与一线 AI 落地人员规避选型风险、降低试错成本、获取可复用的工程方法论，真正实现 AI 技术的规模化落地与商业价值转化。

这不仅是一场技术的盛宴，更是决策者把握 2026 AI 拐点的战略机会。