Kubernetes 上 AI 代理沙箱的 5 个关键层
内容提要
在Kubernetes上运行AI代理生成的代码存在安全风险：代理会执行未经人工审查的代码，可能利用内核漏洞危及共享节点，因此工作负载隔离成为平台的基本需求。文章比较了runc、gVisor和Kata Containers三种运行时在安全与性能之间的权衡，介绍了通过RuntimeClass让代理Pod选用隔离运行时，并提及Agent Sandbox项目可标准化有状态的单Pod环境，支持模板、声明和预热池。
延伸解读
隔离运行时：安全与性能的权衡
文章对比了 runc、gVisor 和 Kata Containers 三种运行时。runc 性能最好但共享主机内核，隔离最弱；gVisor 通过用户态内核限制系统调用接口，启动快、密度高，但只实现 Linux 子集，可能限制代理行为；Kata 为每个 Pod 提供独立虚拟机内核，隔离最强，但带来启动开销和内存成本，且需维护客户机镜像，内核 CVE 需修补两个内核。选择取决于对隔离强度和兼容性的要求。
RuntimeClass：按需选择隔离级别
RuntimeClass 让集群管理员定义可用的隔离运行时及其开销，Pod 通过 runtimeClassName 字段选择。这样代理工作负载可以选用更隔离的运行时，而不影响其他非代理工作负载。文章提醒，额外隔离会增加资源消耗和 Pod 就绪时间，应将实测开销写入 RuntimeClass 的 overhead 字段，以便调度器和资源配额正确计算，而不是照搬示例值。
沙箱的边界：策略同样重要
沙箱保护的是主机免受代理侵害，但无法阻止代理对其有权访问的资源造成破坏。文章指出，沙箱内的代码仍可能删除可写仓库、读取已挂载的密钥，或向网络允许的任何地方发送数据。因此，沙箱策略与沙箱本身同样重要，例如通过网络策略限制通信。平台团队在部署隔离运行时的同时，需配套制定访问控制和网络策略。
Agent Sandbox：标准化有状态环境
代理工作常呈突发性：运行代码后可能等待数分钟甚至数小时。保持虚拟机运行会占用容量，销毁则需重建。Agent Sandbox 项目由 Kubernetes SIG Apps 拥有，其 Sandbox API 标准化了有状态单 Pod 环境，提供稳定身份和持久存储，并支持模板、声明和预热池等扩展。它保持运行时无关，将隔离交给所选的 RuntimeClass，使代理环境更易管理和复用。
Q&A
为什么在Kubernetes上运行AI代理生成的代码需要工作负载隔离？
AI代理会执行未经人工审查的代码，可能利用内核漏洞危及共享节点，因此工作负载隔离成为平台的基本需求。
runc、gVisor和Kata Containers在安全与性能上如何权衡？
runc性能最高但共享主机内核；gVisor通过用户空间内核限制系统调用接口，启动快、密度高，但可能约束代理行为；Kata Containers提供完整VM隔离，每个Pod运行轻量VM，有VM启动和内存开销，但兼容性最好。
如何让特定的代理Pod使用隔离运行时？
通过RuntimeClass资源定义运行时，并在Pod的spec中设置runtimeClassName字段（如kata或gvisor），不设置则使用默认runc。
Agent Sandbox项目解决了什么问题？
Agent Sandbox项目标准化了有状态的单Pod环境，提供稳定身份和持久存储，并支持模板、声明和预热池，同时保持运行时无关，隔离由所选RuntimeClass负责。
沙箱能防止代理删除仓库或泄露密钥吗？
不能。沙箱保护主机免受代理影响，但无法阻止代理删除可写仓库、读取挂载的密钥或通过网络发送数据，因此沙箱策略（如NetworkPolicy）同样重要。
使用gVisor或Kata Containers时，节点需要哪些额外配置？
gVisor需要节点安装并集成到containerd；Kata需要裸金属或支持嵌套虚拟化的节点，配置Kata运行时shim、VMM、KVM及包含kata-agent的客户机镜像，并维护该镜像。
