摘要:沙箱技术的引入,为容器提供了更强的隔离性和安全性,成为云原生技术的重要组成部分。
本文来源《华为云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 模型相比,有以下优点:
-
sandbox 管理逻辑清晰:sandbox 管理逻辑和 container 管理逻辑完全分开,开发友好,语义清晰
-
简化 container API 调用链:取消 Task API 到 Shim v2 API 的转化,链路简化, Pod 启动速度加快
-
高效的 sandboxer 进程:
-
Sandboxer 进程常驻减掉了冷启动 Shim 进程的耗时,Pod 启动速度加快
-
1:N 管理模型减少了进程数量,节省大量内存
-
Rust 程序内存安全,相比 Golang 内存开销小
-
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