Kubernetes会被AI取代吗？创始人断言：软件终有一死！Linux也如此……

如果今天有人站出来说，Kubernetes在100年后将不复存在，很多人会觉得这是危言耸听。但说这句话的恰恰是亲手把它构建出来的那个人：Brendan Burns，Kubernetes的联合创始人之一。

十年前，他和Craig McLuckie、Joe Beda在谷歌用一个不到一周写出的粗糙原型，撬动了整个云计算行业的格局。如今他是微软Azure的副总裁，亲眼见证Kubernetes从一个小项目成长为云原生时代最成功的开源项目之一。但在近期一次访谈中，Burns却对这个项目给出了一个近乎冷酷的判断：软件终有一死，Kubernetes也不会例外。

本次对话探讨了Brendan在谷歌开发Kubernetes的经历和具体技术细节、如何获得领导层支持以及他在此过程中学到的经验。

以下为这场访谈的中文编译。

Q：假设我是你的主管或者类似角色，你带着这个方案来找我，你是如何说服我的？

Brendan：项目初期，最难的部分其实就是把这个想法表达清楚。我们用了好几种不同的方式来阐述它为什么重要。其中之一是跟MapReduce那篇论文有关。因为当时MapReduce，尤其是Hadoop和大数据正是大家关注的热点。MapReduce这样的技术曾经非常重要，它引发了大数据革命。谷歌写了最初的论文，但Hadoop是一个开源项目，谷歌跟它毫无关系，也得不到任何功劳。所以，部分论点是这样的：我们有自己的云平台，并希望影响技术格局。如果我们只是往外发论文，但那些东西跑不起来，或者说别人没法真正运行它，那我们就没有话语权。

第二点是为什么人们要使用虚拟机或容器？很多讨论都围绕着软件编写的需求展开。内部的经验告诉我们，编写可靠的软件需要一些类似应用程序“自动驾驶仪”的系统。随着软件对越来越多企业变得至关重要，这个需求是绕不开的。

第三点是为什么要开源。在某种层面上，这可能是最有趣的讨论。因为大家会说：“你成功说服我了，我们应该构建它，应该把它开放给全世界，人们会觉得它有用。”但紧接着就会问：“但是，如果它只能在我们的平台上使用，不是更好吗？”这时候我们会回答：“是的，那当然更好，但如果你只在自己的平台上开放，你赢不了。”

Q：为什么这么说？

Brendan：因为市场还有其它平台，如果你搞独占，那些出于各种原因使用其它云或本地部署的人就被拒之门外，他们就会自己去造一个替代品。这有点像Linux，Linux成功是因为Linux可以部署在任何地方。开放技术和开放生态系统最终获胜的根本原因在于大多数用户都不会使用你的独占平台。

如果你不是领导者，那么大多数人都不会用你的平台。如果你让大多数人用不上你的东西，他们就会直接忽略你，然后自己去造一个。但如果你开发一个面向所有人的产品，同时确保它在你的平台上体验最好，那你就有机会能把更多人吸引到你的平台上来。

而且，在某种程度上，这也跟当时的技术氛围有关。如果大家都用Linux、Docker、开源的编程语言，那你肯定不想成为那个格格不入的人。历史上只有极少数情况，你能在闭源的同时还能成功，那必须要有极大的差异化。我不认为我们有那么大的差异化。

Q：当时竞争格局是怎样的？谷歌之所以选择以开源方式发布Kubernetes，是为了让更多开发者能够接触和使用它，从而逐步从AWS手中争夺市场份额吗？这样一来，这些开发者后续就更有可能迁移到GCP，或者至少愿意将其纳入考量。

Brendan：他们至少会注意到你，而且你也改变了对话的格局。追着别人的尾灯跑是很难的。如果别人已经建好了虚拟机，所有人都在用虚拟机，而你能说的只是“我们也在做跟他们一样的东西，只不过可能稍微好一点点”之类的，其实这并不是什么好的市场策略。

但如果你开创一个全新的赛道，成为思想领袖，人们就会开始倾听你的声音。即使他们没有使用你的平台，他们也会关注你，会让你在市场中拥有更大的话语权。它改变了叙事方式和人们关注的倾听对象。因此，我认为，掌控话语权是突破或尝试打破这种被动格局的关键所在。

