AI Agent开始直连基础设施，Kubernetes加速适配

云基础设施长期围绕人类用户设计：管理员通过控制台、命令行或 API 提交请求，平台再依据预设规则分配计算、存储和网络资源。随着 AI Agent 能够自主判断任务、调用工具并提出资源需求，基础设施的使用者正从人和固定自动化逻辑扩展到软件智能体，底层控制接口与调度方式也需要重新设计。

在 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 期间，OpenInfra 基金会总经理 Thierry Carrez（阚雷）和 CNCF 执行总监、Linux 基金会云与基础设施执行总监 Jonathan Bryce（傅兰石）分别谈到了这一变化。Thierry 认为，未来基础设施需要更直接、轻量、语义化且可编程的控制方式，并推动目前多在封闭环境中的创新进入开放社区。Jonathan 则介绍了 Kubernetes 面向 AI 硬件的适配进展。

Kubernetes 正借助 DRA（Dynamic Resource Allocation，动态资源分配）等插件机制接入 GPU 及其他加速器。厂商可以通过插件暴露芯片能力，避免将每种硬件逐一写入 Kubernetes 核心代码。CNCF 还推出 Kubernetes AI Conformance，在既有由上百家公司参与的 Conformance 体系基础上，为 AI 基础设施建立更统一的兼容与治理规则。其方向被概括为支持“任何芯片、任何云、任何 Agent”。

AI 工作负载带来的挑战并不只是算力需求增加。GPU、NPU 等设备存在型号差异、切分方式差异和不同的任务适配性，训练、预填充与解码也有不同资源要求。未来 Agent 可能动态决定申请何种资源、启动多少实例，调度系统因此要在异构且持续变化的资源池中处理更复杂的资源语义，而不是简单安排容器运行节点。

OpenInfra 与 Kubernetes 分别处于不同层次。OpenInfra更接近硬件和基础设施，负责提供并控制计算、网络、存储等资源；Kubernetes位于云原生编排层，上方则是 PyTorch、vLLM 等训练与推理工作负载。典型架构可以是 Linux 承载底层系统，OpenStack 管理服务器和硬件，Kubernetes 编排容器，最上层运行模型训练或推理。Metal3 已将 OpenStack 裸金属能力接入 Kubernetes，CNCF 生态的 LLMD 也在与 PyTorch 体系衔接。

当 Agent 需要动态调用 GPU、裸金属、PCIe 直通、专用网络或存储时，Kubernetes无法独立解决硬件安全暴露和底层资源控制问题，硬件层与编排层之间仍存在空白。与此同时，Agent 还带来新的安全边界：系统不仅要隔离工作负载，还要明确其授权范围、操作记录和故障处置方式。Thierry 将 Kata Containers视为 AI 安全的重要项目之一，并指出未来还需强化可审计性与可逆性，使资源调用过程能够追踪，并在必要时进行回退或撤销。