Kubernetes 没有被 AI 取代，但它正被 AI 重新定义。焦虑，是新生的前奏。
在阿姆斯特丹参加完 KubeCon EU 2026 后，我一直在思考一个问题：Kubernetes 没有落伍，但它也不再“够用”；它没有被 AI 取代，却正在被 AI 重新定义。
这是我第三次到欧洲参加 KubeCon，过去几年的 KubeCon，其实可以通过 slogan 看出社区心态的变化：
2024 巴黎：La vie en Cloud Native
→ 云原生已经成为“生活方式”，是默认存在
2025 伦敦：没有 slogan，只有 10 周年纪念
→ Kubernetes 达到阶段性顶点，开始回顾而不是前进
2026 阿姆斯特丹：Keep Cloud Native Moving
→ 但问题是：要往哪里 moving？
2025 年没有 slogan，本身就是一个信号：
当一个生态开始纪念过去，而不是定义未来，它就已经进入了一个拐点。
本文不回顾演讲内容，而是基于我在 KubeCon 的观察，提炼出关于 Kubernetes 在 AI 浪潮下的焦虑与新生的洞察。
焦虑的根源：Kubernetes 面临“危机”？
KubeCon 现场最大的变化，是 AI 彻底取代了传统云原生话题。讨论的重心从服务优化、微服务管理，转向了如何在 Kubernetes 上部署和管理 AI 工作负载，尤其是推理任务和 GPU 调度。
Kubernetes 作为基础设施底座，曾是云原生世界的核心。随着 AI 模型爆发式增长，Kubernetes 是否还能作为“通用”平台承载一切，成为了新的焦虑点。
AI 的火热带来了现实问题：Kubernetes 的 “通用性”能否适应 AI 工作负载的复杂性？
AI 爆发带来的聚焦
AI 的火爆让云原生的焦点完全转向了人工智能。AI coding、OpenClaw、大模型、生成模型等技术引发了广泛关注。AI 已经成为现实世界的核心计算需求。
这种需求增长带来了疑问：Kubernetes 能否继续担当基础设施平台，承载复杂任务？尤其是 GPU 共享、推理模型调度、显存分配、设备属性选择等问题，传统 Kubernetes 资源模型是否足够？
过去，Kubernetes 承载了计算、存储、网络等基础设施。但 AI 加速发展下，其“通用性”正被挑战。尤其在推理任务层面，Kubernetes 的模型显得单薄。
与 OpenStack 的对比：Kubernetes 会重蹈覆辙吗？
OpenStack 曾雄心勃勃，试图成为完整的开源云平台，但最终因复杂性和对新技术适应的灵活性不足而未能持续成长。
Kubernetes 是否会步其后尘？我认为 Kubernetes 有不同优势：作为容器和微服务调度平台，已广泛应用，拥有强大社区和厂商支持；它并不试图取代云服务商所有能力，而是作为基础设施控制平面，帮助用户管理资源。
但随着 AI 工作负载普及，Kubernetes 必须在不被“AI 优化平台”替代的情况下找到新定位。
Kubernetes 的挑战：GPU 资源管理的断裂
NVIDIA 在 KubeCon 上宣布捐赠 GPU DRA（动态资源分配，Dynamic Resource Allocation）驱动给 CNCF，标志着 GPU 资源管理的上游化。GPU 的共享与调度已成为 Kubernetes 亟需解决的问题。
传统上，Kubernetes 依赖 Device Plugin 模型调度 GPU，仅支持基于设备数量的分配（如 nvidia.com/gpu: 1）。但在 AI 推理任务中，需要更多信息来决定资源调度，比如显存大小、GPU 拓扑、共享策略等。NVIDIA DRA 让 GPU 资源管理更灵活智能，逐步缓解 AI 工作负载中的“GPU 资源紧张”问题。
这种变化意味着，Kubernetes 不再只是“容器调度平台”，而是成为处理 AI 专用资源调度的基础设施层。
在这种背景下，社区和产业侧已经开始探索更细粒度的 GPU 资源抽象与调度机制。例如开源项目 HAMi 尝试在 Kubernetes 之上构建一层面向 AI 工作负载的 GPU 资源管理层，支持 GPU 共享、显存粒度分配以及异构设备调度等能力。
这类实践本质上并不是替代 Kubernetes，而是在其之上补齐 AI 时代所缺失的资源模型。从长期来看，这一层很可能演化为类似 CNI / CSI 的“GPU 资源层（GPU Abstraction Layer）”，成为 AI 原生基础设施中的关键组成部分。
生产化“断层”：AI 的 PoC 多，生产环境少
会后总结普遍提到：PoC 很多，但“日常生产部署”依然稀缺。Pulumi 的总结：
lots of working demos, very few production setups people trust
这说明，许多 AI 工作负载解决方案在技术展示中成功，但从实验到生产的过渡依然困难。无论是 GPU 资源共享，还是推理请求调度，Kubernetes 作为底座能否顺利承接变革，仍是悬而未决的问题。
推理系统的崛起：Kubernetes 调度边界被挑战
在本次 KubeCon 我觉得还有一个重大事件，就是 llm-d 被贡献给 CNCF，成为 Sandbox 项目。
如果说 GPU DRA 代表的是设备资源模型的上游化，那么 llm-d 所代表的，是另一条同样关键的演进路径：分布式 LLM 推理能力正在从各家厂商的工程实现，逐步走向云原生社区中的标准化协作对象。
这件事的意义不只是多了一个开源项目，而是说明 Kubernetes 在 AI 时代面临的挑战，已经不再只是“如何调度 GPU”，还包括“如何承载推理系统本身”。当 prefill / decode 拆分、请求路由、KV cache 管理、吞吐优化等能力进入基础设施层，Kubernetes 的边界正在被重新定义。
传统 Kubernetes 调度器关注 Pod 调度。但在 AI 推理场景，调度责任不仅是选择节点，更是如何根据请求特点选择最合适的推理实例。如模型状态、请求队列深度、缓存命中率等都需纳入调度决策。这一过程逐步被推理运行时控制，形成新的“请求级调度”系统。
这带来了 Kubernetes 调度器与推理系统的分层重叠，Kubernetes 需重新思考自身角色：是继续扩展，还是与推理系统协同？
AI 原生基础设施：生产化的关键挑战
在 AI Native Summit 上，AI 原生基础设施的实际需求尤为突出。讨论焦点不再是“是否能跑在 Kubernetes 上”，而是如何让 AI 工作负载成为 Kubernetes 上的常规业务，稳定运行并具备生产能力。
核心挑战在于交付。与传统应用不同，AI 模型权重通常极大，达几十 GB 甚至 TB 级，导致模型交付和数据管理异常复杂。传统容器交付体系（如镜像层）难以应对如此庞大的数据量和复杂的版本管理。
Kubernetes 未来的重要方向，是将模型权重和数据交付标准化，通过引入 ImageVolume 和 OCI artifacts 解决 AI 模型在 Kubernetes 上的交付和版本管理问题。这不仅能减少“冷启动”时间，还能为模型多租户、合规等需求提供基础设施支撑。
总结
Kubernetes 不会被 AI 取代，但正被 AI 重塑为基础设施核心。这种焦虑，是推动其不断进化的力量——它正从 “通用基础设施平台” 逐步演变为 “AI 支撑的多功能底座”，甚至有媒体将其评论为 AI 操作系统。
未来，Kubernetes 的核心竞争力不再只是容器管理，而是如何有效调度和管理 AI 工作负载，如何让 AI 成为常规运营的一部分。这是我在 AI Native Summit 和 KubeCon 上最大的启发，也是对未来几年 Kubernetes 生态的期待。