当然，现在GCP还是第三名，所以这个策略并没有完全逆转局面。但我也不会说它没有效果，整体上它是成功的，只是市场惯性太难打破了。而且后来所有云厂商都围绕它形成了合力，现在Kubernetes已经成了一种通用的基础设施。

Q：当时你们在往前看、跟领导层沟通的时候，你们自己是否清醒地意识到这些好处？

Brendan：我们绝对希望确保自己在思想领导力上站在最前沿，也明确表述过这一点。处在思想领导者的位置是有价值的。

Q： 很有意思，因为我觉得这很难量化。如果我在那场会议上要做决策，这个价值到底值多少钱？

Brendan：当时做这件事的成本其实很低，大概只有八九个工程师，我们差不多就这些人。从某种意义上说，这既是好事也是坏事。比如，我们之所以坚持要打造一个如此独特的品牌，将Kubernetes这个品牌与谷歌品牌分开，部分原因就在于这给了我们一定的试错空间。

当时的想法是，如果这八个人搞出点什么事，结果发现不靠谱，我们直接把它关掉就行了，这样不会损害大家对整个云业务的整体印象。所以我觉得开源也有好处，它有助于推广。特别是后来当我们跟Linux基金会等组织合作，真正建立了一个独立的实体之后，它让Red Hat、Azure或者AWS这些厂商敢于押注Kubernetes，并且对这笔押注有信心。

同时，它也是一份“失败保险”。同时它还简化了很多事情，因为我们当时还要跟初创公司竞争。Docker就是一家初创公司，他们比大公司灵活得多。而我们把Kubernetes作为一个独立实体来运作，也让我们变得灵活一些。

Q：这个项目的最初构想是不是你和另外两个人一起头脑风暴的？

Brendan：那几乎就是个demo。就是那种“你看，我们把一堆现有的开源技术拼在一起，就能做到这样”的感觉。

Q：这个demo具体能做什么？

Brendan：基本上就是一个基础的容器控制。那时候你还得先跟人解释Docker是什么，我用Docker构建了这么一个容器镜像，接着你可以运行它、部署它，能看到它被分发到了多台机器上，而且能对它做负载均衡。因为你访问一个统一的入口，它会返回“我是副本一”；然后你刷新一下，它会说“我是副本三”。所以它展示了副本能力。还有基本的健康检查，如果你把容器杀掉，它会自动恢复。再就是V1到V2的版本升级，大概就这些。

Q：最初的MVP版本开发花了多长时间？

Brendan：我花了不到一周的时间写完，大概五天。

Q：你是不是把手头上的所有工作都停掉了？

Brendan：倒也不能说完全停掉，但就那一周的时间尺度来说，你可以在那些工作上稍微松懈一点。总有足够的弹性时间让你能抽出空来拼出这么个东西。而且那代码真的是拼凑出来的，能走的捷径全走了，能偷的懒全偷了。我觉得我比较擅长的一件事，就是把其他开源项目集成到一起，看看怎么把现成的东西拿来组合起来。所以很多具体的零件其实都是从别的开源项目里拿来的，用一些胶水代码把它们粘在一起，给人一种像模像样的感觉。

Q：我觉得很多软件工程师听到这类故事时，都会想：“我还有自己的工作要做，就算我觉得这是个好主意，我也不一定能抽出时间来做这件事。”你对有这种想法的人有什么建议吗？

Brendan：我对此有两个答案。第一点，我相信你可以向管理层隐瞒大约10%的工作成果。你总会有余地，有可以偷懒的空间。而且随着组织规模越来越大，实际上你能用这10%做的事情比例反而会增加。我很多真正有影响力的好想法都是从这里冒出来的。

这其实也是一种比较随意的说法，本质上是说：我想给一线员工赋权，让他们能做自己认为对业务最有利的局部决策，而不需要层层请示、不需要事事征求许可。但当你这样告诉别人的时候，你其实也在说：顺便提一句，你们也会做出不少糟糕的决定，也会浪费不少时间。所以你必须接受这样一个心态：我要去试一些想法，有些会失败，有些会成功。回头来看，那些失败实际上就是浪费时间。而这可能就是你绩效评定里“超出预期”和“达到预期”之间的差别。你肯定不想掉到“低于预期”，但这可能正是“超出预期”和“达到预期”的区别所在。

