共计 5557 个字符，预计需要花费 14 分钟才能阅读完成。
随着云计算和容器技术的一直倒退，容器引擎和容器运行时曾经成为了云原生时代的基石，它们负责了容器生命周期的治理以及容器运行过程中环境的创立和资源的配置。openEuler 社区基于容器引擎我的项目 iSulad[1]在解决容器运行效率、安全性以及隔离性等问题上进行着一直地尝试与摸索。
华为云在 2023 年 4 月 21 日阿姆斯特丹的 Kubecon+CloudNativeCon Europe 2023 云原生峰会上公布了多沙箱运行时 Kuasar[2]，将 Kubernetes CRI(https://github.com/kubernetes/cri-api) 规范中的 Pod 语义精确地映射到了 Kuasar 的 Sandbox 语义。与此同时，iSulad 容器团队与华为云 Kuasar 严密单干，率先反对了 Kuasar 的 Sandbox 语义，实现了从 Kubernetes 到 iSulad 容器引擎到 Kuasar 对立容器运行时的全栈买通。通过 iSulad 和 Kuasar 我的项目，对立了容器运行时应答不同容器隔离技术的 Kubernetes 生态场景，简化了单节点上多种容器（或沙箱）状态的对立部署。相比于 Containerd + Kata-Containers 的运行时组合，iSulad + Kuasar 「不仅能够反对多种容器隔离技术，而且使容器运行时治理组件的内存耗费缩小了 99%，并行启动工夫缩短了 40% 以上！」
背景与现状
从容器编排组件 Kubernetes 的视角来看，可能解决 CRI(Container Runtime Interface)申请的服务端都是容器运行时(Container Runtime)。事实上，容器运行时还能够再细分为两个档次，即容器引擎和底层容器运行时。
容器引擎 (Container Engine) 次要负责容器运行环境的创立、容器资源的配置和容器生命周期的治理，北向接管来自于 Kubernetes 或前端命令行的输出，南向则调用底层容器运行时 (Low Level Container Runtime) 来实现最终容器环境的生成和容器生命周期的操作。
在业界，容器引擎和容器运行时的术语常常被交替应用。「在本文的语义中，容器运行时特指底层容器运行时」。除了 iSulad 以外，以后的容器引擎还包含 Containerd，Docker 等，底层容器运行时包含 runc，Kata-Containers 等。
这些容器引擎和容器运行时因为一些历史起因始终存在着不少遗留问题。这些问题次要是因为容器引擎和容器运行时没有妥善处理 CRI 中的 Pod 语义而引起的。下图以 MicroVM 为例，简略介绍了一些容器引擎和容器运行时中的次要问题。
1. Pod 语义缺失
Kubernetes 的 CRI 标准强化了 Pod Sandbox 的概念，将 Pod 作为容器编排调度的最小单元。Pod 是一个或多个容器的组合，他们共享一些命名空间和资源，沙箱 (Sandbox) 则通过容器隔离技术为这一组容器提供平安隔离的运行环境。然而，Pod 的语义在容器引擎和容器运行时的层面并没有很好的体现进去，这导致这些组件在架构上的不合理，同时也减少了实现的复杂度，带来了很多保护上的问题，比方 shim 过程的治理和保护，IO 通道的保护等等。
2. Shim 过程的冗余
在通过 shim v2 规范创立 Pod 的过程中，每创立一个新 Pod 都须要启动一个 shim 过程对 Pod 及其资源进行治理。由此而带来的问题有以下三点：
- 内存资源的耗费：shim 过程耗费了大量内存资源。通过测试，在 Containerd + Kata 的组合中，每减少一个 Pod，因为 shim 过程引起的管理层组件的内存耗费就减少了约 18MB。
- 启动工夫的缩短：因为 shim 过程的存在，容器生命周期治理的调用链变长，减少了启动工夫，耗费了更多的 CPU 资源。
- 可靠性问题的减少：在大规模商用实际中，可靠性问题困扰着不少容器商用团队，这些问题不仅影响了业务失常发展，而且难以定位和解决。shim 过程的存在带来了大量的相似问题，比方状态不统一、数据流卡死、过程残留等，大大增加了容器的保护老本。
3. Pause 容器的冗余
因为历史起因，晚期的通用容器是通过 Linux 的 namespace + cgroups 实现资源隔离与资源限度的。Pause 容器就是晚期的容器状态为了应答 CRI 中 Pod 语义而创立的非凡容器。这个容器的作用就是依据配置创立命名空间、限度共享资源。除此之外，Pause 容器不执行任何理论工作但却会耗费一些 CPU 工夫和内存资源，同时因为 Pause 容器的存在也减少了零碎被攻打的攻击面，会带来一些潜在的平安危险。事实上，对于以后的一些容器隔离技术来说，Pause 容器是能够打消的。比如说虚拟化隔离技术，虚拟机自身就曾经具备了足够的安全性与隔离性，不须要 Pause 容器帮助配置命名空间和共享资源。
4. 容器运行时隔离技术繁多
容器隔离技术是推动容器运行时疾速倒退的次要能源之一。以后支流的容器隔离技术有以下几种：
- Linux 容器隔离技术：Linux 容器次要采纳 namespace + cgroups 的形式实现隔离，其次要特点是高性能、低开销。LXC 是比拟晚期的隔离技术，起初因为其安全性和可移植性的问题，逐步被 libcontainer 取代，但其隔离性始终较差，例如 runc 容器。
- 轻量级虚拟化容器隔离技术：MicroVM 是一种基于虚拟化的容器隔离技术，它应用了轻量级的虚拟化技术来实现容器的隔离，具备了传统虚拟机的强隔离性和安全性，但带来的效率问题也颇为显著，比方 QEMU，Stratovirt 等。
- 用户态内核隔离技术：用户态内核是将原来运行在内核态的大部分内核性能运行在用户态，通过对业务过程零碎调用的代理实现零碎调用的平安隔离。相比于虚拟化，用户态内核更加轻量化、性能更好，但因为仍旧处于晚期倒退阶段，其稳定性、可靠性和兼容性存在不少问题，比方 gVisor，Quark 等。
- 语言虚拟机隔离技术：语言虚拟机隔离技术实质上是将底层字节码通过专用的语言虚拟机来加载运行，从而达到隔离的目标。Wasm 虚拟机就是语言虚机的一种。该类型语言虚拟机隔离技术利用与平台无关的零碎接口（WASI），使 Wasm 程序可能拜访到系统资源。Wasm 沙箱具备冷启动速度快、资源开销小的有点，但目前的应用束缚较多，反对的语言也无限，成熟度不高，目前还有很多尚未解决的隔离、通用性和语言生态问题。
不同状态的容器隔离技术在性能、安全性以及通用性上都有各自的优劣，当下大部分容器运行时都只反对繁多容器隔离技术，无奈很好地施展不同隔离技术的劣势。因而在单节点部署多状态沙箱的老本与复杂度都会比拟高。
iSulad+Kuasar：新一代对立容器运行时解决方案
为了解决上述的这些痛点问题，openEuler 社区联结华为云推出了新一代对立容器运行时的解决方案，指标是让容器引擎和容器运行时更加优雅正当地解决由 shim v2 规范对 Pod 生命周期及其资源管理而引起的问题。
在容器隔离技术欣欣向荣的明天，业界对于将 Sandbox 语义引入容器引擎和容器运行时的思考与探讨始终在继续进行。事实上，Containerd 社区早就开始了对 Sandbox 语义引入的探讨，Sandbox API[3]也于 2020 年 3 月被提出，2022 年 4 月正式被合入了 Containerd 社区。
尽管 Sandbox API 的合入使 Containerd 外部对于 Pod 语义的解决更加清晰，但并不可能解决上述其余与 shim 相干的问题。iSulad 和 Kuasar 我的项目对于 Sandbox API 更深层次的翻新为解决这些问题带来了可能性。在新的解决方案中，iSulad 作为容器引擎将 Sandbox API 的调用延长进来，通过 RPC 让作为容器运行时的 Kuasar 来治理 Pod。与原有的基于 shim v2 的计划不同，新的计划不须要为每个 Pod 都创立一个 shim 过程。在新的架构中，同一类型的容器只须要应用同一个过程来治理。例如，上图中的 MicroVM Sandboxer 就是用于治理轻量级虚拟机的过程。iSulad 通过 Sandbox API 与 MicronVM Sandboxer 进行交互，用于治理所有该类型的 Pod 的生命周期。同时，每当新的 Pod 被创立后，Pod 中的 Task Service 的地址就会通过 Sandbox API 返回给 iSulad，iSulad 便可通过 shim v2 接口与 Pod 中的 Task Service 进行交互，治理 Pod 中的容器。
这个新的解决方案完满地解决了容器引擎与容器运行时之间遗留已久的痛点问题：
- 「Sandbox 的语义被带入了容器引擎和容器运行时」，在语义层面与 CRI 保持一致，加强了在云原生架构上的连贯性。
- Kuasar 用一个 Sandboxer 过程取代了 shim v2 中的多个 shim 过程，解决了由 shim 过程带来的多个问题：
- 「Sandboxer 削减了 shim 过程的冗余，大大减小了因为 shim 过程带来的资源开销。依据测试在 50 个 Pod 的场景下，Kuasar 在治理面的开销只有 shim V2 的 1%。」
- 「容器的创立不须要通过 shim 过程代理，iSulad 间接将容器生命周期治理的申请发送给 Task Service，从而使启动工夫缩短了 40% 以上。」
- 「打消了 shim 过程当前，各种状态不统一、数据流卡死、过程残留等可靠性问题都会随之有所改善。」
- 在新的架构中，Pod 是通过 Sandbox API 创立，不用遵循 OCI 规范流程，从而 「打消了 Pause 容器的冗余。」
- 新的解决方案 「反对在繁多节点上通过配置运行多种不同类型的沙箱，利用不同的隔离技术，在性能、安全性及通用性等各方面造成优势互补」。
iSulad
作为用 C/C++ 编写而成的容器引擎，iSulad 的内存底噪仅为 Containerd 的 50%，其轻、灵、快的特点使其可能在包含云原生、嵌入式等多种场景下部署应用。
在新的解决方案中，iSulad 在结构上也针对 Pod 的解决进行了翻新与调整：
- 北向接口：与原有应用 Container 的语义解决 Pod 治理申请的形式不同，iSulad 将 Sandbox 的语义引入了架构和实现当中，针对 Pod 与 Container 进行了语义上的辨别，不仅更好地反对了 CRI 以及命令行对于 Pod 的申请，而且也为后续容器状态的多样性提供了更大的拓展空间。
- 南向接口：iSulad 将 Sandbox API 延长进来，通过 Sandbox API 为不同的容器状态提供对立接口，实现归一化治理，同时也对容器运行时 Kuasar 提供了更为清晰、精准的调用申请。
用户能够通过 iSulad 的 dev-sandbox 分支[4]，体验 iSulad+Kuasar 的最新版本，具体可参见用户指南[5]。
iSulad 社区将在将来对新一代容器运行时的演进中，继续与 Kuasar 社区放弃深刻单干，独特扩充多沙箱容器技术在业界的影响力。
Kuasar
Kuasar[6]作为新一代的容器运行时，不再采纳通过 shim v2 接口来治理 Pod，取而代之的是 Kuasar 向容器引擎提供的新一代容器运行时 Pod 治理接口 Sandbox API。这套接口不仅逻辑更加清晰，而且能够反对多沙箱接入。
Kuasar 的设计引入了 Sandboxer 的概念。每一种 Sandboxer 都应用了本人的容器隔离技术，用来治理同一类型的 Pod。以后 Kuasar 已反对多种 Sandboxer 的实现，包含 QEMU，Cloud-Hypervisor，StratoVirt[7]，Quark 等。
openEuler 全栈解决方案
openEuler 社区在容器引擎和容器运行时技术上的摸索是多方位的。iSulad 我的项目曾经沉闷多年，并在性能上继续欠缺，性能上继续优化。轻量级虚拟机 StratoVirt 则着力于虚构技术的冲破，相比于 QEMU 在内存和启动工夫上都有大量优化。现在，与华为云单干的新一代对立容器运行时 Kuasar 步入正轨，openEuler 社区具备了「iSulad + Kuasar + StratoVirt 全栈国产平安容器解决方案」。比照支流的 Containerd + Kata + QEMU 的解决方案，这套国产解决方案大大晋升集群的整体性能和部署能力。
总结
新一代容器引擎与容器运行时的解决方案解决了以后支流计划由来已久的痛点问题，不仅欠缺了运行时在 Pod 语义上的缺憾，新增了多沙箱部署的能力，而且在性能和可靠性等方面也带来了大幅晋升。目前已实现了性能上开发，后续个性的摸索与品质的加固还在继续进行当中，欢送大家提前试用并提出贵重的意见，咱们会尽快催熟相干个性并合入 openEuler LTS 版本。
openEuler 社区始终秉承着凋谢、单干、共享的开源态度，欢送更多的开发人员退出 openEuler 参加 iSulad、Kuasar、StratoVirt 等容器和虚拟化我的项目独特摸索。
Reference
[1]容器引擎我的项目 iSulad:https://gitee.com/openeuler/iSulad
[2]Kuasar:https://github.com/kuasar-io
[3]Sandbox API:https://github.com/containerd/containerd/issues/4131
[4]dev-sandbox 分支:https://gitee.com/openeuler/iSulad/tree/dev-sandbox
[5]用户指南:https://gitee.com/openeuler/iSulad/blob/dev-sandbox/docs/manu…
[6]Kuasar:https://github.com/kuasar-io
[7]StratoVirt:https://gitee.com/openeuler/stratovirt
