本文来源《华为云DTSE》第五期开源专刊，作者：华为云云原生开源团队研发工程师。

近年来，云原生容器技术飞速发展，随着企业数字化转型，容器技术在安全性和隔离性上的不足促使沙箱技术的发展。为了解决了单一沙箱无法满足多样化需求和运维压力大的问题，华为云推出了 Kuasar 多沙箱容器项目，整合了多种沙箱技术，显著提升了性能和资源利用效率，推动了云原生技术的发展。

1. 容器运行时技术发展

2013 年，Docker 的出现标志着容器技术的突破性进展，开启了容器时代的序幕。Docker 的成功不仅在于其创新性的容器打包和发布方式，更在于其基于 Linux 内核的命名空间（Namespace）和控制组（Cgroup）功能的运用，实现了容器进程之间的资源隔离和限制。

命名空间允许容器中的进程看到的文件系统、网络、进程等资源与主机或其他容器中的进程完全隔离，使得容器内部的环境与主机环境相对独立，确保了容器之间的隔离性。而控制组则可以对容器中的资源进行限制和管理，如 CPU、内存、网络带宽等，保证了各个容器在资源使用上的公平性和稳定性。

在容器时代，容器就是一等公民。其简单易用的容器打包和发布方式，以及强大的生态系统，使得 Docker 迅速成为了业界标准，被广泛应用于软件开发、测试和部署。

2014 年后，随着 Kubernetes 的崛起，容器编排领域的格局发生翻天覆地的变化。Kubernetes 作为主流的容器编排工具，不仅为容器的部署、调度和管理提供了强大的支持，还引入了一种全新的概念——Pod。Pod 作为 Kubernetes 中的基本调度单元，不仅包含一个或多个容器，还共享其网络命名空间、存储卷等资源，实现了容器之间的紧密协作和通信。

Containerd 作为一个用于管理容器生命周期的核心组件，自从 2019 年从云原生计算基金会（CNCF）毕业后，已经成为 Kubernetes 中首选的容器运行时之一。

2．企业云原生容器化上云面临的挑战

随着企业数字化转型的深入，企业业务愈益关注云上创新和精益运营，“深度云化”对云原生技术提出了更高的要求。原生的 docker 技术尽管具有高性能和快速启动的优势，但其隔离性和安全性容易受到内核漏洞的影响，不能满足企业对安全性、隔离性的更高要求。为此，业界引入了多种新的“沙箱”容器隔离技术。沙箱技术的核心思想是通过增强隔离机制，提供安全、高效的运行环境，使得应用在多租户环境中更加可靠地运行。

在实际的生产落地过程中，应用云原生的沙箱技术面临诸多挑战：

各类云原生场景对沙箱提出了更高的要求：不同类型的沙箱技术在安全性、性能和资源利用等方面有着各自的优势和适用场景，企业需要在安全隔离、极速低噪、标准通用等多个方面都能得到满足。因此，单一沙箱通常难以完全满足所有需求，不同的业务场景可能需要不同类型的沙箱技术，多沙箱是容器技术发展的必然趋势。

支持多类沙箱带来运维压力显著上升：当前业界沙箱技术对接容器运行时的实现缺乏统一的开发框架，导致关键日志、重要事件、沙箱管理逻辑等方面存在差异。这使得引入新的沙箱技术并进行运维和管理成为一项挑战，运维人员需要同时掌握多种沙箱技术的运行原理、监控方法和故障排除策略，增加了工作的复杂度和难度。

为解决这一问题，有必要寻求一种更加统一和标准化的沙箱技术管理框架。这种框架应该支持多种类型的沙箱技术，并提供统一的管理接口和工具，允许运维人员通过统一的界面进行监控、管理和维护。同时还应具有较高灵活性，能够根据不同的业务需求选择合适的沙箱技术，并能够随着技术的发展和变化进行扩展和升级。

3. 探索多沙箱容器

3.1 新一等公民——沙箱

沙箱的形态天然满足对 Pod 的要求，它为容器组提供了一个隔离的环境，不同的容器组之间具有更强的安全隔离性。目前，业界主要的沙箱技术包括：