你必须接受这样一个事实：你要下注五次，其中一次中奖的回报将远远超过每次都靠苦干硬磨去拿“超出预期”所付出的努力。而且我认为，不这么做也情有可原。因为你必须是那种愿意承担这种风险的人，但并非每个人都适合这样做，这也没关系。

另一方面，有时候人们会跟我说类似的话，我就会问他们：那你玩《使命召唤》吗？你看Netflix吗？你看YouTube吗？因为我敢肯定你每周至少有10、15、20个小时在做工作以外的事情。而我可以告诉你，在那个时间段里，除了工作、这个项目、陪陪家人和睡觉，我什么都没干。所以有时候问题也在于：你愿意放弃什么来换取做这件事的时间？我不是那种会通宵工作的人，但这确实意味着：可能有一段时间不看YouTube，可能有一段时间不看体育比赛。

Q： 这很有道理。而且就第二点来说，这个项目的回报是指数级的，高得离谱。你一年投入两倍的时间，就能获得20倍的影响力。所以从时间投入的角度来看，完全说得通。

Brendan：我个人觉得它很上瘾。我觉得我从两方面受益。

第一，我真的很喜欢写代码，写代码对我来说是一种享受。所以如果在看Netflix和写代码之间选，我其实挺乐意写代码的。这对我来说是个优势。

第二，至少对我而言，一旦有人开始用这个项目，他们为此兴奋，他们在GitHub上提issue什么的，我就彻底沉迷了。我就想赶紧把这个issue关掉，想帮那个人解决问题，我会一直干到在笔记本电脑前睡着为止。纯粹就是因为享受这件事，这也是我为什么干这一行。所以即使在当时，我绝对没有想过“哦，这会是我职业生涯余下时间的回报”，我当时的状态绝对是“哇，我只想让这件事继续做下去”。我想保持这种状态和这种激情。

Q：听起来你们花了很长时间才获得领导层的支持？

Brendan：我们花了整整六个月的时间，从一个非常粗糙的原型发展成一个我们真正认为有人可以拿去用的东西，并为此打下了坚实的基础。在这个过程中有很多小细节需要处理好。幸运的是，早期加入我们的很多人之前都开发过类似的系统。所以他们获得了这样的机会：一个完全不受干扰的环境。

作为一名工程师，你的职业生涯中很少有机会能像这样在一个完全不受干扰的环境中重新构建一些东西，并思考如何才能做得更好。所以我认为这对大家来说也很有吸引力。我们没有任何用户，所以不必为了某个付很多钱的大客户去修复bug之类的。在这样的环境当中，我们都花了很多时间思考这套系统应该是什么样子，可以去把想象中的东西搭建起来。

Q：向管理层隐藏大约10%的工作成果，在实践中是怎么操作的？

Brendan：你应该有一个你认为相关的“副业项目”，没人让你做，但你觉得它很重要，你要在上面花功夫。我说的“隐藏”真的是指隐藏，就是别征求同意。迟早你会展示给他们看，但你需要相当长一段时间，可能几个月才能把它做到能拿出手的程度。所以关键就是：不打算征求同意，我要去做我认为重要且有用的东西。

到正式发布或公开的时候，你确实需要征求同意。到那个时候你就可以说：“我已经把这个东西做出来了。”你已经有时间把它从零做到可展示的状态了。我觉得用文档或者PPT之类的东西很难把这类事情的价值讲清楚，如果是一个能跑起来的、别人能上手互动的东西，效果要好得多。所以你要花时间把它做成一个真实的、可以发布的东西。

而且从某种意义上说，你的经理总是在评估：你应该把时间花在这件事上，还是那件事上？而你把东西做出来之后，实际上就迫使对方做出了决定。因为问题不再是“你应该花时间做这个，还是花时间做那个？”，而是“我已经把这个做出来了，你想不想发布它？”从某种程度上来说，这的确是一个更容易的决定。它不再是一个二选一的问题，变成了：你的想法好不好？因为工作已经完成了。

Q：如果出现另一种情况，比如你做了这个东西，没告诉任何人，发布之后根本没人关心，或者它没有达到预期效果该怎么办？

