• 打破“云原生过时论”：针对 Agent 带来的单例有状态、冷启动敏感与高并发下执行不可信代码的挑战，云原生并未退场，而是在 Kubernetes、CNCF、Cilium 等主流项目中自下而上进行了一场深刻的“接口级地基重做”；

• K8s 调度与资源分配革命：调度单元从单个 Pod 升维为协同作业的 Workload（Gang Scheduling/CompositePodGroup），动态资源分配（DRA）正式成为跨厂商 GPU 标准抽象，结合 In-Place Resize 与缩容到零（Scale to Zero）解决空闲 Agent 算力浪费；

• 沙箱运行时双线突围：SIG Apps 推进基于强隔离（gVisor/Kata）的通用 Agent Sandbox 原语，而 Google 9 月开源的 AX 与 Agent Substrate 则将调度移出热路径，通过 Actor 多路复用与快照实现秒级挂起与唤醒；

• 流量层从 Header 走向 Payload：Ingress NGINX 彻底退役，全面押注 Gateway API；AI Gateway 工作组主导请求体深度处理（Prompt 注入防护、MCP 路由），llm-d 落地前缀缓存感知与预填充/解码分离；

• 安全与可观测性闭环：Cilium 1.20 补齐基于 FQDN 与二进制进程的精准网络策略防护，OpenTelemetry 升级 MCP 与 GenAI 语义约定，为 Agent 编排构筑可审计的证据链，全栈重新收敛于开放标准。

“云原生过时了”，这个说法是怎么来的

先把“过时论”摆出来，它有三个依据：

• Agent 不像微服务。它有状态、忽闲忽忙、要执行不可信代码，Pod 这套抽象看上去不合身。

• Kubernetes 太重。集群、镜像仓库、CRD 的运维负担，让不少开发者望而却步。

• 新一代运行时开始绕开 K8s。Agent Substrate 明确把 Kubernetes 控制面从热路径里拿掉。

这些批评有道理。但同一时期，一些主流项目的官方博客给出的事实却是：

• Kubernetes v1.37（代号 Garhwal）2026 年 8 月 26 日发布，据 PerfectScale 统计共 67 项增强，其中 16 项 Stable、23 项 Beta、27 项 Alpha，1 项 deprecation/removal。

• Cilium 1.20 的发布说明写明：2,660 多个提交，1,100 多位贡献者。

• OpenTelemetry 在 2026 年 5 月 21 日由 CNCF 宣布毕业。

• Kubernetes AI Conformance 认证平台从 18 个增长到 31 个，并把 Agent 工作负载纳入验证。

• Ingress NGINX 在 2026 年 3 月停止维护。据 Kubernetes 指导委员会引用的数据，约一半云原生环境依赖它，社区仍然选择果断退役。

• ……

而且，连“绕开 K8s”的 Substrate 也没有离开 K8s：它依然把 Kubernetes 当作基础设施供给层，并以补丁方式对齐上游的 Pod 证书能力。

所以本文的结论是：过时论说对了一半。Agent 确实暴露了旧抽象的不足，但答案不是抛弃云原生，而是在云原生的地基上改造接口、加建楼层。

全景图：Agent 时代的“地基”有几层

我们把这两年云原生生态里的典型项目压缩成一张分层图，后文每一节对应图里的一层。

图片

Kubernetes：调度与资源这一层，被重写得最彻底

五个版本速览

调度对象从 Pod 变成 Workload

AI 训练和分布式推理有个共同点：一组 Pod 要么一起跑，要么都别跑。传统调度器逐个 Pod 决策，容易出现“占着资源却凑不齐一组”的死锁。

Kubernetes 的回答是工作负载感知调度（Workload-Aware Scheduling，WAS）：

图片

v1.37 最值得关注的是 CompositePodGroup：把 PodGroup 组织成树，支持多层拓扑约束、Gang Scheduling 与抢占策略，官方点名了 JobSet 和 LeaderWorkerSet 这类结构。

要提醒的是：v1.36 曾把 v1alpha1 整体替换为 v1alpha2，v1.37 又引入 v1alpha3，并带来 disruptionMode字段的破坏性变更。KEP-4671 里标注的 Stable 目标是 v1.38，这只是社区目标。想用在生产里，先在预发环境验证。

