云原生的下半场不是被 AI 取代，而是被 AI 重写。平台工程的未来，将以模型和 Agent 为核心，重塑技术栈与开发体验。
自 2015 年接触 Docker 和 Kubernetes 起，我始终沿着云原生主线前行：从最初在 YAML 里写 Deployment，到探索 Service Mesh、可观测性，再到近两年聚焦 AI Infra 与 AI Native 平台。站在 2025 年回望，2015–2025 可视为“云原生的上半场”。以 KubeCon / CloudNativeCon NA 2025 为标志，行业正集体迈入“下半场”：AI Native 平台工程时代。
本文将回顾云原生的上一个十年，并结合 KubeCon NA 2025 的内容，梳理关键拐点与下一个十年的技术坐标系。
2015–2025：云原生的“上半场”
过去十年，云原生技术主题大致分为三个阶段。下方流程图展示了各阶段的演进关系。
第一阶段：2015–2017 容器编排标准化
本阶段的主线是容器化与编排标准化。
- Docker 实现“打包一次，到处运行”的工程现实
- Kubernetes 在多轮“编排战争”中胜出，成为事实标准
- CNCF 成立，Prometheus、Envoy 等项目陆续加入
- 企业关注点集中在应用如何迁移到 Kubernetes
在实际工作中，这一阶段最典型的任务是将一批 Java 服务从虚拟机迁移到容器和 K8s，重点理解 Deployment、Service、Ingress 等基础概念。
第二阶段：2018–2020 服务网格与可观测性
Kubernetes 稳定后，复杂度开始从“部署”转向“通信”和“运维”。
- Service Mesh（Istio / Linkerd / Consul）解决东西向流量治理
- 可观测性三件套（Logs / Metrics / Traces）成为默认配置
- 多集群、多 Region 实践逐步落地
- 企业开始关注庞大微服务系统的治理
这一阶段，我投入大量时间研究 Istio、服务网格和流量治理，并撰写 Kubernetes Handbook 及 Istio 相关书籍。关注点转向系统稳定性、可观测性和可靠性提升。
第三阶段：2021–2025 平台工程与 GitOps
随着微服务和工具数量激增，平台复杂度开始反噬开发者，Platform Engineering 成为行业关键词。
- GitOps（Argo CD / Flux）推动交付流程声明化
- 内部开发者平台（IDP）成为大中型企业建设重点
- “平台即产品”理念传播
- FinOps、成本治理、合规审计纳入平台维度
- DevOps 从“工具实践”演化为“组织能力 + 平台能力”
我的体会是：大家逐渐意识到，“给开发者一堆工具”并非答案，更需要端到端交付路径和稳定抽象层，让开发者专注业务而非工具拼接。
下表压缩展示了“上半场”各阶段的主要特征。
| 阶段 | 核心矛盾 | 关键技术栈 | 典型问题 |
|---|---|---|---|
| 2015–2017 编排 | 从 VM 迁移到容器 | Docker、Kubernetes、CNI | 如何可靠部署、如何滚动升级 |
| 2018–2020 网格 | 微服务数量扩大，通信与观测变复杂 | Istio/Linkerd、Prometheus、Jaeger | 排障困难、可观测性碎片化 |
| 2021–2025 平台 | 工具堆叠过多，开发体验持续下滑 | GitOps、IDP、FinOps、Policy-as-Code | 开发者疲惫、平台团队被压扁 |
KubeCon NA 2025：云原生“下半场”的信号
2025 年 KubeCon 的主旋律已不再是“如何用好 Kubernetes”，而是聚焦 AI 时代，如何将 Kubernetes 与云原生生态重构为 AI Native 平台。
今年 KubeCon NA 2025 上，行业出现了以下集中信号：
- CNCF 发布 Certified Kubernetes AI Conformance Program
- Dynamic Resource Allocation（DRA, 动态资源分配）进入主流语境
- Model Runtime / Agent Runtime 项目成为大会热点
- 厂商聚焦 AI SRE、AI Assist Dev、AI 安全与供应链治理
- Alex Zenla 等讲者直言 Kubernetes 底层结构需重构
这些内容共同构成了清晰分界线：云原生正式进入“下半场”。
上半场 vs 下半场：云原生叙事的切换
如果将 2015–2025 视为“上半场”，那么 2025–2035 很可能是“下半场”。下表对比了两者的核心差异。
该表展示了平台对象、目标、抽象层等关键维度的变化。
| 维度 | 上半场（2015–2025） | 下半场（2025–2035，AI Native） |
|---|---|---|
| 核心对象 | 容器、Pod、微服务 | 模型、推理任务、Agent、数据管线 |
| 平台目标 | 稳定交付应用 | 持续、高效地运行 AI 工作负载与 Agent 编排 |
| 抽象层 | Deployment / Service / Ingress / Job | Model / Endpoint / Graph / Policy / Agent |
| 资源调度 | CPU / 内存 / 节点 | GPU / TPU / ASIC / KV Cache / 带宽 / 能耗 |
| 工程主线 | DevOps / GitOps / 平台工程 1.0 | AI Native Platform Engineering / AI SRE |
| 安全与合规 | 镜像安全、CVE、供应链 SBOM | 模型安全、数据安全、AI 供应链与“幻觉依赖” |
| 运行时形态 | 容器 + VM + Serverless | 容器 + WASM + Nix + Agent Runtime |
从开发者视角看，最直观的变化是：未来平台不再以“服务”为一等公民，而是以“模型 + Agent”为核心。
样貌之一：AI Native 平台的技术分层
为帮助理解 AI Native 平台的结构，下方分层图展示了各技术层级的关系。
原有云原生主要聚焦于 L0 + L2（Kubernetes + 平台工程），而 AI Native 时代，L1（Model Runtime、Agent Runtime、异构资源调度）成为新主战场。
关键变化一：从“容器为中心”到“模型为中心”
在上半场，云原生主要对象是应用进程，容器仅为打包形式。下半场则需处理：
- 模型版本管理与灰度发布
- 推理性能、延迟与成本平衡
- 多模型组合、路由、A/B 实验
- 模型与数据、特征、向量索引的关系
KubeCon NA 2025 上 CNCF 发布的 AI Conformance Program，核心在于标准化模型工作负载，让其像 Deployment 一样被管理。平台工程将迎来新的抽象层，不再只是“部署服务”，而是“部署模型能力”。
关键变化二：DRA 与异构资源调度的黄金窗口期
过去编写 Deployment 时，主要关注 CPU 和内存。如今，GPU 推理、训练、Agent Runtime 等场景下，静态配额已无法满足需求。
动态资源分配（Dynamic Resource Allocation） 带来如下变化：
- 资源类型可插拔（GPU/TPU/FPGA/ASIC）
- 按拓扑、NUMA、显存碎片智能调度
- 推理请求与算力分配绑定，实现更细粒度 QoS
- 成本优化与功耗控制纳入调度决策
这是 Kubernetes 诞生以来最重要的“资源观”升级。调度器不再只是集群组件，而是 AI 平台的策略引擎。
关键变化三：Agent Runtime 成为新一代运行时
KubeCon 上涌现出一批代表性项目：
这些项目的共识是：AI Agent 不适合完全套用传统容器运行模型。Agent 具备如下特点：
- 强状态性：上下文、记忆、会话
- 高并发但颗粒度细：海量轻量任务
- 对延迟和冷启动极其敏感
- 需支持失败后继续执行（resume）
新一代运行时关注如何为“十万级 Agent”提供可靠执行、状态管理和审计，而不仅仅是“多开 Pod”。
关键变化四：AI SRE 与 AI 安全
KubeCon NA 2025 上，安全与运维话题因 AI 被进一步放大：
- 软件供应链攻击与 CVE 持续增加
- LLM 辅助编码带来“幻觉依赖库”和“vibecoded 漏洞”
- AI 驱动的制品扫描、依赖审计和许可分析
- “AI SRE”正式归类为产品类别
传统云原生已关注安全和 SRE，但现在需面对模型权重、数据集、向量库、Agent 工作流等新资产。AI Native 平台工程需同时回答：
- 代码和依赖是否安全
- 模型和数据是否可信
- Agent 行为是否可控
这将推动 Policy-as-Code、MCP、Graph 权限系统与 AI 深度集成。
关键变化五：开源参与从“加分项”变成“门槛”
大会访谈中，平台工程负责人普遍提到：
- 招聘更看重候选人在 Kubernetes / 相关项目的上游贡献
- 参与开源显著缩短 ramp up 时间
- AI Native 新项目（Model Runtime、Agent Runtime、Scheduler）也走开源路线
个人职业发展角度，参与 AI Native 相关开源项目将成为平台工程和 AI Infra 角色的基本要求，而不只是“简历加分项”。
云原生的“下半场”轮廓
下表压缩展示了“下半场”各方向的技术焦点与本质差异。
该表总结了 AI Native 平台工程的关键坐标。
| 方向 | 技术焦点 | 与上半场的本质差异 |
|---|---|---|
| AI Native 平台 | Model/Agent 一等公民，统一抽象与治理 | 对象从服务转向模型和推理 |
| 资源调度 | DRA、异构算力、拓扑感知、功耗与成本 | 从静态配额转向动态、策略驱动 |
| 运行时 | 容器 + WASM + Nix + Agent Runtime | 从“进程容器化”到“执行图容器化” |
| 平台工程 | IDP + AI SRE + 安全 + 成本 + 合规 | 从工具拼盘转向“自治平台” |
| 安全与供应链 | LLM 依赖、模型权重、数据集、向量库的全链路治理 | 守护对象从镜像扩大为“所有 AI 工程资产” |
| 开源与生态 | AI Infra / Model Runtime / Agent Runtime 上游协作 | 不只是“用开源”，而是“在开源里造未来” |
总结
过去十年，云原生完成了从容器编排到平台工程 1.0 的演化。以 KubeCon NA 2025 为节点，行业系统性地将 AI 引入云原生技术与组织栈：
- Kubernetes 不再只是“跑微服务的基础设施”，而是“AI 工作负载的运行时”
- Platform Engineering 不再只是“整合工具”，而是“为模型和 Agent 提供自治平台”
- 安全、SRE、运行时、调度、网络，都将在 AI 驱动下重构
对我而言，过去十年关注“如何让应用在云原生世界里更稳”，未来十年则聚焦“如何让 AI 在云原生世界里更好、更安全、更可控”。这就是我眼中，云原生“下半场”的开场哨。