Brendan：这就是事情的另一面，你必须学会接受。你会浪费一些时间的事实。这种浪费可能是：我本来可以看Netflix什么的，结果写了一大堆没人喜欢的代码。也可能是另一种浪费：我本来可以做足够多的工作去晋升职位，但我觉得这个绝妙的想法能帮我突破瓶颈，结果并没有。我觉得你就得接受这一点。这本质上就是在冒险——在某种程度上跟创业差不多。你在冒险，你不能想当然。我觉得有时候人们做这类事情时的心态是：“我会有一个好点子，它会很了不起，然后它会呈指数级增长。”我觉得如果你抱着这种心态去做，很可能一开始就会感到失望。你应该抱着这样的心态：我觉得这不错，我愿意一试。但如果了失败也能接受，因为这是我自己的选择。

Q：这个项目也让你在Google得到了晋升，对吧？

Brendan：我的职业生涯确实从那次成功中获益良多。在某个阶段，大家对你的期望就是你得是那个懂足够多、能提出真正好想法的人，已经不只是你能不能执行别人给你的想法了。还有一点，我有时会跟考虑晋升的人说：如果你完全是自己想出的这个点子，那功劳显而易见就是你的。如果你是在一个更大的项目或者别人的想法里取得成功并产生影响，你仍然可以有非常成功的职业生涯，但功劳比较难直接归到你头上。

但话说回来，这在某种程度上仍是一场赌博。可能有些人一次又一次地尝试，却始终没有找到对的想法。我觉得颠覆式创新有意思的地方之一在于，它既需要你是有想法的人，也需要你恰好处在那个想法能够成事的时代。所以你可能有这个想法，但如果时机不对，它就不会产生同样的效果，也不会朝着同样的方向发展。

Q：关于商业战略，在离开Kubernetes这个话题之前，我想问一点：在当时，我觉得Borg就是Google的竞争优势，就像某种秘密的基础设施配方。我本以为大家会担心把任何一点这样的东西透露给业界。所以当时是怎么考虑的？你们是怎么说服大家说“没关系”的？

Brendan：确实有那一层顾虑，但我也跟别人半开玩笑地说过：你又不是黑衣人，人一离开谷歌你就给他闪一下记忆消除；也不是每个人来了谷歌之后，就永远待在这里不走了。事实上，当我们跟Facebook、Twitter的人聊，跟其他大型科技公司的人聊的时候，他们都在搭建类似的东西。这其实不算什么秘密。而且当时Mesos也在做类似的事情，虽然不完全一样，但很接近。你能看出来迟早会有一个开源的解决方案出来。所以在某种程度上，争论的要点就是：肯定会有一个开源方案，你是希望这个方案是我们的，还是别人的？这只是在重新定义选择而已。问题不是你希不希望有开源方案，而是它必然会出现。要让人们清楚地意识到这就是选择：你没有“专有方案”这个选项，因为那根本行不通。

Q：在构建编排系统最初的MVP时，没有任何客户可参考，你们是如何确定在发布之前所需的最小功能集的？

Brendan：我们受益于团队协作。当时只有三个人参与：Craig擅长产品和业务，Joe擅长API设计，而我写代码很快，能快速编写出原型。我们当时大量反思了自己过去的经验，也亲眼见过人们在传统虚拟机基础设施上部署时有多痛苦，所以我们对大家正在经历的痛点有切身的认知。而且当时Netflix那帮人也在讲不可变基础设施之类的东西，他们在推进一些类似的概念。所以其实有一个更大的行业思潮在发生，我们只是参与了其中。从某种意义上说，客户是存在的，只是他们还不是我们的客户而已。我其实不觉得Kubernetes是凭空冒出来的，它更像是把当时行业内已经在流传的很多想法汇聚到了一起。它只是成了一个锚点，一个把这些想法表达得特别好的载体。

Q：最初的MVP里大部分代码是你写的吗？

Brendan：大概占了80%以上，我觉得我仍然是第一。即使后来我已经很少残参与Kubernetes的开发，但我仍然是GitHub提交总数贡献榜上的第五名，早期更是长期位列第一。

Q：给Kubernetes编写了这么多代码，系统中哪个部分构建起来最难？