DRA：GPU 时代的标准设备抽象

Dynamic Resource Allocation（DRA）在 v1.34 GA，v1.37 补上几块关键拼图：

• Extended Resource 支持 GA：example.com/gpu 这类传统写法可以由 DRA 驱动满足，不必再并存 Device Plugin，存量工作负载不改就能渐进迁移。

• 设备污点与容忍 GA：可以给过热或待维护的 GPU 打污点，NoSchedule 阻止新调度，NoExecute 驱逐已在使用的 Pod。

• 标准 NUMA 节点属性：不同厂商的设备可以在同一 NUMA 节点上对比。

• PodGroup 共享 ResourceClaim（Beta）：避免一组 Pod 各自生成一堆 Claim。

弹性与隔离：为“长期驻留、忽闲忽忙”的 Agent 铺路

• In-Place Pod Resize 在 v1.35 GA，v1.37 又开始做“为原地扩容腾资源的抢占”（Alpha）；

• “HPA 缩容到零”在 v1.37 进入 Beta；

• “用户命名空间”在 v1.36 GA，容器内 root 不再等于宿主机 root；

• Memory QoS 在 v1.37 进入 Beta 且默认开启；

• 清单式准入控制让“删不掉的准入策略”成为可能，适合平台方强制安全底线；

• Pod Certificates 与 Cluster Trust Bundles 为工作负载身份打底。

一次断舍离：Ingress NGINX 退役

2025 年 11 月 11 日社区宣布退役，2026 年 1 月 29 日指导委员会再发联合声明，3 月停止维护，官方同步发布 Ingress2Gateway 1.0 帮助迁移。社区用一次痛苦的退役，把流量入口的标准明确压在了 Gateway API 上。Gateway API 也在持续发力：v1.5（2026 年 4 月）推进多项特性到 Stable，v1.6（2026 年 8 月）让 TCPRoute 与 UDPRoute 进入 Standard。后文所有 AI 网关能力，都长在这块地基上。

Google AX 与 Agent Substrate：最激进的一次“重做”

为什么 Pod 不够用

Kubernetes 官博《Running Agents on Kubernetes with Agent Sandbox》把趋势概括为 “AI v2 eating AI v1”：从短命的无状态调用，走向持续运行的多 Agent 协作。Agent 有三个特点，传统原语都难以应付：

1. 单例且有状态：需要持久身份和一个安全的“草稿区”来执行 LLM 生成的不可信代码；

2. 大部分时间空闲，偶尔爆发：需要挂起与快速恢复；

3. 对启动延迟敏感：新起一个 Pod 大约多出一秒开销，Agent 被唤醒时，这一秒足以打断交互的连贯感。

用 StatefulSet 加 Headless Service 再加 PVC 也能拼出来，但官方的评价很直白：规模一大就是运维噩梦。

路线一：Agent Sandbox（在 Pod 抽象内改进）

Agent Sandbox 是 SIG Apps 下开发中的子项目，核心是 Sandbox CRD：

• 强隔离：原生支持 gVisor、Kata Containers；

• 生命周期管理：空闲时缩到零，恢复后接着干；

• 稳定身份：稳定的主机名和网络身份，便于多 Agent 互相发现。

扩展层有三个 CRD：SandboxTemplate（模板）、SandboxClaim（按需申请）、SandboxWarmPool（预热池，压低冷启动）。2025 年 11 月 KubeCon 北美大会上，Google 也宣布了 GKE Agent Sandbox 的技术预览。

图片

路线二：Agent Substrate 与 AX（把控制面挪出热路径）

GKE 官方文档给出的判断是：标准 Kubernetes 把每个 Agent 绑定到独立 Pod，受制于调度吞吐和 Pod 启动延迟；Kubernetes 也不支持 Pod 休眠，数百万空闲 Agent 常驻会耗尽 Pod 上限和控制面内存。

