文章指出，自建Kubernetes难以应对智能体AI时代。智能体AI需动态基础设施，传统方法力不从心。自建平台后期运维成本高昂。未来趋势是采用自主平台，效仿公有云模式，以高效支持AI工作负载，专注于业务价值而非底层构建。
译自：Why your DIY Kubernetes stack won't survive the era of agentic AI
作者：Oren Penso
我们正处于企业IT的转折点。在过去的十年中，“现代化”一直是容器化的代名词——本质上是将应用程序打包，使其可以在任何地方运行。但目标已经改变。挑战不再仅仅是运行静态微服务；而是为智能体AI时代以及动态的、资源密集型的工作负载做准备，这些工作负载挑战了传统的基础设施规划。
这不仅仅是技术转向；这是一种由格局中的几次巨大转变驱动的生存策略。
首先，我们面临AI现实检验。我们正迅速从简单的聊天机器人转向自主智能体——能够规划、推理和行动的软件。这些智能体不符合传统应用程序可预测的“朝九晚五”使用模式。它们具有突发性，需要在短推理窗口内消耗大量计算资源，并在空闲时缩减至零。试图用僵化的、基于工单的基础设施供应来支持这些流动性工作负载是行不通的。你根本无法为需要立即扩展的智能体进行手动供应。
其次是效率崩溃。企业正淹没在自建平台的“后期运维成本”中。通过拼凑不同的开源工具，团队无意中造成了巨大的维护负担。高薪工程师把时间花在修补 ingress controllers 和调试 YAML 上，而不是交付业务价值。维护平台的成本已经超越了它所托管应用程序的价值。
最后，我们面临私有云需求。随着数据引力和主权问题的增长，公有云并非总是答案。企业需要在自己的数据中心内建立“云运营模式”——提供 API，而非工单的能力。
核心要点很简单：我们需要停止构建平台，开始消费平台。基础设施必须变得隐形，以便人类和人工智能的智能都能蓬勃发展。
“自建平台”的终结
在过去的十年里，我们一直陷入一个错误的二元选择。企业要么是运行 Kubernetes 的“云原生”，要么是运行虚拟机的“传统”企业。业界投入了数十亿美元和无数的工程时间来改写物理定律，说服自己只要我们将一切容器化，就能达到运维涅槃。
剧透预警：这并没有发生。
相反，我们构建了“弗兰肯斯坦平台”。看看你的普通平台工程团队。他们正被复杂性所淹没，试图将 ArgoCD、Istio、Tekton、Prometheus 和十几个其他 CNCF 项目拼凑在一起，只是为了重新创建 Pivotal Cloud Foundry（现在的 Tanzu Platform）早在2012年就解决的开发者体验。
“这些弗兰肯斯坦平台的隐性成本不仅仅是前期工程投入；它是‘后期运维噩梦’……你的平台团队停止创新，转而救火。”
这些弗兰肯斯坦平台的隐性成本不仅仅是前期工程投入；它是“后期运维噩梦”。当安全漏洞影响到特定版本的 Istio，或者当 Prometheus 更新破坏了你的 Grafana 仪表盘时，你的平台团队就会停止创新，转而救火。他们变成了过度劳累的、脆弱技术栈的运维人员，而不是业务价值的赋能者。我们向开发者承诺自助服务体验，但我们却给了他们一个长期处于困境的平台团队的工单队列。
但展望2026年基础设施的发展方向，我们认识到一种新模式。这并非是在过去的稳定性和未来的灵活性之间做出选择。而是将它们叠加起来。
通用控制平面
Kubernetes 最近最重要的发展与容器无关。它认识到 Kubernetes API 实际上是数据中心的通用控制平面。这是 Kubernetes 是一个构建平台的平台这一概念背后的主要思想；是一个更好的起点，而不是终局。
我们用了比预期更长的时间才理解这一点，而是将 Kubernetes 视为直接销售给开发者的产品，迫使他们处理 YAML 并找出 pod disruption budgets。最终，我们明白 Kubernetes 从来就不是用户界面。它是现代数据中心的汇编代码，是我们构建的隐形层。
缺失的环节：自主运维
虽然 Kubernetes 解决了基础设施 API 的问题，但它可能使应用程序生命周期变得更糟。我们用无休止的配置的原始灵活性取代了平台即服务 (PaaS) 的护栏。但我们再次从 Cloud Foundry 中寻求对未来的洞察。如果最终目标真的是自主运维，那么你需要一个强制标准化以确保一致性和规模的平台。通过平台交付标准工具和实践，我们可以实现自动化涅槃！
让我们考虑 BOSH，Cloud Foundry 的核心。虽然表面上 BOSH 看起来像一个部署工具，但它的功能更像一个可用性工程师。它不仅部署代码，还监控系统健康状况，恢复故障组件，轮换凭证，并在不中断运行的情况下修补操作系统。
与通常专注于应用层的标准 Kubernetes operators 不同，BOSH 深入理解基础设施依赖。它知道如何在应用程序和开发者都没有察觉到任何中断的情况下排空节点、重新配置操作系统和重新挂载存储。它提供了原生 Kubernetes 假设由其他人处理的“动态修复”能力。在一个日益复杂的世界中，拥有一个能够在 VM 级别自愈的平台并非奢侈品；它是规模化的先决条件。
AI 催化剂
这种对有主见、一致的应用平台的需求正受到智能体AI爆发的强烈推动。
看看公有云如何解决 AI 智能体的问题。它们肯定没有直接将原生 Kubernetes 集群交给开发者。公有云智能体平台完全抽象化了基础设施。为什么？因为 AI 智能体是非确定性的。它们扩展迅速，串联复杂任务，并且需要短暂环境。在“Pod”级别管理数千个自主智能体的生命周期是一个噩梦。
“公有云智能体平台完全抽象化了基础设施。为什么？因为 AI 智能体是非确定性的。它们扩展迅速，串联复杂任务，并且需要短暂环境。”
此外，智能体AI的资源需求不可预测地激增。一个智能体可能空闲数小时，然后突然需要海量计算资源来并行化复杂的推理链。硬编码此基础设施效率低下且昂贵。我们需要一个将这些智能体视为一等公民的平台，在空闲时自动将底层计算资源缩减至零，并在智能体需要“思考”时即时爆发，而无需人工操作员供应一台服务器。
业界正在用行动投票：AI 需要高级的、有主见的平台。如果我们想在本地（数据所在地）运行这些工作负载，我们就不能依赖底层管道。我们需要一个模仿公有云模式的技术栈。
后炒作时代
“简历驱动开发”——仅仅因为工具时髦就选择它们的时代——已经结束。下一波思想领导力是关于融合。
我们正在进入“工业化 Kubernetes”阶段。修修补补阶段已经结束。目标不再是看我们是否能构建它，而是看我们能多快地在其上交付价值。未来十年的赢家不会是构建最复杂 Kubernetes 集群的那些人。他们将是那些意识到最好的平台是你无需自己构建的平台的人。
