Kubernetes 十周年从 Cloud Native 到 AI Native云原生架构正在经历的范式跃迁2026 年 7 月CNCF 正式宣告 Kubernetes 迎来十周年里程碑几乎同一时间7 月 28 日至 30 日在横滨举办的 KubeCon Japan 2026把大会主题词从 Cloud Native 换成了 AI Native。这不是营销话术而是一个真实的行业信号Kubernetes 正从容器编排平台进化为AI 基础设施的核心底座。本文结合 K8s 1.36 动态资源分配DRA、HAMi GPU 共享、Volcano、Kueue、llm-d 等最新进展拆解这场架构演进的技术脉络与落地姿势希望对后端、架构与云原生方向的同学有所启发。一、一组数据为什么所有 AI 平台都在向 Kubernetes 收敛先看几组硬数据。CNCF 最新发布的《State of Cloud Native Development Q1 2026》报告显示全球云原生开发者数量已突破 1560 万超过 78% 的企业在生产环境使用容器技术。而 CNCF 在 2026 年 1 月公布的年度调查给出了两个更关键的数字82% 的容器用户在生产环境运行 Kubernetes66% 托管生成式 AI 模型的企业使用 Kubernetes 承载部分或全部推理工作负载。也就是说Kubernetes 早已不再是互联网大厂的玩具而是整个软件行业默认的运行时底座。从演进路径看Kubernetes 的十年恰好对应软件架构的三次跃迁• **微服务时代2015-2020**无状态服务的部署、滚动发布、服务发现与多租户平台被彻底固化K8s 借此奠定了事实标准的地位• **数据 GenAI 时代2020-2024**分布式数据处理与 GPU 重负载的训练/推理进入主流K8s 开始承载有状态、异构算力工作负载• **Agentic 时代2025**工作负载从 request/response API 转向长时间运行的推理循环reasoning loopAI Agent 需要持续执行、记忆与工具调用。训练任务需要万卡级集群的拓扑感知调度推理服务需要秒级弹性伸缩与 GPU 共享Agent 需要持久化记忆和完整的生命周期管理——这些诉求最终都收敛到同一个答案Kubernetes。正如 AWS 在 CNCF 官方博客《The great migration》中所言所有 AI 平台都在向 Kubernetes 汇聚这不是巧合而是声明式基础设施对 AI 复杂性的必然胜利。二、Kubernetes 1.36DRA 让 GPU 调度成为一等公民K8s 1.36 是 2026 年最重要的版本更新核心特性是动态资源分配Dynamic Resource AllocationDRA正式 GA。在 DRA 之前GPU 只能通过 nvidia.com/gpu 这类扩展资源整卡分配无法表达显存、算力切片、拓扑亲和等细粒度需求集群调度器对设备内部结构一无所知只能做有或没有的粗粒度匹配。DRA 之后局面彻底改变设备被建模为具有属性的对象DeviceClass、ResourceClaim、ResourceSlice调度器按需求精准匹配第三方厂商只需实现一个 DevicePlugin 即可接入任意硬件。显存 8G 的切片、指定 NVLink 互联域、独占或共享策略这些诉求第一次成为调度的原生输入。一个典型用法如下apiVersion: resource.k8s.io/v1beta1 kind: ResourceClaim metadata: name: gpu-claim spec: devices: requests: - name: gpu deviceClassName: nvidia.com/gpu --- apiVersion: v1 kind: Pod metadata: name: llm-infer spec: resourceClaims: - name: gpu source: resourceClaimName: gpu-claim containers: - name: vllm image: vllm/vllm-openai:latest resources: limits: nvidia.com/gpu: 1DRA 的意义不只是语法升级它为 GPU 虚拟化、异构算力昇腾、寒武纪等国产芯片的接入提供了标准底座让国产卡 K8s的组合第一次有了统一的资源抽象层。对平台团队来说这是 2026 年最值得优先跟进的能力。三、HAMi把 GPU 利用率从 30% 拉到 80% 以上GPU 贵闲置更贵。行业调研显示多数推理集群的 GPU 平均利用率长期徘徊在 30% 以下——模型推理通常是显存密集、算力稀疏的整卡独占必然造成巨大浪费。HAMiHeterogeneous AI Computing Virtualization Middleware正是为解决这个问题而生通过 GPU 虚拟化技术多个容器可以共享同一张 GPU并支持显存与算力SM 切片的精细隔离容器间互不干扰。2026 年 7 月 2 日HAMi 以 TOC 全票通过正式晋升为CNCF Incubating孵化项目并在 KubeCon EU 与 Japan 大会上成为主论坛 Demo 的常客社区热度持续走高。它的使用方式非常简洁——部署 device plugin 后通过 ConfigMap 声明切片策略apiVersion: v1 kind: ConfigMap metadata: name: hami-device-plugin namespace: kube-system data: config.yaml: | vgpu: resources: - name: nvidia.com/gpu memory: 8192 # 每张卡切出 8G 显存 cores: 40 # 算力占整卡 40%部署完成后Pod 只需像往常一样声明 nvidia.com/gpu: 1调度器便会自动完成一卡多用。实测在 LLM 推理与 CV 推理混合场景中HAMi 可将集群 GPU 整体利用率提升至 80% 以上同时保持显存隔离与故障独立。对于预算有限的中小团队这几乎是零成本扩容的最优解。四、训练与推理混部Volcano Kueue 双引擎分布式训练和在线推理的调度诉求截然不同训练任务需要gang scheduling所有 worker 同时启动否则先启动的 Pod 会互相等待造成资源死锁推理任务需要基于队列的公平配额与优先级抢占。单一调度器很难同时优雅地满足两者于是生态分化出两个互补项目。Volcano v1.14已从批处理作业调度器升级为 AI-Native 统一调度平台原生支持 LLM 训练 推理混合调度。其 gang-scheduling 机制确保分布式训练任务的所有 Pod 一次性就位从根本上避免了资源死锁apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: llm-finetune spec: minAvailable: 4 # 4 个 worker 全部就绪才开始 schedulerName: volcano tasks: - name: worker replicas: 4 template: spec: containers: - name: train image: registry.example.com/llm/train:latest resources: limits: nvidia.com/gpu: 8而KueueCNCF 孵化项目负责队列层通过 ClusterQueue / LocalQueue 把不同团队、不同优先级的 AI 任务纳入统一配额体系支持训练任务被高优推理任务抢占、GPU 资源在多租户间弹性流转让算力即服务在集群内部真正落地apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata: name: ai-queue spec: namespaceSelector: {} resourceGroups: - coveredResources: [nvidia.com/gpu, cpu, memory] flavors: - name: gpu-a100 resources: - name: nvidia.com/gpu nominalQuota: 64 # 该队列最多可用 64 卡实践中Volcano 管怎么把任务跑起来Kueue 管任务之间如何排队与让位二者配合即可覆盖训练、推理、批处理三大场景的调度需求。五、推理部署标准化llm-d 与 vLLM 的组合拳推理引擎碎片化vLLM、TGI、TensorRT-LLM 各有一套部署方式与运维语义曾是平台团队最大的痛点换一个引擎监控、扩缩容、灰度策略全要重做。CNCF 与 Red Hat 联合贡献的llm-d 框架正在统一 LLM 部署标准通过标准的 CRD 描述模型服务底层可自由切换推理引擎上层体验保持一致。一个典型的 vLLM 推理服务长这样apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen spec: replicas: 2 template: spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [python3, -m, vllm.entrypoints.openai.api_server] args: [--model, Qwen/Qwen3-32B, --tensor-parallel-size, 4] resources: limits: nvidia.com/gpu: 4 readinessProbe: tcpSocket: port: 8000配合 KEDA Prometheus 指标推理副本可以按请求队列深度、GPU 利用率等业务指标自动伸缩——这正是那 66% 的企业选择用 K8s 跑推理的根本原因弹性、标准化、可观测三者兼得模型服务终于可以像普通微服务一样被发布与运维。六、AI Agent 编排从无状态 Pod 到有状态 Agent2026 年的另一个关键词是Agent Native。阿里云在 WAIC 2026 发布了 Agent Native Cloud宣告 Agent 从能用的玩具进化为可传承、可治理、会生长的组织级资产。但随之而来的工程问题是Agent 跑在哪传统做法是把它塞进 Pod 或 Serverless 函数可 Agent 的核心特征是有状态——它需要持久化记忆、任务上下文和工具调用历史重启即失忆显然不可接受。社区正在用 CRD 把 Agent 建模为 K8s 一等公民让声明式编排能力直接作用于 Agent 本身apiVersion: agent.k8s.io/v1 kind: Agent metadata: name: code-review-agent spec: model: gpt-5.2 tools: - name: github type: mcp-server config: url: http://mcp-github:8080 memory: type: vector-db config: url: postgresql://agent-memory:5432/agents triggers: - type: webhook config: events: [pull_request]当 Agent 拥有独立的生命周期、持久化记忆与工具权限K8s 的 Reconcile 循环、滚动升级、多副本容灾将第一次真正作用于 AI 应用本身——而不是只服务于承载它们的 Pod。MCP Server 作为 Agent 的工具总线与 K8s Service 发现天然契合Agent 生态与云原生生态正在加速融合。七、结语架构师视角的下一个十年从 Borg 到 K8s 用了十年从 Cloud Native 到 AI Native 可能只需要两三年。对于后端与架构从业者2026 年的能力坐标系已经非常清晰1.掌握 DRA 与设备插件模型理解 GPU 从整卡资源到可切片资源的语义变化这是异构算力调度的地基2.吃透 Volcano、Kueue、HAMi 的调度语义能针对训练、推理、混部场景做正确的资源建模与配额设计3.熟悉 llm-d 与 vLLM 部署模式把模型服务当普通微服务来发布、观测、扩缩容形成标准化的推理平台4.关注 Agent CRD 化趋势提前思考有状态 Agent 的存储、治理、权限与安全边界这是下一个爆发点。Kubernetes 的第十年不是终点而是AI 原生的起点。当 1560 万开发者的基础设施底座与万亿参数模型相遇属于架构师的黄金时代才刚刚开始。希望这篇文章能帮你把AI Native从概念变成可执行的路线图——欢迎在评论区聊聊你所在团队的云原生与 AI 落地实践。