基于轻量级虚拟化技术的 microVM 沙箱：如 AWS Firecracker 和 Kata Containers，这类技术通过引入轻量级虚拟机，将容器封装在微虚拟机中，既保留了虚拟机的强隔离性，又提供了接近容器的启动速度和资源开销。microVM 沙箱在安全性和性能之间找到了一个较好的平衡点, 适合安全性和兼容性要求高的场景。

基于进程级虚拟化的 App Kernel 沙箱：如 gVisor、QuarkContainer,这种技术通过在应用层面进行虚拟化，实现了更细粒度的资源控制和隔离。App Kernel 沙箱能够提供比传统容器更高的隔离性，适用快速资源收缩和安全性要求高的场景。

新兴的 WebAssembly 沙箱：如 wasmtime, wasmer 和 wasmEdge。WebAssembly（Wasm）是一种基于字节码的虚拟机技术，最初用于浏览器内的高性能应用执行，近年来被引入到云原生领域，成为一种新的沙箱技术。WebAssembly 沙箱具备跨平台、高性能、轻量级等优点，能够在不同操作系统和硬件环境中一致地运行，适合像函数计算这种轻量任务的场景。

2023 年 3 月，容器运行时 containerd 在 v1.7.0 版本中引入了 Sandbox API 特性。2024 年，即将发布的 containerd 2.0 版本将这一 API 趋于稳定。

Sandbox API 定义了一套用于 Sandbox 生命周期管理的接口，包括创建、启动、停止、等待、删除、监控等功能，它将容器和沙箱的概念解耦，容器归容器，沙箱归沙箱，Pod 就是沙箱，沙箱成为容器世界新的一等公民。

3.2 冗余的 Pause 容器

为了兼容 Kubernetes 中 Pod 这一概念，Docker 引入了 pause 容器，它不包含任何用户进程，只是简单地运行一个无限循环的命令，以保持容器不退出。pause 容器的存在，使得 Docker 能够更好地模拟 Kubernetes 中的 Pod 的行为，实现容器之间的共享命名空间和其他资源。在 Docker 中，为了区分 pause 容器和用户容器，通常需要进行一些冗余和复杂的判断逻辑，这使得代码的开发和阅读变得困难。

与 Docker 一样，Containerd 在运行 Pod 时也需要借助 pause 容器。具体来说，当 Kubernetes 创建一个 Pod 时，实际上是在 Containerd 中创建了一个包含多个容器的任务（Task）。每个容器共享 pause 容器所创建的网络命名空间等资源。尽管 pause 容器在 Kubernetes 中的角色至关重要，它实现了 Pod 中容器间共享资源的关键功能，但与之相关的复杂性和理解难度也不容忽视。

有了 Sandbox 的概念后，Sandbox 可作为一个 Pod 载体，创建 Pod 不再创建 pause 容器，进而可以减少容器创建的工作，加快容器启动。

3.3 管理面资源瘦身

在目前沙箱容器的解决方案中，为了引入沙箱容器，运行时管理面程序做了很多“非容器”的工作，以 Kata-containers 2.0 为例，其管理面模型如下：

containerd 每创建一个 Pod，就要创建一个对应的 Shim 进程（Golang 语言开发）用于 Pod 的管理，Shim 进程再去创建虚机、pause 容器和业务容器，在这种场景下，管理面 Shim 进程和 Pod 的数量关系为 1:1。同时，创建 VM 和创建容器这两种不同的概念共用了同一套 TaskAPI，中间经过多层 API 的转换，过程复杂且效率低。

有了前面提到的 SandboxAPI，和对 pause 容器的探索，结合目前的沙箱容器现状，我们可以探索一个支持多种主流沙箱技术的容器运行时。

3.4 华为云多沙箱容器运行时 Kuasar

2023 年 4 月在 KubeCon + CloudNativeCon Europe 上，华为云联合中国农业银行以及 openEuler 社区、WasmEdge 社区和 Quark Containers 社区联合发起了 CNCF 首个多沙箱容器运行时项目—— Kuasar。

