简介：袋鼠与 Kata 将会碰撞出什么样的火花？
文 / 云原生 SIG（Special Interest Group）一、Kata 的过来让咱们将时钟拨回 2015 年 5 月，Hyper.sh 和 Intel 开源技术核心的工程师们分别独立公布了 runV 和 Clear Containers 的虚拟化容器我的项目，而这两个我的项目便是 Kata Containers1 的前身。这两个我的项目相互有很多交换，在分别独立倒退了两年半之后，于 2017 年底合并成了 Kata Containers 我的项目，并把这个我的项目捐给 Openstack 基金会治理，这也是 Openstack 基金会的第一个 Pilot 我的项目。在 2019 的 4 月，Kata Containers 被 Openstack 基金会认可为其第二个顶级我的项目，在这之前的十多年里，Openstack 基金会都只有 Openstack 一个顶级我的项目。Kata Containers 平安容器的诞生解决了许多一般容器场景无奈解决的问题：1. 多租户平安保障。云原生多租户场景下，平安容器能够避免歹意租户对 host 内核的间接攻打并大幅缩小机器上其余租户的危险，从而让私有云服务变得更稳固。2. 不同 SLO 混部容器混合部署。平安容器的强隔离性缩小了容器之间的性能影响，使得不同 SLO 优先级实例混部有了更稳固的技术计划，对延时敏感的在线业务用 runC 解决方案，大数据类对资源诉求比拟高且有显著峰谷差别的离线业务用平安容器解决方案，避免离线业务突发流量影响到在线业务，通过在线离线业务同时混部进一步缩小计算资源的节约和老本耗费。3. 可信 & 不可信容器混合部署。可信代码运行在 runC 容器中，不可信代码运行在平安容器中，两者在同一台宿主机上混部，升高不可信容器产生危害的可能性。在这些劣势的根底上，平安容器在虚拟化上谋求极致的轻薄，从而让整体资源耗费和弹性能力靠近 runC 容器计划，以此达到 Secure as VM、Fast as Container 的技术指标。二、Kata 的倒退在 2018 年 5 月 Kata 1.x 阶段，Kata 和 containerd 社区独特制订了 shimv2 接口标准，并率先在 Kata Containers 反对了该标准。18 年 11 月，通过 containerd-shim-v2 和 vsock 技术，Kata 精简了大量的组件，配合轻量级 hypervisor 和精简内核，kata 能够大幅升高内存开销和容器启动工夫。更要害的是，升高零碎部署复杂度还大幅提高了稳定性，特地是在零碎重载状况下的稳定性。
（图 1 /Kata 1.x 架构图）2019 年的时候，Kata 从 1.x 降级到了 2.x , 有了十分重要的技术提高。Kata-agent 应用 Rust 进行了重构，极大水平缩小了内存开销以及整体攻击面。通过 2.x 版本，Kata 从最开始的做架构、用开源组件搭建原型的疾速成长路线，逐步有了名气，走向了影响上游社区技术迭代的成熟路线。而 Kata 的整体架构在 2.x 版本中已趋势成熟，后续倒退须要开始对专用组件进行思考和优化，从而以部分影响整体来实现 Kata 能力的再次晋升，例如 2.x 中用 Rust 改写 Kata agent 升高内存开销便是一个很好的例子。而在 Kata 迅速倒退的这几年间，阿里云外部有一个名为“袋鼠”的团队始终在基于 Kata 打造云原生场景下的秘密武器。三、袋鼠云原生底层零碎为了解决因为云原生带来的高密、高并发等技术难题，阿里云外部用多年的工夫锻炼了一套袋鼠云原生底层零碎。袋鼠中的平安容器解决方案便是基于 Kata Containers 我的项目打造，并将其向更极致的方向深度优化，袋鼠做的优化诸如应用 Rust 重写了 Kata Container 2.0 的 go runtime 来进一步升高容器运行时的内存开销，并且为 Kata Container 专门开发了一个针对容器场景深度优化的轻量级虚拟机管理器 Dragonball，通过容器运行时以及虚拟机一体的设计将 Kata 的整体体验带上了新的高度。那么袋鼠平安容器都能提供什么样的能力呢？简略来说便是极致的高密和弹性。袋鼠平安容器能够在 6 秒之内弹出 3000 个平安容器，同时在一台机器上能够运行超过 4000 个以上的平安容器。通过袋鼠，咱们胜利撑持了阿里云的函数计算 FC 业务每日近 120 亿调用量，弹性容器实例 ECI 业务每日最高超百万的创立量，通过极致的性能体现大幅减少业务的外围竞争力。在极致性能之外，咱们也通过应用平安容器进行混部，从而节俭了大量资源老本。袋鼠在外部获得的问题与 Kata 社区的倒退非亲非故，因此袋鼠也决定将其多年来外部打磨的零碎回馈到 Kata 社区，独特推动 Kata 社区的进一步倒退。四、Kata 3.0：袋鼠与 Kata 的一场碰撞在云原生场景下，业界对容器启动速度、资源耗费、稳定性的要求越来越高，而这些也是平安容器绝对一般容器会面临的挑战。仿若多年前 runV 和 Clear Containers 的交互诞生了 Kata Containers 这个顶级我的项目，多年之后的明天袋鼠与 Kata 之间彼此碰撞，袋鼠会将其基于 Kata 社区历经线上生产环境考验的外部零碎开源到 Kata 社区，助力 Kata 社区架构降级至 3.0 版本，让 Kata 整体的应用体验、资源耗费、启动速度、稳定性都失去晋升。总结而言，在 Kata 3.0 版本中，咱们将新减少了以下设计：为了缩小简单的流程来和不同 VMM 适配，取得开箱即用的平安容器体验，咱们提供了内置基于容器场景深度优化的 Dragonball 沙箱。Dragonball 将提供 Kata 平安容器生态下的虚拟化最优解。（当然，Kata 3.0 的可扩大架构也反对用户通过配置选项应用其余 VMM，做出符合实际需要的决策。）为了实现高性能、低资源利用、内存平安，以及高并发的指标，咱们实现了 Async Rust Runtime 的新技术。为了反对不同 Service、Runtime 和 Hypervisor，以及减少秘密容器的相干反对，为 Wasm 等将来方向留下空间，咱们在 Runtime 内提供了可扩大框架来实现这一指标。为了容器和沙箱资源生命周期对立管理机制，咱们提供了 Resource Manager 机制来实现这一指标。在本文的后续局部，咱们会对 Kata 3.0 的重点更新进行开展。五、设计介绍
（图 2 /Kata3.0 架构图）5.1 内置 VMM DragonballDragonball 沙箱是针对 Kata 量身打造的一个基于 KVM 的轻量级 VMM，除了反对惯例的 hypervisor 的性能以外，还针对容器工作负载做了一些优化：基于 Nydus2 开源我的项目的容器镜像治理和镜像减速服务可扩大高性能的虚构设施驱动低 CPU 内存开销单 VM 疾速启动工夫，多 VM 疾速并发启动速度为什么须要内置 VMM？
（图 3 /Kata2.x 版本 Runtime 与 VMM 架构示意图）如图所示，在 Kata2.x 之前 Runtime 和 VMM 是独立的过程。Runtime 过程会 fork VMM 过程并通过 RPC 进行交互。通常，过程之间的交互比过程内的交互会耗费更多的资源，从而会导致绝对较低的效率。同时还要思考资源运维老本，例如，在异常情况下进行资源回收时，任何过程的异样都必须被其余组件检测到，并激活相应的资源回收过程。如果有额定的过程存在，复原变得更加艰难。并且，不同版本的 Kata 还须要思考和不同版本的 VMM 的适配问题，可能 VMM 版本的落后或降级都会导致 Kata 适配上呈现问题，须要用户破费额定的精力来做版本和配置上的调整。最初，即便平安容器曾经成为了业界多 SLO 混部 / 私有云多租户问题的规范解决方案，当初仍没有任何一款 VMM 是定位于反对平安容器生态的。其余 VMM 都有各自不同畛域的定位，例如 QEMU 能力全面但代码已早早超过百万行，整体启动速度与耗费资源都偏大；Firecracker 尽管做到了极致轻薄但许多虚拟化能力都为了轻薄而做了减法，无奈撑起平安容器复杂多变的场景需要。多过程交互问题、运维简单问题、VMM 版本适配问题、平安容器虚拟化缺位问题，都指向了一个独特的答案——咱们须要一个专一于平安容器场景的 VMM 来提供平安容器生态下的虚拟化最优解。Dragonball VMM 便是带着这个使命而来的，在 Kata3.0 里，咱们将提出一个内置于 Kata 生态的 Dragonball VMM，将来将与 Kata 独特成长，以解决上文提到的这些历史问题。后续咱们也会有专项文章对 Dragonball 进行介绍，敬请期待。如何反对内置 VMM？咱们提供了 Dragonball 沙箱，通过将 VMM 的性能集成到 Rust 库中来启用内置的 VMM。咱们能够通过应用该库来执行与 VMM 相干的性能。因为 Runtime 和 VMM 在同一个过程中，所以在音讯处理速度和 API 同步方面具备劣势。同时还能够保障 Runtime 和 VMM 生命周期的一致性，缩小资源回收和异样解决保护，如图 4：
（图 4 /Kata3.0 内置 VMM 示意图）5.2 可扩大框架 Rust 版本的 kata-runtime 为 Service、Runtime 和 Hypervisor 提供了可扩大框架，还包含了针对不同场景的配置逻辑。在 API 层面，Service 提供了插件注册的机制来反对多种容器相干的原生服务。除了对容器过程进行治理的 task service, 后续还会减少 image 服务，以及能够反对运维监控的其余服务。反对不同类型的 Runtime。包含基于虚拟化技术的 VirtContainer，基于可信计算硬件的秘密容器。前面还会依据 kata 社区和行业需要思考反对 WasmContainer 以及 LinuxContainer。对于 VirtContainer 反对的 Hypervisor，除了内置的 Dragonball, 也能够插件式的去配置 Dragonball、Qemu、Acrn 以及 Firecracker。
5.3 资源管理在咱们的案例中，会有各种资源，每个资源都有相应的子类型。特地是对于 Virt-Container，每个子类型的资源都有不同的操作。并且可能存在依赖关系，例如 share-fs rootfs 和 share-fs volume 将应用 share-fs 资源将文件共享到 VM。目前，network 和 share-fs 被视为沙箱资源，而 rootfs、volume 和 cgroup 被视为容器资源。因而，咱们为每个资源形象了一个公共接口，并应用子类操作来对应不同子类型之间的差别。
5.4 Rust Async Runtime 绝对于 Go 语言，Rust 在性能和资源耗费方面更胜一筹，在某些特定的场景下效率甚至优于 C++。同时，Rust 还能防止空指针，野指针，内存泄露，内存越界等一些列内存平安问题, 从而大幅缩小了程序解体的频率，这些能力对于 Kata 这种偏底层的零碎尤为重要。然而，Go 语言的劣势在于内置的机制和库来反对编写并发程序，比方 goroutine，以此显著升高 CPU 和内存开销，尤其是对于具备大量 I/O 密集型工作的工作负载。咱们为了既兼顾 Go 语言的并发和异步劣势，又取得 Rust 的安全性和低开销特点，开发了 Async Rust Runtime。如何反对 Async？kata-runtime 由 TOKIO_RUNTIME_WORKER_THREADS 管制运行 OS 线程，默认为 2 个线程。对于 TTRPC 和容器相干线程对立运行在 tokio 线程中，相干依赖须要切换到 Async，比方 Timer、File、Netlink 等。借助 Async 咱们能够轻松反对 non-block io 和计时器。目前，咱们仅将 Async 用于 kata-runtime。内置的 VMM 保留了 OS 线程, 这样能够确保线程是可控的。六、何为开箱即用？让咱们将注意力拉回到本文的题目——开箱即用的平安容器体验。通过上文的介绍，咱们提到的“开箱即用”也应该在读者的心中逐步清晰，在此咱们对这个概念做以下总结：通过提供内置于 Kata Runtime 的 Dragonball VMM 让平安容器整体生态的底层基础设施实现闭环，提供可扩大 Rust Runtime 来反对诸如秘密容器等不同平安容器状态。从此之后，用户无需再做简单的适配工作，只需下载 Kata、编译 Kata 即可运行 Kata，所有都将变得如此简略和易用。这样开箱即用的体验，无论是对于初入 Kata 想疾速上手的小白，还是商用 Kata 的工程师团队，都会带来易用性、可维护性、稳定性等多方面的晋升飞跃，任何技术的倒退肯定是向更纯正、更精简的方向后退，因此咱们也深信这会是 Kata 平安容器生态将来的方向。七、将来瞻望 7.1 Kata 3.0 开发路线目前，Kata 3.0 还处于第一阶段的开发，第一阶段将会实现 Kata 基本功能的实现。残余的性能将会在第二和第三阶段陆续反对，预计在 2022-07-25 会有 Kata 3.0 的第一个 alpha 版本，欢送各位参加到 Kata 3.0 的建设以及试用 3.0 版本。
ClassSub-ClassDevelopment Stageservicetask service 阶段 1extend service 阶段 3image service 阶段 3runtime handlerVirt-Container 阶段 1Wasm-Container 阶段 3Linux-Container 阶段 3EndpointVeth Endpoint 阶段 1Physical Endpoint 阶段 2Tap Endpoint 阶段 2Tuntap Endpoint 阶段 2IPVlan Endpoint 阶段 3MacVlan Endpoint 阶段 3MacVtap Endpoint 阶段 3VhostUserEndpoint 阶段 3Network Interworking ModelTc filter 阶段 1Route 阶段 1MacVtap 阶段 3Storagevirtiofs 阶段 1nydus 阶段 2hypervisorDragonball 阶段 1Qemu 阶段 2Acrn 阶段 3CloudHypervisor 阶段 3Firecracker 阶段 3 7.2 Kata 3.0 公布工夫预计 2022-07-25 在 main 分支有可用的 alpha 版本，在此之前可先在开发分支 runtime-rs 应用 Kata 3.0。Kata 3.0 后续布局的公布工夫与版本迭代停顿咱们也在此同步给各位。欢送继续关注龙蜥社区公众号及龙蜥云原生 SIG，也欢送感兴趣的小伙伴参加共建。2022-07-25pre-release 3.0.0-alpha02022-08-15pre-release 3.0.0-alpha12022-08-29pre-release 3.0.0-alpha22022-09-12pre-release 3.0.0-rc02022-09-26pre-release 3.0.0-rc12022-10-10release 3.0.0 龙蜥云原生 SIG 在龙蜥云原生的首次 SIG 会议上，咱们的架构师具体介绍了 Kata 3.0 原型 RunD 的技术架构，视频回放已上线至龙龙蜥社区官网（或点击浏览原文中转）和 B 站，欢送对 Kata 3.0 想理解更多的小伙伴点击以下链接观看：官网：https://openanolis.cn/video/B 站：https://www.bilibili.com/vide… 同时，云原生 SIG 将整合龙蜥社区的云原生劣势能力，输入开箱即用的龙蜥云原生发行版，联合用户需要输入大数据、混部等场景的解决方案，帮助用户能更快更好应用云原生技术构建利用集群。Kata 作为龙蜥云原生的我的项目之一，将来也将独特构建基于平安容器的云原生服务。后续 Kata 的能力咱们会通过龙蜥社区云原生 SIG 上在整个云原生生态的视角上进行反对，欢送感兴趣的同学们扫码退出龙蜥社区云原生 SIG 群（二维码见下），一起共建云原生生态。相干链接：[1] Kata Containers 我的项目链接：https://github.com/kata-conta…[2] Nydus 我的项目链接：https://github.com/dragonflyo… —— 完 ——退出龙蜥社群 退出微信群：增加社区助理 - 龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；退出钉钉群：扫描下方钉钉群二维码。欢送开发者 / 用户退出龙蜥社区（OpenAnolis）交换，独特推动龙蜥社区的倒退，一起打造一个沉闷的、衰弱的开源操作系统生态！
对于龙蜥社区龙蜥社区（OpenAnolis）由企事业单位、高等院校、科研单位、非营利性组织、集体等在被迫、平等、开源、合作的根底上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、凋谢的 Linux 上游发行版社区及翻新平台。龙蜥社区成立的短期指标是开发龙蜥操作系统 (Anolis OS) 作为 CentOS 停服后的应答计划，构建一个兼容国内 Linux 支流厂商的社区发行版。中长期指标是摸索打造一个面向未来的操作系统，建设对立的开源操作系统生态，孵化翻新开源我的项目，凋敝开源生态。目前，Anolis OS 8.6 已公布，更多龙蜥自研个性，反对 X86_64、RISC-V、Arm64、LoongArch 架构，欠缺适配 Intel、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密反对。欢送下载：https://openanolis.cn/download 退出咱们，一起打造面向未来的开源操作系统！https://openanolis.cn 原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。