企业官网建设流程全解析

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% 的容器用户在生产环境运行 Kubernetes，66% 托管生成式 AI 模型的企业，使用 Kubernetes 承载部分或全部推理工作负载。也就是说，Kubernetes 早已不再是"互联网大厂的玩具"，而是整个软件行业默认的运行时底座。

从演进路径看，Kubernetes 的十年恰好对应软件架构的三次跃迁：

• **微服务时代（2015-2020）**：无状态服务的部署、滚动发布、服务发现与多租户平台被彻底固化，K8s 借此奠定了事实标准的地位；

• **数据 + GenAI 时代（2020-2024）**：分布式数据处理与 GPU 重负载的训练/推理进入主流，K8s 开始承载有状态、异构算力工作负载；

• **Agentic 时代（2025+）**：工作负载从 request/response API 转向长时间运行的推理循环（reasoning loop），AI Agent 需要持续执行、记忆与工具调用。

训练任务需要万卡级集群的拓扑感知调度，推理服务需要秒级弹性伸缩与 GPU 共享，Agent 需要持久化记忆和完整的生命周期管理——这些诉求最终都收敛到同一个答案：Kubernetes。正如 AWS 在 CNCF 官方博客《The great migration》中所言：所有 AI 平台都在向 Kubernetes 汇聚，这不是巧合，而是声明式基础设施对 AI 复杂性的必然胜利。

二、Kubernetes 1.36：DRA 让 GPU 调度成为一等公民

K8s 1.36 是 2026 年最重要的版本更新，核心特性是动态资源分配（Dynamic Resource Allocation，DRA）正式 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: "1"

DRA 的意义不只是语法升级：它为 GPU 虚拟化、异构算力（昇腾、寒武纪等国产芯片）的接入提供了标准底座，让"国产卡 + K8s"的组合第一次有了统一的资源抽象层。对平台团队来说，这是 2026 年最值得优先跟进的能力。

三、HAMi：把 GPU 利用率从 30% 拉到 80% 以上

GPU 贵，闲置更贵。行业调研显示，多数推理集群的 GPU 平均利用率长期徘徊在 30% 以下——模型推理通常是显存密集、算力稀疏的，整卡独占必然造成巨大浪费。HAMi（Heterogeneous 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"

而Kueue（CNCF 孵化项目）负责队列层：通过 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 到有状态 Agent

2026 年的另一个关键词是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 落地实践。