文章指出Kubernetes正成为AI模型的理想“光荣宿主”，通过标准化和边缘部署，为AI应用提供可靠、无摩擦的基础设施，实现产品市场契合。
译自：Why the ‘glorified host’ for AI is exactly the Kubernetes we need
作者：Danielle Cook
我最近看到一篇 Hyperframe Research 的帖子，其中提出了一个我们许多身处云原生一线的人们一直在低声讨论的问题：Kubernetes 真的只是人工智能模型的“光荣宿主”吗？
这个标题具有煽动性，但对于我们这些正在构建下一代分布式基础设施的人来说，它实际上是具有启发性的。 它表明我们终于走出了“为 Kubernetes 而 Kubernetes”的时代。我们正在进入一个阶段，编排器的价值完全由它所支持的工作负载来定义。而现在，这种工作负载就是人工智能。从这个意义上说，成为“光荣宿主”根本不是一种贬低；它证明了 Kubernetes 已成为人工智能所需要的确切基础设施，并在此过程中找到了其产品与市场契合点。
而且，如果 Kubernetes 正在成为一个“光荣宿主”，那么我们的工作就是让这个宿主成为这个星球上最可靠、最分布式、最无摩擦的引擎。
“隐形引擎”的成熟
多年来，K8s 社区一直专注于“如何做”——如何管理状态、如何扩展 Pod、如何驾驭不断扩展的 CNCF 生态系统。但正如 Hyperframe 报告所指出的，现在“做什么”已经转变了。Kubernetes 正在成熟为“云的操作系统”，就像任何优秀的操作系统一样，当它“消失”时，它的表现最好。
“Kubernetes 正在成熟为‘云的操作系统’，就像任何优秀的操作系统一样，当它‘消失’时，它的表现最好。”
当您运行大规模 AI 推理工作负载时，您不想支付“复杂性成本”，也不想被锁定在超大规模厂商特定的 API 中，这些 API 会将您的可移植容器变成专有孤岛。您需要一个符合 Kubernetes 标准的集群，可以部署在 AI 推理需要的地方——靠近最终用户。
开发人员需要一种方法来获取模型服务所需的计算原语和 GPU 直通功能，而无需承担传统上困扰“三大”Kubernetes 托管服务的开销。
因为推理本质上是分布式的，而 Kubernetes 正是为此而构建的。我们面临的挑战是，如果 Kubernetes 是 AI 的标准化运行时，那么这个引擎就应该不影响开发人员。今天不一定如此，这就是为什么平台工程在 AI 工作负载中变得更加重要。开发人员需要一种方法来获取模型服务所需的计算原语和 GPU 直通功能，而无需承担传统上困扰“三大”Kubernetes 托管服务的开销。
自动化第二天“AI 税”
让 Kubernetes “隐形”说起来容易做起来难——世界各地的平台团队仍在为此而努力！报告正确地指出，尽管 K8s 是 AI 的理想宿主，但进入门槛仍然很高。大多数团队遇到的困难不是在第一天（启动集群），而是在第二天（保持其安全、可观测和连接）。
运行 AI 工作负载只会放大这种成本。在模型投入生产之前，团队需要连接 CI 流水线、构建和扫描镜像、实施安全策略、管理密钥、配置入口、搭建可观测性堆栈以及维护 GitOps 工作流。这种持续的维护和管理可能繁琐、脆弱且分散注意力。每一个工具的选择都会引入另一个需要构建的集成和另一个需要维护的表面区域。
如果 Kubernetes 要成为 AI 的无缝宿主，那么整个流水线都必须“消失”。
在整个生态系统中，这导致人们越来越重视完全基于上游 CNCF 项目构建的、带有鲜明观点的平台。挑战不在于这些操作任务中的任何一个都是新颖的。而是 AI 工作负载迫使团队同时应对所有这些任务。
公司需要知道他们已经具备了云原生基础，以便开发人员可以专注于他们的工作。这意味着要么花费数年时间构建自己的专属平台，要么使用一个已经集成了团队所需所有开源工具的云原生堆栈，包括部署自动化、策略实施、运行时保护、可观测性 和流量管理。问题在于您将资源投入到何处，是构建已经存在的东西，还是选择一个可以随着时间推移部署和扩展的开源平台。
这正是 Kubernetes 成熟之处变得显而易见的地方。进步不再通过新的原语来衡量，而是通过这些开源项目的集成程度来衡量。让 Kubernetes “隐形”意味着通过标准化 AI 工作负载周围的操作支架来降低复杂性，从而使平台在压力下表现可预测。
当这些模式一致且与上游对齐时，Kubernetes 就可以退居幕后。编排器成为一个可靠的宿主，团队可以将注意力重新集中到真正使他们的应用程序脱颖而出的模型、数据流水线和推理策略上。
边缘：将宿主带到数据所在地
如果 Kubernetes 是这些模型的宿主，那么该宿主的位置就是下一个差异化因素。
集中式云区域非常适合计算密集型、批处理型工作负载，这些工作负载受益于集中的基础设施，例如训练。但推理是延迟敏感且面向用户的。无论是实时欺诈检测还是生成式 AI 聊天，响应速度直接影响用户体验。
这正在推动人们对分布式部署模型日益增长的兴趣，包括边缘和近边缘环境。在靠近最终用户或数据源的地方运行 Kubernetes 集群可以减少延迟，提高弹性，并实现新的实时用例。
在这些场景中，编排器的职责保持不变：确保模型服务可用、可扩展和可观测。但操作限制发生了变化。集群可能更小、数量更多、地理位置分散，硬件占用空间各异，网络条件也波动不定。
编排层必须足够一致，才能在异构环境中管理分布式 AI 推理，而不会重新引入令人望而却步的复杂性。
为 AI 而 Kubernetes
Hyperframe 团队正确地指出了这一转变。将 Kubernetes 视为一项精细工匠技艺的时代已经结束。我们现在正处于为 AI 而 Kubernetes 的时代。
通过深入理解“光荣宿主”的身份，我们可以为开发人员提供一个标准化、可移植且极其快速的基础，以支持 2026 年及以后的人工智能原生应用程序。
“将 Kubernetes 视为一项精细工匠技艺的时代已经结束。我们现在正处于为 AI 而 Kubernetes 的时代。”
如果 Kubernetes 因为其“开箱即用”而达到了备受推崇的产品市场契合状态，那么我们作为一个社区就已经完成了我们的工作。现在，让我们看看我们能在此基础上构建什么。
