100年后K8s还会存在吗？AI科技大本营

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

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 早期恰好有这样一个窗口。