Brendan：其实没有任何一块具体的代码是特别难的。真正的难点在于我们早期做出的决定：要构建一个高度松耦合的系统。在这个架构下，很多独立的组件各自执行操作，到处都是控制循环在运行，这对系统的韧性非常有利。但代价是，一旦出了故障，就很难追踪根因。因为可能需要十五个不同的进程协同工作才能达成某个结果，你只看到结果没达成，但中间到底发生了什么，就得翻一大堆日志、一大堆可执行文件的运行记录，在时间轴上一点一点重建整个过程。尤其是在早期，我们的日志质量不高，事件记录的一致性也很差。所以我觉得，这其实是所有这类分布式系统共同面临的难题。

此外，各个节点的时间并不同步，而且你必须在日志里记录正确的内容，早期我们经常漏记。再加上这类问题往往是由多个组件交互产生的，很难复现。通常来说，如果问题能稳定复现，即使没有日志也容易修，因为你只需加上日志再跑一次就能看到现象。但对于那些偶发的临时性问题，比如两三个事件之间的竞态条件，即便你加了日志，也不一定能轻易让它重现，这非常棘手。

另外还有一点：我们当时都在边学边写Go语言，Golang里有很多坑，我们都是在实战中不断踩坑才慢慢掌握的。

Q：如果领导者宕机了，领导者选举应该是一个非常棘手的问题吧？

Brendan：这件事之所以没有造成太大困扰，是因为我们几乎完全依赖Etcd来帮我们处理这部分逻辑。

Q：Etcd是另一个开源组件吗？

Brendan：Etcd现在基本上已经是Kubernetes的一部分了。但当时它是一个基于Raft共识算法的键值存储系统，是CoreOS写的一个已有软件，实现了Raft协议。因为当时Paxos是最早的共识算法，但Paxos真的很难实现，因为它的算法太复杂了，没人搞得懂。刚好在那段时间，有人提出了Raft，同样是可证明正确的共识算法，但实现起来简单得多。Etcd实现了 Raft 协议，然后给你一个可靠的共识存储，你可以跑多个副本，由它来做共识。 它不直接做领导者选举，但它提供了足够的基础原语，让领导者选举变得相对简单。

关于这点我还有补充：我们决定所有访问都必须通过API Server。没有人能直接访问存储。这个其实是我最初使劲推动的，但大家也基本同意。任何人都不能直接写磁盘，系统的每一部分都必须通过API Server，再通过API Server背后的Etcd来做任何持久化操作。

Q：这样做的好处是什么？

Brendan：所有组件随时都可以重启，起来就能正常工作。你不用担心中间状态损坏，不用担心schema变更，不用管那些乱七八糟的东西。所有组件实际上都是无状态的，除了数据库本身。也就是说，只有Etcd那个共识数据库是有状态的。因此，整个系统稳定起来就简单得多。缺点就是它导致了那种松耦合，一堆独立的控制循环通过存储层来协调一切，这让调试变得更难了。

这就是权衡取舍。如果你有一个完整的日志，记录了你的当前状态，并且把它想象成一个状态机，那么在状态机中就更容易理解你当前的位置以及你经历了什么。但状态机的可靠性很难保证。它们易于调试，但难以稳定运行。而我们构建的系统虽然设计稳定，但调试难度很高。状态机的问题在于，它描述的是世界原本的样子，但除非你设定得非常精确，否则世界有时会呈现出你意想不到的样子。这时你就束手无策了，因为你的状态机不知道该怎么办。 

而我们因为有了这些基于"期望状态"和"当前状态"的控制循环，不断驱动当前状态向期望状态靠拢。不管你从什么状态醒来，你都知道自己应该朝哪儿走。这就是它稳定的那部分。就是无论系统把自己搞成了什么状态，它永远在努力朝期望状态靠拢。这很大程度上受到机器人学的控制理论启发。

Q：我在读Kubernetes的一些设计文档时看到过，它的一个特点是声明式而不是命令式，这个设计决策的利弊有哪些？

Brendan：这其实是当时行业内正在发生的一个大趋势，也是整个"基础设施即代码"运动的一部分。我们不是唯一主张这个理念的人，但我们确实把它贯彻到底了。好处在于：你能够清晰地表达你希望系统达到什么样的状态。如果你没有写下来，那你只是在执行一系列步骤，却没有记录最终目标。