Substrate 的做法是：把大量“Actor”（Agent）多路复用到少量就绪的“Worker”（Pod）上。Agent 空闲时，系统给它的内存和本地文件打快照，需要时在不到一秒内恢复到某个可用沙箱里。

图片

而 AX 则是 Substrate 之上的、Kubernetes 风格的声明式编排层，Apache 2.0 许可，定义了四个原语：

用法上很像 kubectl：

ax apply -f task.yaml    # 注册清单
ax watch                 # 实时查看任务阶段与状态变化
ax ssh <task>            # 进入沙箱调试
ax suspend <task>        # 手动挂起
ax resume <task>         # 恢复1.2.3.4.5.

一个耐人寻味的细节：Substrate 仓库里带有一个 Pod 证书签发控制器，仓库自述是一个“补丁式”实现，提供的签发能力将来会由上游 Kubernetes 内置。这恰好对应 v1.37 的 Pod Certificates。也就是说，最激进的 Agent 运行时，也在向上游标准靠拢，而不是另起炉灶。

最有力的反对意见，我们怎么看

• Hacker News 上的讨论出现分化：基础设施工程师赞赏它解决了“空闲 Agent 烧钱”的问题，也有开发者批评“人体工学”的宣传与 Kubernetes 集群、镜像仓库、CRD 的运维负担不符。

• 联合创作者 Jaana Dogan 在 HN 上强调，AX 更接近作业编排，不是 Agent 框架。

• AX 的 Go 文档标注仍处于活跃早期开发阶段，Substrate 仓库 README 也声明不是 Google 官方支持的产品；目前部署文档面向 GKE Standard 集群。

这些批评确实说明，Kubernetes 不是 Agent 的唯一答案，但没有削弱一个事实：多数团队今天的算力、网络、安全、可观测和身份体系都长在云原生上，绕开它的成本很高。所以更准确的说法是：Agent 时代的地基不是被推倒，而是被拆开重新分层。

流量层：从看 Header 到看 Payload

传统网关根据 Header 路由；AI 请求的关键信息在 Body 里：哪个模型、什么优先级、Prompt 是否安全。

1. 2025 年 6 月：Gateway API Inference Extension 发布，借助 Envoy 的 ext-proc，把支持 Gateway API 的网关升级为推理网关。项目自述已 GA。

2. 2026 年 3 月：SIG Network 成立 AI Gateway 工作组，方向是给 Gateway API 增加面向 AI 的声明式能力，两个核心提案：

• Payload Processing（载荷处理）：声明式地处理请求与响应的完整 Body，用于提示注入防护、内容过滤、语义路由、缓存与 RAG 集成；要求处理器有确定的执行顺序和可配置的失败模式，并明确提到要处理 MCP 请求。

• Egress（出站）：面向 OpenAI、Vertex AI、Bedrock 等外部模型提供方的出站路由。

1. Agent 网关：由 Solo.io 创建、现属 Linux Foundation 的 agentgateway（Rust 编写）覆盖 MCP、A2A 与 LLM 路由，2026 年 5 月从 kgateway 中拆分为独立项目。kagent（2025 年 5 月进入 CNCF Sandbox）则用 CRD 声明 Agent、模型配置和 MCP 工具。

2. 推理层：llm-d 于 2026 年 3 月 24 日进入 CNCF Sandbox，由 Red Hat、Google Cloud、IBM Research、CoreWeave、NVIDIA 等发起，基于 vLLM 与 Inference Extension，做 Prefill/Decode 分离与前缀缓存感知路由。Google 在博客里披露，这类路由把 Vertex AI 的前缀缓存命中率从 35% 提升到 70%。

CNCF：用“合同”把生态拧在一起

Kubernetes AI Conformance（2025 年 11 月启动）要求平台先通过标准 Kubernetes 一致性认证，再额外满足 AI 相关要求。2026 年 3 月的更新有几个信号：

• 认证平台从 18 个增至 31 个；

• 新增 KAR（Kubernetes AI Requirements），对齐 v1.35 的技术原语，明确要求稳定的 In-Place Resize 与工作负载感知调度；

• 验证范围扩展到 Agent 工作负载，并在制定解耦推理、LLM 流量路由、DRA 网络的标准；