Kuasar 基于 Rust 语言实现，可以创建 MicroVM/App Kernel/WebAssembly /Runc 类型的沙箱容器，融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，已收获 1200 多个 GitHub Star 和 80 个 Fork，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用。

Kuasar 当前的模型和目前容器运行时的 Shim v2 模型相比，有以下优点：

1. sandbox 管理逻辑清晰：sandbox 管理逻辑和 container 管理逻辑完全分开，开发友好，语义清晰

2. 简化 container API 调用链：取消 Task API 到 Shim v2 API 的转化，链路简化，Pod 启动速度加快

3. 高效的 sandboxer 进程

4. Sandboxer 进程常驻减掉了冷启动 Shim 进程的耗时，Pod 启动速度加快

5. 1:N 管理模型减少了进程数量，节省大量内存

6. Rust 程序内存安全，相比 Golang 内存开销小

7. pause 容器去除：创建 Pod 不再创建 pause 容器，不再需要准备 pause 容器镜像快照，Pod 启动速度加快

性能测试结果如下：

端到端容器启动时间：包含 microVM 的启动时间

单个 Pod 启动时间

并行50个 Pod 启动时间

测试结果表明，Kuasar 具有 2 倍的启动速度，一方面是 Sandbox API 的实现，使得创建容器不再单独创建 pause 容器，节省了准备 pause 容器镜像快照的时间；另一方面得益于 1:N 的管理模型，Sandboxer 进程常驻，从而节省了冷启动 Shim 进程的时间，容器的启动速度大大提升。

管理面的内存消耗：对比 Kuasar 的 Sandboxer 进程和 Kata 的 Shim v2 进程的 PSS 内存（Proportional Set Size）。

测试结果表明，Kuasar 空载的 Sandboxer 进程 PSS 为 7MB 左右，创建 50 个 Pod 需要消耗将近 900 MB 内存，节省近 99%的内存，其背后的原因也可分为两点：主要是 1:N 的管理模型使得 N 个进程减少为 1 个进程，带来的内存收益与 Pod 数成正比；其次，Kuasar 采用了 Rust 编程语言，相比于 Kata Shim 进程使用的 Golang 语言，没有 runtime 运行时，且内存安全，语言本身也会带来一些内存收益。

综上，Kuasar 的性能表现是相当强悍的，在测试场景下相较于 Kata-containers 具有 2 倍的容器启动速度和 99%的管理面内存消耗下降。

4．结语

云原生技术的发展，使得容器化技术在企业数字化转型中扮演着越来越重要的角色。而沙箱技术的引入，为容器提供了更强的隔离性和安全性，成为云原生技术的重要组成部分。

Kuasar 在南向沙箱方面已支持基于轻量级虚拟化技术的安全容器沙箱（Cloud Hypervisor、Qemu、StratoVirt），基于新兴的 WebAssembly 沙箱（WasmEdge、Wasmtime），基于进程级虚拟化的 App Kernel 沙箱（Quark）以及基于内核的原生普通容器（runC）；而在北向引擎方面，Kuasar 已与 Containerd 联合构建最新的沙箱接口标准，并共同推动该标准在 Containerd v2.0 版本的完整实现。此外，轻量级容器引擎 iSulad 项目也已经完成与 Kuasar 项目的深度集成，支持在 openEuler 23.09 创新版本上一键部署。

面向未来，Kuasar 将持续探索云原生容器运行时领域技术创新，在企业数字化、云原生转型过程中发挥作用，让基于 Kuasar 的多沙箱容器运行时方案融入更广泛的云原生技术生态。

Kuasar 官网：http://www.kuasar.io

Github 地址：https://github.com/kuasar-io/kuasar

华为开发者空间，汇聚鸿蒙、昇腾、鲲鹏、GaussDB、欧拉等各项根技术的开发资源及工具致力于为每位开发者提供一台云主机、一套开发工具及云上存储空间，让开发者基于华为根生态创新。点击链接，免费领取您的专属云主机