而声明式的方法则不同，你明确地写下了期望状态，系统就知道该往哪个方向努力。这也让系统具备了自愈能力，因为目标状态被记录下来了，一旦系统发生偏离，比如某个组件挂了或重启了，我们就能知道该恢复到什么状态。它还有个附带好处：一旦你用声明的方式定义好状态，就可以对它进行代码审查、编写单元测试。很多软件开发的方法论都能应用到这份声明上。

缺点可能就是引入了一定的复杂性。相比在GUI 里点点点地操作，你需要学习YAML，觉得这很难。不过我觉得，现在情况已经好很多了，已经有足够多的学习资料可供参考，而且还有生成式AI辅助，学习曲线其实没有最初那么陡了。相比大家之前习惯的操作方式，这可能是最大的缺点。但总的来看，坏处其实并不多。

Q：在Kubernetes扩展阶段，你们是如何获得其他公司支持的呢？OpenShift是Red Hat很重要的产品，还有其他公司也加入了。你们是怎么说服那些公司，让他们觉得Kubernetes是他们想要用的东西？

Brendan：我觉得对很多早期伙伴来说，核心就是那个"无差别的重活"的概念。他们有自己的目标：OpenShift在做平台即服务，很多早期用户同时也是贡献者，他们在尝试构建某种可靠的Web服务之类的东西。所以我们的逻辑就是：反正你们迟早也要自己搞这套东西，那为什么不大家一起搞呢？我们其实不太在乎这个。因为我们不认为我们的价值绑定在这一层，所以愿意来给你们的项目做贡献。因为我们从集体协作中能获得的价值，比自己单干要大得多。所以对很多早期伙伴来说，论点的核心就是：我们让你加入进来。

而其中一部分工作就是让他们明白，他们是平等的合作伙伴，而不是依赖别人的路线图。所以我们还得明确告诉他们：你可以依赖我们，同时我们也会让你参与设计决策。当需要新功能的时候，你们可以自己贡献。我们想达成的目标跟你们的路线图是匹配的，诸如此类。随着时间的推移，因为生态系统在不断发展，越来越多的人开始有兴趣参与进来。比如你看网络提供商或存储提供商，当他们的用户开始成为Kubernetes用户时，他们就有动力确保自己的网络系统或存储系统能跟Kubernetes很好地配合。

Q：考虑到Kubernetes起源于Google、主要由Google资助，你们怎么确保Google不会控制Kubernetes的发展方向？

Brendan：我觉得有两件事。一是把它交给基金会。我们只做了一年就把Kubernetes全部捐赠给了云原生计算基金会，成立了CNCF。所以把项目、logo、所有法律事务、商标等等全部交给一个独立的软件基金会，跟Linux基金会合作是至关重要的。因为如果别人手里握着Kubernetes logo的商标之类的，合作伙伴就很难跟你合作。二是把治理规则写下来。Kubernetes有好几年没有任何成文的治理规则。其实我们应该更早做这件事的，但我们没有。2016年，我们写了治理规则。所有人都有一个共识：我们不希望任何一家公司能够控制整个社区。

从Craig、Joe和我的角度来看，我们从来没想过要做那种终身独裁垄断的项目，而是分布式所有权、民主式的项目。我们把很多这样的理念都写进了治理文档里，一直沿用至今。所以我觉得这两件事加在一起，确保了它是一个行业标准，而不是某一家公司的标准。而且我也觉得这对它的成功至关重要，两者是相辅相成的，缺一不可。

Q：Kubernetes作为一个开源项目，社区贡献代码的比例大概是多少？主要利益相关方公司投入的又占多少？

Brendan：我没有具体的数据，但根据我在开源领域的经验，大概80%到90%来自核心贡献者，不到10%来自其他人。让大家参与贡献确实很难。部分原因在公司层面。像微软这样的公司，领导层已经承诺为开源做贡献，也愿意组建专门团队做上游开源项目的工作。但对很多Kubernetes用户来说，比如零售商或银行业，技术不是他们的核心业务，只是交付应用的手段。在这种情况下，很难证明"拿10%的人力去做上游开源贡献"是合理的。尤其是领导层非技术背景出身，他们不是在那些社区里成长起来的。如果你来自金融行业，"贡献回去的价值"就很难解释。"用开源"的价值很明确，因为是免费的，但"贡献回去"的价值就模糊得多。

