Kubernetes 1.36深度解析：云原生正式拥抱AI Agent时代

ハル（Haru）：春天的版本，转型的信号

Kubernetes 1.36版本代号"ハル"（Haru，日语"春天"），于2026年4月正式发布。但这个版本的重要性远超版本号的递增——它是Kubernetes从"容器编排平台"向"AI工作负载原生平台"转型的标志性节点。

三个GA（正式发布）特性和一个全新项目共同构成了这幅图景：

User Namespaces GA — 容器安全的最后一块拼图
Fine-Grained Kubelet API Authorization GA — 零信任架构的基石
SELinux Volume Label Changes GA — 存储安全的彻底解决
Agent Sandbox — 全新项目，专为AI Agent设计的隔离运行环境

User Namespaces：为什么安全专家等了这么久？

User Namespaces是Linux内核的一个特性，允许容器内的root用户映射到宿主机上的非特权用户。这听起来简单，但在Kubernetes的语境下实现它耗费了超过4年的工程努力。

技术挑战

1
2
3
4
5
6
7
传统容器安全模型：
  容器内 root (UID 0) ──映射──→ 宿主机 root (UID 0)
  ⚠️ 容器逃逸 = 宿主机root权限

User Namespaces模型：
  容器内 root (UID 0) ──映射──→ 宿主机 nobody (UID 65534)
  ✅ 容器逃逸 = 宿主机无权限用户

为什么在Kubernetes中实现如此困难？因为Kubernetes的存储系统（PersistentVolume）、网络插件（CNI）、和运行时（CRI）都需要适配UID映射。一个组件的疏忽就可能导致权限泄漏或功能破坏。

对AI工作负载的特殊意义

AI训练和推理工作负载通常需要：

访问GPU设备文件（需要特权）
挂载大型数据集（需要存储权限）
运行自定义CUDA内核（需要特定的系统调用）

User Namespaces GA意味着这些工作负载终于可以在最小权限下安全运行，而不需要privileged: true这个安全噩梦。

Agent Sandbox：Kubernetes的AI原生时刻

这是1.36版本最具前瞻性的新增项目。Agent Sandbox不是一个Kubernetes核心特性，而是一个官方支持的项目，旨在为AI Agent提供安全的运行环境。

为什么AI Agent需要沙箱？

AI Agent（如OpenAI Codex、GitHub Copilot Agent）与传统微服务有根本性的区别：

特性	传统微服务	AI Agent
行为可预测性	高	低（LLM输出不确定）
资源使用模式	稳定	突发且不可预测
外部交互	受限API	可能调用任意工具
执行时长	毫秒级	分钟到小时级
安全边界	明确	模糊（代码执行、文件访问）

传统的Kubernetes安全模型（RBAC + NetworkPolicy + PodSecurityPolicy）不足以应对AI Agent的安全需求，原因是：

代码执行：Agent可能生成并执行任意代码
动态资源需求：Agent可能在运行中请求额外的GPU或内存
工具调用链：Agent可能通过一系列工具调用间接获得不预期的权限

Agent Sandbox的架构

Agent Sandbox采用了多层隔离架构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────┐
│  Agent Sandbox Controller               │
│  ┌──────────────────────────────────┐   │
│  │  gVisor/Firecracker microVM      │   │
│  │  ┌───────────────────────────┐   │   │
│  │  │  Agent Runtime            │   │   │
│  │  │  ┌────────┐ ┌──────────┐ │   │   │
│  │  │  │ LLM    │ │ Tool     │ │   │   │
│  │  │  │ Client │ │ Executor │ │   │   │
│  │  │  └────────┘ └──────────┘ │   │   │
│  │  │  ┌────────────────────┐  │   │   │
│  │  │  │ Filesystem Overlay │  │   │   │
│  │  │  └────────────────────┘  │   │   │
│  │  └───────────────────────────┘   │   │
│  │  Network: egress-only + allowlist│   │
│  └──────────────────────────────────┘   │
│  Resource Limits: CPU/Mem/GPU/Time      │
│  Audit: Full action logging             │
└─────────────────────────────────────────┘

关键设计决策：

双层隔离：gVisor提供系统调用过滤，Firecracker提供硬件级隔离
Filesystem Overlay：Agent只能看到预定义的文件集，修改写入临时层
Network Allowlist：出站网络仅允许访问白名单中的API端点
时间限制：Agent执行有硬性时间上限，防止失控

Gateway API v1.5与Ingress2Gateway 1.0

另一个值得关注的进展是Gateway API v1.5的多项特性稳定化，以及Ingress2Gateway 1.0的发布。

Gateway API正在取代传统的Ingress资源，成为Kubernetes流量管理的标准。对于AI应用而言，这意味着：

gRPC原生支持：AI推理服务大量使用gRPC，Gateway API的原生支持简化了部署
流量分割：支持按权重将流量路由到不同模型版本（A/B测试、金丝雀部署）
跨命名空间引用：允许共享的AI网关服务跨多个团队的命名空间

Ingress2Gateway 1.0则提供了从旧Ingress配置自动迁移的工具——这对于正在AI化改造的企业来说，降低了迁移成本。

GitHub的eBPF实践：部署安全的新范式

GitHub最近分享了他们如何使用eBPF来提升部署安全性。eBPF（extended Berkeley Packet Filter）允许在Linux内核中运行沙箱化的程序，提供了前所未有的系统可观测性。

GitHub的用例特别有启发性：他们在自己的基础设施上部署代码变更时，使用eBPF来：

监控系统调用模式的异常变化
检测新部署代码的网络行为偏差
在不影响性能的情况下记录审计日志

这与Agent Sandbox的设计理念不谋而合：不是阻止所有行为，而是监控和约束行为在预期范围内。

观点与预判

Kubernetes 1.36是云原生平台从"微服务优先"到"AI工作负载优先"转型的里程碑。

我的具体预判：

2026下半年：主要云厂商将推出基于Agent Sandbox的托管服务
2027年：Agent Sandbox将成为企业部署AI Agent的事实标准
Gateway API将在2027年底前全面取代Ingress

对于平台工程师的实际建议：

立即开始User Namespaces的迁移测试
评估Agent Sandbox是否适合你的AI Agent部署场景
开始使用Ingress2Gateway进行流量管理的现代化

Kubernetes的进化不再只是关于"如何更好地运行容器"——而是关于"如何安全地运行不可预测的智能体"。这是一个根本性的思维转变。

参考链接：

Jiayun's Blog