解读Kuasar多沙箱容器技术，带来更强隔离性和安全性

摘要：沙箱技术的引入，为容器提供了更强的隔离性和安全性，成为云原生技术的重要组成部分。

本文来源《华为云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%的管理面内存消耗下降。

结语

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

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

点击关注，第一时间了解华为云新鲜技术~