还有法律层面的顾虑。即使在今天，情况已有所好转，但我仍遇到过有人说：我们很想贡献，工程领导层也同意，但法务团队担心，如果我们贡献了代码、引入了bug，可能会被追责。如果你写了一款专有软件并卖给他人，里面的bug导致对方房子烧了，对方确实可能起诉你。但开源场景下，很多许可证都包含了免责条款，核心就是：使用者自行承担风险，不能因使用开源软件造成损失而追责贡献者。不过这种担忧确实存在，我确实听人说过公司有此类顾虑。他们会衡量：看到了风险，却没看到相应的价值。而且，如果技术不是核心业务，如果你不是科技公司，那个开发者真的有能力去跟法务部门争论什么能做、什么不能做吗？恐怕很难。很可能就这样放弃了。

Q：现在AI领域出现了新的工作负载。训练类任务是大规模、集中式的计算负载；而推理类任务则对延迟敏感，需要近乎实时的响应。Kubernetes这些年来是如何调整演进，以应对这类工作负载的？

Brendan：早期我们连100个节点都很难支撑。核心系统经过了大量优化，API的调用频率一度很高，我们不得不降低噪声，或者把某些组件拆分出来，以实现扩展。ETCD尤其容易成为大规模集群的瓶颈。掌握如何高效运行ETCD，是掌握Kubernetes大规模运维的核心。这跟学习如何把数据库跑大没有本质区别。大规模运行就是会出各种奇怪的问题，只能不断尝试、发现问题、修复、再重复。

有趣的是，虽然AI训练确实需要大规模集群，但很多云上用户实际上拥有的是大量小型集群，而不是一个超大集群。有成百上千个集群，每个集群规模相对较小。这是我们最初没有预料到的，因为我们过去在物理数据中心时代，只会部署一个集群，因为搭一次很麻烦。但在云上，比如AKS，点一下按钮两分钟就能创建一个集群，太容易了，所以人们会创建大量集群。

因此Kubernetes社区和Azure都在投入大量精力来管理集群规模：如何管理成百上千个集群。以前我们常说容器替代了"雪花服务器"，现在我们又有了"雪花集群"。虚拟机都一样，但每个集群的配置都千奇百怪。所以我们得给用户提供工具，确保所有集群的监控软件、Kubernetes版本、管理员用户等保持一致。这是大规模扩展的另一个维度：集群数量，而不仅仅是集群大小，也是我们当初没有预料到、后来不得不去解决的问题。

Q：Kubernetes有没有一个上限，到了某个节点就完全撑不住了？比如规模再扩大10倍，会不会在某个点上彻底崩溃，必须用更定制化的方案？

Brendan：关键还是回到存储层。因为那个设计决策，所有操作都要经过存储层。其他组件基本都可以水平扩展：API请求多了，就加API Server；调度慢了，就加调度器。几乎一切都可以水平扩展。瓶颈在于存储层，所有的工作都落在这里。所以如果想把规模扩大10倍，就得考虑ETCD能不能撑住，或者是否需要换成具备同样特性但能支持更大规模的其他存储方案。我不认为设计上有根本性的限制。但有一句名言：每次规模提升一个数量级，问题就会转移到别的地方。当你以为的问题是网络，解决了之后CPU成了瓶颈；解决了CPU，内存又成了瓶颈；解决了内存，网络又成了瓶颈。

Q：你提到过你有机器人学的博士学位。我听到很多人说不推荐读博，也有人推荐。想听听你对读博的看法。

Brendan：这大概是我被问到最多的前五或前十的问题之一。我用两个故事来回答。

第一个故事：我职业生涯中遇到过一个人，我跟他上同一所本科，他毕业后去做了创业，一直在科技行业，后来到了我所在的公司；而我读了博士之后才回到业界。最后我们在同一家公司，职位级别完全一样，本科毕业年份也一样。所以从这个角度说，读不读博可能差别不大。

