Kata Containers 是一个开源的安全容器运行时，其做法是把每个容器或 Kubernetes 的 Pod 放进一台轻量级虚拟机里运行，让工作负载拥有独立的内核，从而获得虚拟机级别的隔离，同时保持接近普通容器的启动速度和资源效率。它兼容开放容器计划(OCI)标准与 Kubernetes 的容器运行时接口(CRI)，可以像普通容器运行时一样接入 Docker、containerd、CRI-O 等容器管理层，不必改写应用[1]。该项目由英特尔 Clear Containers 与 Hyper 的 runV 合并而来，2017 年 12 月在 OpenStack 基金会下发布。
定义
Kata Containers 是一套开源的容器运行时实现，它把容器进程包裹在轻量级虚拟机内部执行，使每个工作负载运行在自己独立的客户机内核上，而不是与宿主机及其他容器共用同一个内核[2]。它的目标是在保留容器使用方式与性能特征的同时，补上传统容器在隔离强度上的短板。
该运行时遵循 OCI 容器格式规范，并实现了 Kubernetes 的容器运行时接口，因此对上层编排系统而言与普通运行时没有区别[1]。在 Kubernetes 中，用户只需在 Pod 清单里指定对应的 runtimeClass，调度、镜像、存储、探针等既有用法基本保持不变[3]。
原理
传统容器运行时 runc 依靠 Linux 内核的命名空间和 cgroups 实现隔离，所有容器共享同一个内核，一旦内核出现可被利用的漏洞，容器边界就可能被突破[4]。Kata Containers 改用硬件虚拟化作为隔离手段：每启动一个容器或 Pod，它就创建一台精简的虚拟机，容器进程在这台虚拟机内部的内核上运行[5]。
其执行路径大致为：容器引擎把请求交给 Kata 的 shim 组件，由 shim 启动虚拟机监视器，创建带有独立客户机内核的 Pod 虚拟机；虚拟机内部运行的 Kata 代理负责创建和管理容器进程；Pod 被删除时，shim 关闭虚拟机并把资源归还给宿主机[3]。Kata 支持多种虚拟机监视器后端，包括 QEMU、Cloud Hypervisor 与 Firecracker，不同后端在攻击面和启动速度上有所差异。
网络方面，Kata 用 Traffic Control 的重定向规则把宿主机上的 veth 接口与虚拟机内部的 tap 接口对接，从而让 CNI 或 CNM 网络插件照常工作。存储方面，块设备型驱动可通过 virtio-scsi 直接挂载底层块设备以获得更好的 I/O 性能，非块设备场景则使用 virtio-fs 共享文件系统。
发展历程
Kata Containers 的前身之一是英特尔 2015 年推出的 Clear Containers 项目，它借助英特尔虚拟化技术把容器当作轻量级虚拟机启动，用于缓解共享内核带来的安全问题；另一个前身是 Hyper 的 runV，属于基于虚拟机管理程序的 OCI 运行时实现，强调对不同 CPU 架构和虚拟化环境的支持。
2017 年 12 月 5 日，OpenStack 基金会在 KubeCon 北美峰会上宣布两个项目合并为 Kata Containers，由基金会托管，代码以 Apache 2 许可发布。发布时项目包含代理、运行时、代理转发、shim、内核与 QEMU 2.9 等组件，有约 20 家公司参与支持[6]。
此后社区逐步扩展了对 AMD64、ARM、IBM p 系列与 z 系列等架构的支持，并接入 containerd 等项目。2023 年发布的 3.0 版本对架构做了重写，随后的 3.4、3.5 版本趋于稳定，并成为机密容器(Confidential Containers)方向的底层支撑之一[2]。4.0 版本改为以 Rust 编写的运行时作为默认实现，以提升内存安全性与性能[7]。
应用
在公有云与托管 Kubernetes 服务中，Kata Containers 常被用于实现 Pod 级沙箱。微软在 Azure Kubernetes 服务中推出 Pod Sandboxing 功能，把每个沙箱 Pod 放进带独立客户机内核的 Pod 虚拟机，用户只需在清单中加入 runtimeClassName 一行配置即可切换运行时[8]。腾讯云容器服务也在原生节点上提供 Kata 运行时，用于多租户隔离、运行不可信代码以及智能体沙箱等场景[9]。
典型使用场景包括：在同一集群上承载不同租户的工作负载并提供各自的计算隔离边界；隔离不可信工作负载而继续复用共享集群容量；通过为每台 Pod 虚拟机设置 CPU 与内存请求和限制，减少资源密集型工作负载对其他 Pod 的影响[3]。
在人工智能领域，Kata Containers 被用作智能体运行环境的隔离底座。Kubernetes SIG Apps 下的 Agent Sandbox 项目将其列为受支持的后端之一，与 gVisor 并列供用户按需选择。蚂蚁集团将该运行时用于离线计算、核心在线服务以及智能体基础设施等场景[7]。
局限
Kata Containers 用虚拟机管理程序、客户机内核与代理通信协议替换了直接暴露给攻击者的宿主机内核，攻击面总量小于完整 Linux 内核，但并不为零。QEMU 是使用最广的后端，其 virtio-net、virtio-blk、virtio-9p 等设备模拟在过去数年间均出现过漏洞；代理与 shim 之间的通信协议也曾出现过可被利用的问题[2]。
隔离带来的开销体现在启动时间与内存占用上。截至 2024 年的测试数据显示，QEMU 后端启动通常在 1 至 3 秒，Cloud Hypervisor 为 0.5 至 1.5 秒，Firecracker 为 0.3 至 1 秒，而 runc 为 100 至 300 毫秒；每台 Pod 虚拟机还会为内核与代理额外占用约 20 至 50 MB 内存[2]。对长时间运行的服务影响有限，但对按请求创建 Pod 的无服务器类负载影响明显。
功能兼容性也存在边界。由于容器运行在独立虚拟机中，宿主机网络、宿主机 IPC、宿主机 PID 命名空间以及特权模式等 Kubernetes 字段不被支持[9]。Pod 虚拟机提供的只是计算隔离，并不隔离控制平面、存储与数据路径，也不限制具备集群管理员权限者的操作，因此单靠它无法实现完整的多租户硬隔离[3]。此外，该方案本身只提供高隔离的容器基础设施，端到端的沙箱方案仍需使用者自行搭建。
参见
-
runc —— 基于命名空间与 cgroups 的传统 OCI 运行时，是 Kata Containers 在隔离强度上的对照对象
-
Kubernetes —— 容器编排系统，通过容器运行时接口调用 Kata Containers
-
containerd —— 容器运行时管理器，可将请求转发给 Kata 的 shim
-
gVisor —— 另一类通过用户态内核实现隔离的安全容器方案
-
Firecracker —— 面向无服务器与容器负载的轻量虚拟机监视器，可作为 Kata 的后端
-
机密容器 —— 以 Kata 为基础、保护使用中数据的技术方向
参考资料
- Learn About the Kata Containers Project [引用日期2026-10-14]
- Kata Containers Security Review: Micro-VM Isolation for Pods [引用日期2026-10-14]
- concepts-pod-sandboxing [引用日期2026-10-14]
- What is Kata Containers and why should I care? | Ubuntu [引用日期2026-10-14]
- Kata Containers [引用日期2026-10-14]
- OpenStack基金会携手Intel、Hyper发布开源Kata Containers项目 [引用日期2026-10-14]
- opensourceforu.com 上的网页 [引用日期2026-10-14]
- Kata Containers [引用日期2026-10-14]
- 容器服务 安全容器_腾讯云 [引用日期2026-10-14]