• 路线图：自动化一致性测试，以及包含沙箱和数据隐私要求的主权 AI 标准。

CNCF 在 2026 年 3 月的博客《The great migration》里提出三时代叙事：微服务、数据与训练推理、以 2025 年为起点的 Agent 时代。

CNCF 的 AI Tech Radar 还给出一个数据：41% 的 AI 开发者自认为是云原生开发者。协议层的治理也日渐明朗：MCP 由 Linux Foundation 下的 Agentic AI Foundation 托管，A2A 同样归属 Linux Foundation。

Cilium：网络与运行时安全的“横切层”

Cilium 1.20（2026 年 9 月）在 CNCF 博客上有两条主线与 Agent 时代直接相关：

• Gateway API 成为更完整的流量管理层：支持 ExternalAuth（GEP-1494）、TCPRoute/UDPRoute，并跟进 Gateway API v1.6.1；

• 网络策略走向标准化：支持上游 ClusterNetworkPolicy，含 Admin 与 Baseline 两级，并让 Hubble 对审计判决做策略关联。

此外还有可扩展数据面（Datapath 插件，云厂商不必 fork）、ENI IPAM 支持 IPv6（Beta）、ztunnel 仍为 Beta、旧的 Mutual Authentication 被标记为废弃、cilium-cni 二进制缩小 80%。

Isovalent 官博里，2026 年 2 月的《From Hyperscalers to Neoclouds》梳理了 18 家以上把 Cilium 作为默认 CNI 的云厂商，包括 CoreWeave 和 OVHcloud；2026 年 9 月 23 日的《Tetragon Network Policy》则宣布 Tetragon 可以按二进制匹配、用 FQDN 书写网络策略。

OpenTelemetry：从“三支柱”到“Agent 调用树”

OpenTelemetry 这两年同时做两件事：夯实底座，追赶 Agent。

底座方面：2026 年 5 月毕业；声明式配置稳定；Profiles 进入公开 Alpha；OBI（eBPF 自动插桩，源自 Grafana Beyla 的捐赠）持续推进；Kubernetes attributes processor 在 2026 年 9 月发布 v1.0.0。与之呼应，Kubernetes v1.37 把原生直方图推进到 Beta 并默认开启。

Agent 方面：

• 官博 2025 年有《AI Agent Observability》，2026 年有《Inside the LLM Call》；

• 语义约定 v1.42.0（2026 年 6 月 12 日）把 GenAI、提供方专属约定与 MCP 约定拆到独立仓库 semantic-conventions-genai，以便更快迭代；

• 约定已覆盖推理、嵌入、检索、记忆操作与工具执行，Agent 与 MCP 都是一等公民；

• 但整体仍标注为 Development，截至 2026 年 8 月 21 日尚无正式发布版本。

这意味着：现在按 gen_ai.* 插桩是对的，但要预期属性名还会变。

一次 Agent 请求，怎样走完整条链路

图片

一句话：网关管入口，Sandbox/Substrate 管运行，DRA 与调度管资源，Cilium 管边界，OTel 管证据。这五件事，都发生在云原生的地盘里。而汉荣下一代云原生统一管理平台正是这么一直坚持的技术路线。

回到标题：谁说云原生过时了

五个判断

1. 分层，而不是替换。Kubernetes 核心保持通用，Agent 特有需求由 CRD、子项目和上层系统（Sandbox、Substrate、AX）承接。

2. 调度单元在升级。Pod → Workload/PodGroup → Actor。

3. 网关的关注点从 Header 走向 Payload。

4. 标准先行。AI Conformance 是 CNCF 用“合同”约束生态的方式。

5. 可观测性是 Agent 的“证据链”，但标准尚未定型。

风险清单

• 工作负载感知调度：v1.36 到 v1.37 API 版本连续变更，勿直接上生产；

• AI Gateway 提案未见已合并的 CRD，agentgateway 仍是 v1alpha1；

• AX 处于早期开发，Substrate 目前面向 GKE Standard；

• OTel GenAI 约定仍是 Development；

• Ingress NGINX 的教训：关键组件依赖少数维护者，本身就是风险

白明的赞赏账户