但从另一个角度看，我觉得读博很有趣。做机器人学博士的过程让我很快乐，这本身就值了。而且我从博士导师那里学到了很多关于写作和演讲的技巧，如何把自己的想法清晰地表达出来，这些是在业界未必能学到的。这些能力让我在论证和表达上受益匪浅。比如我们之前谈到的那六个月，为"为什么要开源"这件事争取支持，我学到的表达和写作技能在那段时间发挥了很大作用，至今仍在受益。

另外，我曾当过几年教授，教CS101，需要把计算机知识解释给完全不懂的学生听。这段经历帮我组织Kubernetes项目的初期文档和教学材料，让新人能学会Kubernetes。因为当时很多人进来问"什么是容器？""什么是编排？怎么操作？"有很多教学工作需要做。当教授时思考"怎么教学生"的经验，让我在向别人传授Kubernetes时做得更好。

所以两个方面：一方面读博本身在职业发展上未必有决定性影响；另一方面我确实学到了很多对职业生涯有用的技能，而且过程很快乐。

Q：你说是被问到最多的问题之一，我好奇排名第一的是什么？

Brendan：另一个常被问到的是："我怎么知道该学什么？"尤其当我跟实习生或刚入职一两年的新人交流时，很多人会问：AI现在很火，但我觉得系统方向更有意思，我该去学AI还是学系统？我的回答是：你学什么其实不重要，重要的是你在学。最关键是找到让你兴奋、有热情的东西，因为只有这样才能让你愿意投入时间，而不是去看YouTube。如果你对AI不感兴趣，你大概率也学不好，只是在浪费时间；如果你真的对系统有热情，你会投入大量精力和心血去钻研。系统工程师的需求依然存在。

我觉得很多人害怕做出错误的选择。我总告诉大家：我从来没给自己的职业做过规划，从来没有。我一直只是去追逐那些我觉得有用、有趣、有意思的东西。当然这不一定适合所有人，有规划可能是好事。但我希望人们明白，回头看时，有些你以为是错误或死胡同的东西，反而恰恰是教会你关键东西的经历。所以只要你一直在学习，你大概率不会走错。

Q：我无法想象Kubernetes会消失。你觉得它会以什么方式消亡？如果真到了那一天，你怎么看？

Brendan：我仍然坚持这个观点。不过那句话前面还有一句："你永远不应该爱上你的软件，因为死亡是软件不可避免的命运。"意思是，当它走向衰亡时，不要死守着不放。永远要愿意舍弃，不能因为是你写的就死守到底。从行业历史来看，这确实是事实。即使在Kubernetes内部，我当年写的源代码在这十多年的历程中已经被重写了无数次。消亡会是什么样子？我觉得会有一个新东西出现，实现类似的目标，但更简单、复杂度更低、实用性更强。

有两种死亡轨迹：一种是彻底消失，另一种是变得太底层、太隐藏，以至于没人注意到它。就像Kubernetes底下是Linux，Linux底下是处理器，但人们不会去关注那些。现在大家都在关注AI，而很多AI跑的底层是Linux。但人们可能把注意力全放在AI上，忘记了Kubernetes那层。我觉得这已经在发生了。从变更提交量之类的指标来看，Kubernetes的活跃度已经趋于平稳，除了AI相关的支持需求算是个例外。放长远来看，一百年后Kubernetes还会在运行吗？我觉得不太可能。

我们拥有计算机系统的时间还不够长，也许没法确定。有些老东西我们还在用，比如电源插头形状大体上没变。但像x86这样的东西，如果六年前你问我"x86处理器会消失吗"，我会说可能。移动端已经没了，但服务器端也许不会。但现在发生了两件事：一是大量计算转移到了GPU上；二是ARM64因为能耗等原因在服务器端成了重要平台。所以预测未来很危险，因为未来要么比你预想的来得更快，要么比你预想的来得更慢。

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

Brendan：应该多做些笔记。我觉得整个Kubernetes的经历，从开始到现在，完全可以写出一篇精彩的MBA论文，甚至是一本好书。但我没有足够详细的笔记来支撑这件事。我们经历了很多，各种各样的事情层出不穷，我记得一部分，但很多已经记不清了。要是当时记了更好的笔记，现在会轻松很多。