Google Cloud在2026年10月7日宣布，GKE Sandbox的microVM沙箱类型正式商用，适用于运行1.37.0-gke.4713000及更新版本的集群。这项能力针对执行未受信代码、AI智能体运行时和多租户应用的隔离需求。
与通过用户态内核拦截系统调用的gVisor不同，microVM为每个Pod提供单独的轻量虚拟机和完整Linux内核。正式商用不代表可直接替换所有普通Pod，节点虚拟化能力、设备支持和资源开销仍是选型前提。
每个Pod获得独立的微虚拟机边界
GKE使用Kata Containers和Cloud Hypervisor创建microVM。每个沙箱Pod运行在自己的客户机内核中，与宿主节点及其他Pod形成硬件虚拟化边界。对于执行第三方代码或不可预知脚本的服务，这比仅依赖容器运行时隔离多了一层防护。
官方同时指出，沙箱用于降低容器逃逸影响，并不能替代对数据库、API、存储驱动等外部依赖的访问控制。能够被沙箱内代码访问的外部服务仍需单独设防。
版本门槛与节点条件不能忽略
Google把microVM正式商用的门槛标为GKE 1.37.0-gke.4713000及以后版本。运行它的节点必须支持并启用嵌套虚拟化，机器类型也要符合该能力的要求；节点镜像可以选择Container-Optimized OS或Ubuntu。
在GKE Standard集群中，默认节点池不能启用GKE Sandbox，集群还必须保留至少一个非沙箱节点池及一个节点来承载系统服务。应用Pod通过相应RuntimeClass请求microVM，团队应先核对集群模式、节点池与调度配置。
完整Linux内核带来兼容性也带来成本
microVM适合需要完整Linux内核功能的工作负载。Google的对照表给出的每Pod固定开销为约250 mCPU与130 MiB内存，启动时间约一至两秒；这与gVisor低基础内存、较快启动的取舍不同。
不要把这些产品级参考值当成自己的压测结果。对高密度短任务或延迟敏感服务，应在目标机型上评估Pod启动、内存占用与单节点可容纳数量，再决定是否大规模迁移。
GPU、TPU与主机网络仍有限制
官方明确microVM沙箱不支持GPU和TPU；需要这些加速器的工作负载应另行评估gVisor或其他隔离方案。microVM中的特权容器只获得客户机系统内的root权限，不等于获得宿主节点权限。
使用hostNetwork: true的microVM Pod不能访问Pod外部资源，依赖主机网络的应用不宜原样迁入。网络诊断工具也只能看到连接到微虚拟机的网络接口，运维验收要按这种边界设计。
上线前验证调度、权限与外部依赖
先选择支持嵌套虚拟化的节点并验证RuntimeClass调度，再测试业务所需系统调用、卷、网络和外部服务连通性。Google建议为沙箱容器设置资源限制，防止异常负载挤占节点资源。
若使用GKE Workload Identity Federation，还应按官方说明阻断不必要的元数据访问。验收标准是沙箱Pod确实落在预期节点、业务功能正常、敏感外部接口仍受最小权限约束，而不仅是Pod显示Running。
