标签: 云原生

1. 背景、挑战与业界进展 1.1. 虚拟化技术背景 在云计算的浪潮中，虚拟化技术扮演着举足轻重的角色。它通过将物理机集群的资源进行抽象整合，构建出一个统一的虚拟资源池。在这个资源池中，每一台物理机上都会运行宿主机以及虚拟化的系统软件。这些系统软件负责为用户提供虚拟的计算环境，包括虚拟CPU、虚拟内存、虚拟网络等，都是由Hypervisor这一核心组件来实现的。Hypervisor不仅确保了虚拟机计算能力的平稳性和弹性，还为用户提供了灵活的资源调度和分配能力。 虚拟化技术在云数据中心、大数据处理、AI与机器学习等多个领域都得到了广泛的应用。通过虚拟化技术，企业可以更加高效地利用物理资源，实现资源的按需分配和弹性扩展，从而提高业务的灵活性和响应速度。 1.2. 虚拟化技术面临的问题与挑战 尽管虚拟化技术带来了诸多优势，但在实际应用中也面临着一些问题和挑战。 首先，虚拟化架构中的管理面会占用部分CPU和内存资源，从而降低了系统整体资源的利用率。系统服务systemd，或libvirtd等虚机管理程序的线程与vCPU线程之间存在资源争抢的问题，导致业务虚拟机的稳定性难以保证，进而影响客户业务的质量。 其次，虚拟机I/O处理线程会占用大量的CPU和内存资源。虚拟化通常使用virtio-blk，virito-net为虚机提供磁盘和网卡设备，为了获得更好的I/O性能，virtio-blk会采用iothread机制加速磁盘I/O的处理；而virtio-net则采用vhost-net的方案将网卡的I/O卸载到内核，通过减少用户态和内核态的切换来减速网卡的I/O的处理；不论是iothread还是vhost-net，都需要在Host上创建对应的线程来完成具体的I/O处理，当I/O负载高的时候，iothread和vhost-net的处理线程会占用大量的CPU和内存资源。 此外，虚拟化技术的安全性问题也不容忽视。当前主流虚拟化方案都是采用QEMU + KVM的形式，QEMU模拟了丰富的外设，由于编写模拟设备的人员众多，加上设备的接口大多数比较复杂，因此QEMU经常在处理这些读写请求的时候没有完整的对请求数据进行安全校验，导致产生了很多安全性问题。攻击者可能会利用虚拟化和Hypervisor的安全漏洞展开攻击，从而威胁到整个虚拟化环境的安全。 1.3. 头部云服务提供商的方案 针对虚拟化技术面临的问题和挑战，业界头部云服务提供商纷纷展开了探索和研发，并不约而同的提出了基于DPU的轻量虚拟化方案。 AWS研发了Nitro系统，通过Nitro卡将虚拟机的I/O卸载到硬件上，从而消除了I/O处理线程对VCPU的资源抢占。同时，Nitro hypervisor内置了虚拟机的管理能力，将管理组件卸载到Nitro SoC上。这种设计不仅提高了系统的资源利用率和稳定性，还大大增强了虚拟化的安全性。Host侧只运行Nitro hypervisor，不提供通用OS能力，没有用户态和文件系统，从而减少了潜在的攻击面。 VMware也提出了基于DPU的ESXi卸载方案。在该方案中，Host ESXi hypervisor负责虚拟化的核心逻辑，而DPU上的ESXi hypervisor则负责主机管理、存储和网络等功能。这种设计同样消除了管理和I/O处理的CPU占用，减少了vCPU的抢占，保证了vCPU的性能。同时，它也减少了Host的攻击面，增强了系统的安全性。 阿里云则推出了神龙系统，其中的Dragonfly Hypervisor以其超轻薄、资源零损耗的特点著称。根据公开资料，其内存占用每个虚拟机不到1MB，CPU占用小于0.1%。这种超低的资源损耗使得神龙系统能够提供更加平稳、高效的虚拟化服务。同时，Dragonfly Hypervisor还具备超平稳、超平滑的特点，能够解决资源池之间互相热迁移的难题，与KVM无缝兼容，从而为用户提供了更加稳定、可靠的云服务。 1.4. DPU轻量虚拟化方案的成效与市场应用挑战 基于DPU的轻量虚拟化Hypervisor解决方案在市场上取得了显著的成效。它大幅提升了资源利用率，降低了运营成本，增强了系统的安全性，为用户提供了更加稳定、可靠的云服务。这些优势使得该方案在市场上得到了广泛的认可，其商业价值也得到了充分的体现。 然而，头部云厂商自研的解决方案往往具有高度定制化和封闭性的特点，大部分未面向公开商用市场，这限制了其应用范围的扩大。尤其是在国内市场，商业化、公开的DPU轻量虚拟化解决方案仍然是一片空白。这不仅限制了其他云厂商或行业客户对这些方案的直接采用，也阻碍了基于DPU的虚拟化技术的进一步发展和普及。 综上所述，基于DPU的轻量虚拟化方案将为虚拟化技术带来了新的发展机遇，各云服务提供商和企业对该类方案的需求日益增加，市场呼唤创新和开放的解决方案。 2. 方案介绍 为了应对虚拟化技术面临的问题和挑战，中科驭数在多年的技术积累和丰富的行业经验基础上，面向公开市场，推出了基于自研DPU的轻量虚拟化解决方案。 2.1. DPU轻量虚拟化整体方案架构 基于中科驭数DPU的轻量虚拟化方案，在Host侧只保留Hypervisor和部分Linux内核功能，且不提供用户态控制面组件。QEMU作为Device Emulation service组件运行在SoC，提供虚机机型及设备的模拟，Host侧只有VCPU内核线程。驭数DPU卡支持nvme和virtio-net的硬件卸载，因此虚机的存储和网卡采用VF直通的方式透传给虚机，提供高性能的存储和网络。其他非关键I/O设备则采用半卸载的方式，卸载到SoC侧，交由QEMU进行模拟。 该方案中，每一个虚机都分配了一个特殊的PCIe设备，该PCIe设备的BAR空间划分成了两部分，其他一部分用于API信息的交互，成为API CHANNEL；另外一部分用于I/O请求的交互，称为IOREQ RING BUFFER。 以下为该方案的关键组件： Libvritd：该组件运行在SoC侧，对上层管理组件如nova-compute等提供虚机管理API，libvirtd进一步和SoC侧QEMU进行交互达到管理虚机生命周期的目的。 QEMU：运行在SoC侧，提供虚机的I/O设备模拟服务，QEMU的交互接口是SoC-KVM提供的/dev/kvm-soc设备文件。QEMU在模拟I/O设备的过程中通过DPU卡提供DMA机制访问HOST内存。 SOC-KVM：这是HOST-KVM内核模块在SoC侧的镜像，通过向用户态暴露/dev/kvm-soc设备文件，供用户态组件如QEMU，libvirtd等调用SOC-KVM提供的能力。该KVM内核模块不提供具体的CPU、MEMORY、I/O等虚拟化能力，只是作为管理面API和虚机I/O请求的转发模块。管理面API通过API channel转发到HOST-KVM模块，并由HOST-KVM进行处理；来自HOST-KVM的I/O请求保存在IOREQ RING BUFFER中，并由SOC-KVM分发给用户态QEMU。 HOST-KVM：这个内核模块是原生KVM的扩展，与原生KVM的区别是：请求不是来自用户态I/OCTL请求，而是来自API channel；除了原生提供的API，HOST-KVM进一步提供了管里面API的处理，如nova-compute或kubelet的资源汇报类接口。 驭数DPU卡提供了SoC和Host间的双向内存同步机制及SoC和Host间的双向中断机制，配合IOREQ RING BUFFER，使得虚机的I/O请求可以卸载到SoC侧QEMU完成；通过API channel，使得来自SoC侧管理API可以被HOST-KVM处理。 2.2. 方案描述 中科驭数DPU轻量虚拟化在保持虚机形态不变的情况下，完成了的虚机I/O和控制面的卸载；以下对主要部分做详细描述： 2.2.1.基于该方案的虚机生命周期管理 Libvirt-soc使用原生API和QEMU-SOC交互，QEMU-SOC采用原生API和KVM-SOC交互，KVM-SOC使用硬件的API channel通道，转发KVM-SOC的API到KVM-HOST，最后由KVM-HOST完成具体的处理。上图以虚机启动为例展示了各个组件的交互，在完成VM和VCPU创建后，QEMU-SOC进一步加载BIOS或kernel，加载后需要使用DMA机制将BIOS内存块同步给Host；加载成功后，设置虚机的寄存器，并发送kvm_run请求，开始VCPU的运行。 2.2.2.基于该方案的虚机I/O处理 GUEST的I/O操作，无论是PIO还是MMIO操作，都会导致VMEXIT，VMEXIT后KVM-HOST检查是否能够处理该I/O，如果无法处理，则需要将该I/O转交给KVM-SOC。KVM-HOST构造I/OREQ结构体，该结构体描述了该I/O的类型，地址，长度，数据等内容。构造完成后，将该IOREQ存放在IOREQ RING BUFFER中，并通过中断机制通知SoC侧，有新IOREQ到达。 KVM-SOC通过ioeventfd机制通知QEMU-SOC，QEMU-SOC访问BAR空间的IO RING BUFFER，取出IOREQ并处理。处理过程中，通过DMA机制访问Host内存。处理结束后，QEMU-SOC通过KVM-SOC 的ioctl接口注入中断。KVM-SOC通过BAR空间的API channel转发中断注入的API到KVM-HOST，最终由KVM-HOST完成虚机中断的注入工作。 2.2.3.基于该方案的虚机热迁移处理 Libvirt-soc发起热迁移操作，使用QEMU-SOC提供的QMP命令接口通知QEMU-SOC。QEMU-SOC连接迁移对端的QEMU，并开始热迁移的操作。QEMU-SOC首先发送全量的内存到对端，内存的同步使用DMA机制完成；全量内存发送完成后，开始迭代发送脏页，首先通过API channel，告知KVM-HOST开始记录脏页，在后续的迭代过程中，使用DMA机制将脏页信息从Host同步到SoC。在热迁移的最后阶段，KVM-SOC通过API channel发送暂停VCPU的API，KVM-HOST停止VCPU的运行。VCPU暂停后，QEMU-SOC停止所有I/O设备的运行，并发送最后的脏页的设备状态到对端。热迁移结束后，QEMU-SOC调用KVM-SOC的ioctl接口，销毁虚机，KVM-SOC通过API channel通知KVM-HOST完成真正的销毁操作。 2.2.4.openstack控制面对接 在该方案中nova-compute和libvirt均运行在DPU的SoC系统内，libvirtd直接和SoC侧QEMU交互镜像虚机管理，Host文件系统通过sharedfs代理到SoC侧，libvirtd通过在SoC侧访问Host文件系统来完成Host系统资源的跟踪和管理。虚机的网络和存储使用PCIe直通的方式，给虚机提供高性能存储和网络。存储和网络资源的管理通过nova-compute的yusur-driver完成，yusur-driver使用/dev/kvm-soc接口请求KVM-HOST侧的PCIe资源管理能力，完成虚机PCIe资源的准备、销毁等操作。 3. 方案优势 3.1. 方案优势 基于DPU的轻量虚拟化解决方案展现出了显著的价值与优势，这一方案不仅填补了市场空白，更引领了云计算行业的技术创新。 a. 填补空白，引领创新 该方案作为国内首创的、公开的、可商业化的DPU轻量虚拟化方案，打破了头部云厂商自研方案的封闭性，为更多云厂商和行业客户提供了可借鉴和采用的先进技术。这一方案的推出，无疑为云计算行业的多元化发展注入了新的活力。 b. 硬件加速，性能卓越 基于DPU的轻量虚拟化方案充分利用了DPU提供的硬件加速能力，显著提升了系统性能和I/O处理效率。在云计算环境中，I/O性能往往是决定业务稳定性和响应速度的关键因素。该方案通过I/O卸载技术，将I/O处理下放给DPU，有效减轻了HOST的负担，从而提升了整体系统的性能。 c. 显著提升资源利用率 该方案还显著提升了资源利用率。传统的虚拟化技术中，管理面和I/O处理线程会占用大量的CPU和内存资源，导致系统整体资源利用率降低。而基于DPU的轻量虚拟化方案则通过精简Hypervisor的设计，几乎不消耗任何主机侧的资源，使得所有的资源都被业务系统所使用。这一优势不仅降低了运营成本，还提高了业务的盈利能力。 d. 减少攻击面，强化安全 该方案在安全性方面也表现出色，通过I/O卸载技术，将I/O处理下放给DPU，有效地减少了HOST的攻击面，大大增强了HOST的安全性。同时，该方案还采用了多种安全技术和措施，进一步提升了系统的安全性。 综上所述，基于DPU的轻量虚拟化解决方案在技术创新、性能提升、资源利用率提高以及安全性增强等方面都展现出了显著的优势和价值。这一方案的推出将为云计算行业的发展带来新的机遇。 3.2. 未来与展望 展望未来，基于DPU的轻量虚拟化解决方案具有广阔的发展前景。随着云计算、大数据、人工智能等领域的快速发展，资源池规模不断扩大，对虚拟化技术的需求将日益增长。该方案以其卓越的性能、高效的资源利用率和强大的安全性，将成为推动这些领域发展的关键力量。 在技术层面，随着DPU技术的不断演进和升级，基于DPU的轻量虚拟化解决方案也将不断优化和完善，我们可以期待该方案在I/O处理效率、资源利用率和安全性方面实现更大的突破，为用户提供更加优质、高效的云服务体验。 同时，该方案的商业化应用也将进一步拓展。随着越来越多的云厂商和行业客户认识到其价值和优势，基于DPU的轻量虚拟化解决方案有望在市场上实现更广泛的应用和推广，为云计算行业的持续发展注入新的动力。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

1.背景介绍 1.1.业务背景 服务网格（Service Mesh）是微服务架构中的一种重要技术，它主要处理服务之间的通信，为服务间的信息交换提供更安全、更快速且更可靠的基础设施层。服务网格将服务治理从业务逻辑中剥离出来，拆解为独立的进程，实现异构系统的统一治理和增强网络安全。 一个典型的服务网格部署示意图如下： 其中绿色方块为应用服务，蓝色方块为代理。应用服务之间通过代理进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了服务网格。 服务网格的主要特点包括： 无侵入性：服务网格的设计理念是将通信和管理逻辑与业务逻辑解耦，使得业务逻辑无需关注通信细节，从而实现了对业务代码的无侵入性。 统一治理：通过服务网格，可以实现对微服务架构中所有服务的统一治理，包括服务发现、负载均衡、安全认证、监控和跟踪等功能。 可扩展性：服务网格支持多种微服务框架和服务治理能力，能够轻松扩展以支持更多的服务和场景。 服务网格的架构通常包括控制平面和数据平面，其中控制平面用于配置、管理和监控数据平面中的Sidecar代理，提供服务发现、负载均衡、安全认证等功能。 数据平面主要由边车Sidecar组成，它以轻量级的网络代理形式存在，与每个微服务实例部署在同一个主机或容器中，作为服务的附属组件运行。边车的主要职责是拦截和处理服务之间的通信流量，并与控制平面进行交互，实现服务发现、负载均衡、安全认证、监控和跟踪等功能。 边车的工作流程通常包括以下几个步骤： 拦截通信流量：边车代理拦截服务之间的所有入站和出站请求和响应。 服务发现：边车代理向服务注册中心注册服务实例，并根据需要动态地发现和管理服务实例。 负载均衡：边车代理根据配置的负载均衡算法，将请求分发到多个服务实例中，以提高服务的可用性和性能。 安全认证：边车代理可以实施安全认证策略，确保服务之间的通信是安全的。 监控和跟踪：边车代理收集和传输服务间的通信流量数据，以实现监控、日志记录、错误追踪和性能调优等功能。 综上所述，服务网格是微服务架构中的重要组成部分，它们共同为服务间的通信提供了安全、快速且可靠的基础设施层，并实现了对业务代码的无侵入性服务治理。 1.2.问题与挑战 在微服务架构中引入服务网格确实可以带来诸多好处，如简化服务治理、提高安全性和可观察性等，但同时也伴随着一系列问题和挑战。以下是几个主要方面： 边车带来的资源开销： 每个微服务应用都都需要运行一个边车代理，实际部署是每个POD部署一个边车容器。边车容器需要额外的计算资源来处理服务间的通信，默认情况下每个边车容器占用0.2个CPU核。假设一台服务器运行了60个POD，那么边车容器将额外占用12个CPU核。 业务转发时延增加： 应用程序的每个数据包都必须通过边车容器，数据包在应用程序和内核之间往返多次，如下对比是单个pod进或出增加的时延。 如图所示，右侧的是引入服务网格的方案，Pod内多了边车容器，相比左侧未引入服务网格的方案，数据包增加了内核往返次数，增加了时延。 通过上述分析可以看出，在微服务架构中引入服务网格确实带来了资源开销和转发时延的问题。 2.方案介绍 2.1.整体方案架构 服务网格DPU卸载解决方案将服务网格的sidecar边车容器集中卸载到DPU卡上执行，可以显著降低服务器CPU的算力消耗。同时，DPU卡高性能转发引擎实现了网络转发功能的加速，从而能够有效降低业务时延。该方案支持和原生Istio的无缝对接，对用户业务无侵入，可以实现业务的平滑迁移。 如图所示，红色系为本方案涉及本方案涉及部分，包括DPU卡及其提供给到主机侧的SRIOV vf口、主机侧CNI(istio-dpu-cni)。 业务容器的流量治理功能由DPU卡上的共享服务代理dpu-proxy提供，它由原生的边车容器从POD中抽离出来卸载到DPU卡上。它的配置由istio-dpu-cni通过对接istio获取并转换为集中式配置并下发下来。流量通过DPU提供的vf口到达DPU侧的dpu-proxy进行流量治理。 此架构的控制面仍为原生的istio，下发xDs配置给转发面；服务网格CNI（istio-dpu-cni）做为DPU卡在k8s集群的接口，无缝对接istio/收集集群信息，相当于DPU管理面给DPU组件下发配置及规则，使DPU卡可以实现原生的透明流量劫持以及流量治理的功能；DPU卡上的dpu-proxy做为服务网格的转发面，接收配置并根据配置对流量进行流量治理。 集群内的主机上插入DPU卡（红色），在主机侧集群内部署安装服务网格CNI（istio-dpu-cni组件）后，istio-dpu-cni组件可无缝对接控制平面K8s及Istio获取服务网格及网络配置、使能DPU卡上的共享服务代理dpu-proxy及转发引擎dataplane、下发相关的启动配置，主机即具有服务治理功能。之后在部署业务POD时，业务添加高速网口vf后，提供用户接口，使业务流量通过vf到达DPU侧dpu-proxy进行流量治理与转发。 2.2.方案描述 2.2.1.主机侧组件服务网格CNI实现管理平面 服务网格CNI（istio-dpu-cni组件）在主机侧k8s集群部署，无缝对接控制平面K8s及Istio获取配置等信息，转换为共享式代理配置下发到DPU侧的共享代理；基于DPU板卡的sriov功能，可给业务POD添加低时延高速网口vf及分配置IP地址；同时使能DPU侧转发引擎dataplane，给dataplane下发引流转发配置。 如图所示，服务网格CNI包括istio-dpu-controller、istio-dpu-adapter和istio-dpu-cni三个组件： ① istio-dpu-controller 使用daemonset方式部署在集群master上 主要是用于生成dpu级别的集中式服务网格配置，收集集群信息如pod变化、nodename等，转换为istio的inbound和internal 配置，并下发给对应节点的istio-dpu-adapter。 ② istio-dpu-adapter 使用daemonset部署在每个主机节点上 主要是用于无缝对接原生控制平面istio，可自动获取配置，转换集群内信息把原生配置聚合为共享式服务网格配置下发给代理dpu-proxy。 ③ istio-dpu-cni 使用daemonset部署在每个主机节点上 可配置网络模式是underlay或者overlay，针对性下发不同的网络规则；收集集群内信息（node, ns, service, pod等），提供用户接口可对dpu侧的转发引擎dataplane下发转发及引流规则，使dataplane能进行透明劫持低时延业务流量到dpu-proxy做流量治理。 除自研的CNI外，引入的开源组件为multus、sriov、spiderpool（不涉及开源组件的改动），通过二进制或pod的形式部署在需要的节点上。 2.2.2.DPU侧组件转发引擎及代理实现转发平面 如图所示，DPU侧组件包括转发引擎dataplane和共享服务代理dpu-proxy两个组件。在DPU卡的soc上，部署两个容器组件实现服务网格转发面功能，流量透明劫持及流量治理。 ① 共享服务代理dpu-proxy采用容器方式部署在DPU卡的SOC上 扩展封装原生边车代理istio-proxy为DPU共享服务代理dpu-proxy。它解析istio-dpu-adapter下发的动态共享式服务网格配置，对进出本机的低时延业务流量进行治理与转发。支持原生的四层TCP流量及七层HTTP流量治理；支持generic-proxy框架对其他七层流量进行流量治理。 ② 转发引擎dataplane采用容器方式部署在DPU卡的SOC上 dataplane接入协议栈(内核/用户态），并可通过vcl共享内存方式与共享服务代理dpu-proxy交互；接收istio-dpu-cni下发的转发及引流规则，根据规则把流量劫持到dpu-proxy；治理过的流量按转发规则进行网络封装及转发；dataplane加载vf-representer，通过NP（网络转发引擎）从vf-representer口收发对应pod内vf口的流量。 2.2.3.DPU共享服务代理流量转发模型 同主机内的业务互访如图（红色），client端业务流量经高速口vf到达DPU共享服务代理进行服务治理后，再经转发引擎dataplane转发到本主机的server端Pod。 跨主机业务互访如图（蓝色），client端业务流量经高速口vf到达DPU共享服务代理进行服务治理。治理后流量到达转发引擎dataplane，根据转发规则转到目标主机的DPU上共享服务代理做inbound入口流量治理。治理后流量再经转发引擎dataplane转到目标主机的server端Pod。 3.方案优势 3.1.方案优势 本方案创新性的将服务网格边车代理集中卸载到DPU上，可以带来一系列显著的优势，包括以下几个方面： ①显著降低服务器开销： 资源消耗减少： 传统的边车模式需要在每个服务容器旁边部署一个边车代理，这会导致大量的资源消耗（如CPU、内存）。通过将代理集中部署在DPU上，可以消除这些额外的资源消耗，使主机侧的资源更加专注于业务逻辑处理。 优化资源利用率： DPU作为专门的硬件加速单元，能够更高效地处理网络流量和加密解密等任务，从而释放主机CPU资源，提高整体系统的资源利用率。 ②极致的低时延： 用户态协议栈Bypass内核： 通过将网络处理移至DPU的用户态协议栈，绕过传统的内核态处理，可以显著减少数据包在内核与用户空间之间切换的开销，从而大幅降低网络延迟。 服务网格快路径： 自研的服务网格快路径技术可以进一步优化网络路径，减少不必要的处理步骤，确保数据包能够以最短的路径和最快的速度在网络中传输。 ③即插即用： 无侵入式服务治理： 集中式代理模式允许在不修改现有应用代码的情况下实现服务治理功能，如流量管理、安全控制等。这使得新服务的部署和现有服务的升级变得更加简单快捷。 灵活部署： DPU作为独立的硬件组件，可以轻松地集成到现有的服务器架构中，实现即插即用。这种灵活性使得企业可以根据实际需求快速调整网络架构和服务部署策略。 ④增强的安全性和隔离性： 服务隔离： 通过DPU上的集中式代理，可以减少不同服务和边车容器之间的干扰，防止潜在的安全风险。 综上所述，将边车代理集中卸载到DPU上是一种高效、灵活且安全的网络架构优化方案，能够显著降低开销、提升系统的性能并增强安全性和隔离性。 3.2.未来与展望 服务网格DPU卸载解决方案，作为云原生时代的一项创新技术，其核心价值在于显著优化了边车代理模式所带来的资源消耗问题，并大幅降低了业务请求在微服务间的转发时延。 随着云原生技术和微服务架构在各行各业的深入渗透，特别是在云计算、金融科技、物联网、边缘计算等领域，对于高效、可靠、可扩展的系统架构需求日益迫切。服务网格DPU卸载解决方案正是顺应这一趋势，凭借其卓越的性能提升和资源优化能力，展现出了极为广阔的应用前景和市场空间。 更为重要的是，该方案和技术正处于快速发展和不断完善的阶段。随着DPU技术的不断创新和服务网格框架的持续演进，未来将有更多高级功能被集成到DPU中，如更精细的流量管理、增强的安全策略执行、智能的数据处理加速等。服务网格DPU卸载方案将吸引更多行业巨头、初创企业以及技术开发者加入DPU生态，共同探索和实践DPU技术的潜力，推动其标准化、生态化的发展进程。 总之，服务网格DPU卸载解决方案作为云原生和微服务架构下的技术探索，展现出了巨大的潜力，有望成为推动云原生技术普及和深化的关键力量，为数字化转型注入新的活力和动力。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

1.方案背景 1.1. 业务背景 随着容器技术的迅猛发展与广泛应用，一种新的云计算服务模式应运而生-函数即服务（FaaS, Function as a Service）。FaaS作为一种无服务器（Serverless）计算方式，极大地简化了开发人员的工作，使他们能够专注于应用的构建与运行，而不再需要承担服务器管理的负担。 然而，FaaS模式也并非没有缺陷，其中最为人诟病的便是“冷启动”问题。所谓冷启动，是指当请求被调度到某个函数实例时，如果该实例在上次执行完代码后已经被回收，系统需要先创建一个新的实例并初始化环境，才能继续执行代码。 相比之下，热启动则是指函数实例未被回收的情况下，直接复用现有实例以响应请求，这显然效率更高。因此，冷启动过程常常导致较高的延迟，进而影响应用的性能。 1.2. 问题与挑战 1.2.1 传统方案 根据《Slacker: Fast Distribution with Lazy Docker Containers》一文的分析，镜像拉取过程占据了容器启动时间的76%，然而实际启动时只有6.4%的数据会被读取。这一现象揭示了传统容器镜像格式和拉取方式在使用overlay文件系统（OverlayFS）时存在的问题： 过多的时间花费在拉取镜像上。 拉取了过多无关的数据。 这两个问题的根源在于容器镜像是由一组tgz文件组成，而这些文件作为镜像层（image layer）存在以下两个显著缺点： 提取单个文件时，需要扫描整个layer。 同一层多个文件的提取不支持并行处理。 因此，使用OverlayFS的容器在启动前必须完成所有tgz文件的拉取和解压，这无疑增加了启动时间。 针对这些问题，社区已经提出了一些改进措施，具有代表性的两个解决方案是Stargz和DADI。 1.2.2 已有的改进方案 Stargz 是一种容器镜像加速技术，它采用了 Google的CRFS（Container Registry Filesystem）来重新组织容器镜像，以便实现更快的容器启动和更高效的文件检索。CRFS是一个只读的用户态文件系统，它使用了新的文件格式，使得镜像层内的文件可以被随机访问（seekable）。 stargz架构图 使用Stargz启动容器时，无需拉取所有层到本地，而是远程挂载每一层到本地目录组成rootfs，从而实现容器的快速启动。容器启动之后的数据访问则是利用FUSE(用户态文件系统)按需获取。 DADI(Data Accelerator for Disaggregated Infrastructure)是阿里云针对容器加速的解决方案，DADI 的核心组件是 Overlaybd，这是一种基于块设备的镜像格式，提供了在block-based layer之上的一个合并视图，然后通过TCMU在Host上产生一个SCSI设备作为rootfs。TCMU（Target Core Module In Userspace），是scsi target的用户态实现，用于生成一个容器 rootfs 的 SCSI 设备。 DADI架构图 使用DADI启动一个容器时，其也不用拉取所有层到本地，只是基于所有层块设备创建一个scsi device表示rootfs，实现容器的快速启动。容器启动之后的数据访问则是由tcmu按需获取，并且加入了本地缓存和ZFile加速数据的读取。 1.2.3 问题总结 综上所述，以上方案在实际应用中仍然存在以下问题： 传统OverlayFS容器的冷启动时间较长，这可能会对性能敏感的应用造成影响，导致较差的用户体验。 改进方案中的用户态文件系统需要占用一定的主机资源，这可能会对系统的整体性能产生影响。 2.方案介绍 2.1.整体架构 为了解决上述问题，我们构建了基于DPU的容器冷启动解决方案，以k8s为底座，以存储为核心，利用DPU的卸载和加速能力，使容器的冷启动更快，占用更少的host资源。整体架构如下所示： 1-4）：containerd会调用yusur-snapshotter准备rootfs每一层的内容快照，image-mgmt根据label参数连接存储，创建spdk bdev。 5-9）：到最后一层时，需要创建NVMe subsystem/ctrl/ns，关联spdk bdev，此时在host侧给相应PCI绑定NVMe驱动，即可看到对应的NVMe disk。 10）：yusur-snapshotter查到disk之后，按照不同的镜像格式生成容器启动的rootfs。 采用本方案启动容器时，首先DPU会通过NVMe/RDMA的方式连接远端存储，实现高效的数据传输，然后通过NVMe PCIE的方式直通给host，最后host基于这个直通的disk生成rootfs并启动容器。由于云盘原生支持按需读取的特性，本方案在容器启动过程中无需拉取镜像，从而显著加快容器的启动过程。 2.2.方案描述 当使用本方案启动容器时，首先需要进行镜像转换，镜像转换的主要作用是将原始镜像按照 Lvol（逻辑卷）的方式落地到存储中，并将镜像元数据推送至镜像仓库，供容器启动时使用。 同时本方案在镜像转换时支持两种镜像格式yusur-overlayfs和yusur-overlaybd。yusur-overlayfs和原生的镜像格式一样，按照overlay的方式生成rootfs，主要用于兼容overlay的场景；yusur-overlaybd以块设备的方式作为rootfs，原生支持可写层和理论上性能较overlayfs好。 2.2.1.镜像转换 镜像转换主要责任是基于SPDK snapshot机制把原生镜像按需转换成以上两种格式的镜像，镜像数据存到存储，元数据存到镜像仓库。镜像转换有两种工作模式：普通模式和DPU模式。在DPU模式下，能利用DPU的加速能力，可以显著加快镜像转换的速度。 普通模式的架构如下图所示，其组件主要包含image-ctrl，attacher service，opi-spdk-bridge和原生spdk。 红色线条表示数据走向，job拉取原镜像层数据，按不同镜像格式写到nbd设备中。各个组件的作用如下： Image-ctrl，镜像控制器：接收镜像转换yaml，创建转换job。job负责创建块存储，调用attach service创建和克隆lvol，完成镜像层数据写入lvol和推送转换后镜像元数据至仓库。 Attacher service：对opi-bridge操作的抽象，对上提供opi-bridge的能力 Opi-spdk-bridge：对接原生SPDK的opi-bridge，提供原生SPDK的基本操作 SPDK：原生SPDK提供快照，克隆的能力 DPU模式的架构如下图所示，其组件主要包含image-ctrl，image-mgmt，attacher ，opi-bridge和DPU spdk。 红色线条表示数据走向，job拉取原镜像层数据，按不同镜像格式写到NVMe disk中，各个组件的作用如下： Opi-bridge：提供不通DPU的存储能力API SPDK：不同DPU的SPDK 服务，提供NVMe disk的模拟功能 2.2.2.镜像格式 使用两种镜像创建容器时，处理流程基本一致，差异在镜像数据的组织方式和rootfs的组成方式，yusur-overlayfs镜像格式如下所示。 如上图所示，镜像X:A完成镜像转换之后，生成数据A，镜像X:B在转换时直接使用这部分数据，镜像X:B其他数据基于克隆的lvol写入。共享数据可以包含一个或多个lvol，它们之间也是通过clone链接在一起。 yusur-overlaybd的镜像格式如下图所示，与yusur-overlayfs镜像每层数据写到lvol不同目录的方式不同，yusur-overlaybd的镜像数据会直接写入lvol。 两种镜像格式的rootfs组成如下图所示。 yusur-overlaybd以nbd设备作为rootfs，不用额外的可写层；而yusur-overlayfs是以块设备中的多个目录作为lowerdir，然后加一个可写层作为upperdir构成rootfs。 2.2.3.容器启动 容器启动流程请参考”整体架构”章节。当用转换镜像启动容器时，containerd会根据镜像元数据生成一些labels，这些labels会作为参数传递给yusur-snapshotter，yusur-snapshotter会根据这些labels，创建不同的存储target。 目前支持两种形式的存储target，本地AIO和远程NVMe-OF，NVMe-OF同时又支持两种连接方式NVMe/TCP和NVMe/RDMA。在容器启动过程中主要涉及以下组件yusur-snapshotter，image-mgmt service和attacher service，作用如下： Yusur-snapshotter：实现containerd的snapshotter接口，负责准备容器启动的rootfs Image-mgmt service：和snapshotter交互，以AIO或NVMe-OF的方式创建和挂载块设备。 3.方案测试结果 3.1.功能测试 3.1.1.镜像转换 创建镜像转换CR之后，控制器就会创建job进行镜像转换。以下是yusur-overlayfs和yusur-overlaybd转换成功的截图： 转换成功之后，会更新CR status，blocks会包含目的镜像对应存储的卷，多个卷之间是以clone的方式递进，以yusur-overlayfs为例，如下所示： apiVersion: iaas.yusur.io/v1 kind: ImageConvertor metadata: name: nginx-latest-overlayfs namespace: image-mgmt spec: destImage: harbor.yusur.tech/cidg/img_test/nginx:latest-yusur-overlayfs imageMode: overlayfs sourceImage: harbor.yusur.tech/cidg/img_test/nginx:latest virtualSizeByGB: 100 status: blocks: - global-ba870cf5-6c3c-4cf6-95f3-d3963086b4e9 - local-e39cacaa-5c3e-4676-a014-d513a1ca0c09 - soldier-f64acdbb-4255-4999-81f8-652e1741120f imageMode: overlayfs ready: true 转换成功之后，目的镜像会推送至镜像仓库，其作用是在容器启动时，提供存储相关的元数据，如下所示： Annotation中包含该层所在的块设备，镜像格式，文件系统等信息，这些信息会作为labels传递给yusur-snapshotter。 3.1.2.Pod启动 pod启动之后，可以查看rootfs组成，如下所示： Yusur-overlayfs : overlayfs格式的镜像，块设备中包含镜像的每一层数据，挂载后把相关层目录，bind到对应的snapshot，构成overlay的lowerdir。 Yusur-overlaybd: overlaybd格式的镜像, 块设备中包含镜像的rootfs；没有把块设备直接作为容器启动的rootfs，考虑到还需要一个可写层，所以基于块设备创建一个qcow2的本地文件，然后本地文件通过nbd暴露出来，作为容器启动的rootfs和可写层。 3.2.性能测试 性能测试包括5种方案，本方案提供了其中的两种yusur-overlayfs/NVMe/RDMA和yusur-overlaybd/NVMe/RDMA。yusur-overlayfs/NVMe/RDMA表示镜像格式是yusur-overlayfs，存储target是NVMe-OF，连接方式是RDMA；yusur-overlaybd/NVMe/RDMA同yusur-overlayfs，只是镜像格式不同。 3.2.1.Containerd下的容器启动耗时测试 我们将测试整个容器启动过程中的时间消耗，具体分为三个阶段：镜像拉取、容器创建和服务ready。 如上图所示，纵坐标表示容器ready时间（单位：秒），横坐标表示镜像名称。由于此场景只是去掉了k8s的影响，结论同2.2.1, 如下： 本方案的yusur-overlayfs较overlayfs有63%的性能提升，因为不用拉取所有数据到本地； 本方案的yusur-overlaybd较DADI overlaybd有34%的性能提升，是因为本方案io路径更短。 如上图所示，可以得出如下结论： overlaybd镜像拉取是最快的，因为overlaybd在这个过程中只生成TCMU的config文件； 本方案的两种方法都较overlaybd慢，是因为本方案在镜像拉取中需要挂载云盘。 ​stargz也比overlaybd慢，是因为stargz在镜像拉取中需要挂载用户态文件系统​ 如上图所示，可以得出如下结论： 由于 OverlayFS 的数据已经在本地，因此 OverlayFS 的容器创建时间仅包括 runc 的操作以及启动命令的时间。 本方案的两种方法中，容器创建时间较高，因为本方案的 rootfs 基于 DPU 提供的云盘，yusur-snapshoter 需要创建 NVMe 系统（前端）并执行找盘操作。 stargz 在 CentOS 上消耗的时间较多，是因为 stargz 需要预加载（在这里需要预拉取 80M 的数据，主要时间消耗在这里）。 ​对于 overlaybd，由于其原理上与本方案基本相同，都是利用文件系统实现按需拉取，因此时间上基本差不多。 如上图所示，可以得出如下结论： 容器gcc消耗时间基本没有，是因为gcc启动命令只是执行了gcc --version，这个在容器创建时，已经就执行完了 OverlayFS 的耗时最短，因为在镜像拉取阶段，镜像数据已经被下载并存储在本地 Stargz由于前一过程预拉取了部分数据，所以总体时间上略高于OverlayFS。 本方案的 yusur-overlaybd 优于 overlaybd，主要是因为它在后期数据读取方面表现更佳。与 overlaybd 需要通过 TCMU 定位文件偏移量并使用 HTTP Range Request 向 registry 请求数据的方式不同，本方案直接通过内核 VFS，并采用 NVMe/RDMA 的方式进行数据传输，因而具有更低的延迟。 本方案的 yusur-overlayfs 相较于 stargz 和 overlayfs 表现稍逊，主要原因在于 overlayfs 的数据已存储在本地，而 stargz 在容器启动前已完成热点数据的预提取，而本方案则缺少数据预提取这一过程。 3.2.2.镜像转换耗时测试 由于两种镜像格式相差不大，故采用 yusur-overlayfs 作为对比，测试结果如下所示： 如上图所示，纵坐标表示不同模式下镜像转换时间（单位：秒），横坐标表示镜像名称。可以得出如下结论： 基于DPU的镜像转换方案可以降低镜像转换的时间，但是效果不是太明显。不明显的原因是受制于后端存储CEPH，导致RDMA发挥不出优势。 3.3.资源消耗测试 3.3.1.CPU消耗测试 stargz两次测试结果：如图所示，CPU最高使用率20.17%，平均使用率4.22%。 overlayfs两次测试结果 ： 如图所示， CPU最高使用率14.77%，平均使用率2.78%。 overlaybd两次测试结果：如图所示，CPU最高使用率11.4%，平均使用率3.27%。 yusur-overlayfs两次测试结果：如图所示，CPU最高使用率7.66%，平均使用率1.95%。 yusur-overlaybd两次测试结果：如图所示，cpu最高使用率10.02%，平均使用率2.17%。 整体使用率较yusur-overlayfs高，从system使用率观察可以得出是nbd这一层导致的。 汇总结果如下 ： 从以上所有图片，得出如下结论： 本方案的最高CPU使用率最低; 本方案的cpu高利用率维持时间最短，只有30s左右。 3.3.2.内存消耗测试 stargz两次测试结果：如图所示，最高内存使用7.67G，平均内存使用6.86G。 overlayfs两次测试结果：如图所示，最高内存使用5.71G，平均内存使用5.16G。 overlaybd两次测试结果：如图所示， 最高内存使用5.21G，平均内存使用4.94G。 yusur-overlayfs两次测试结果：如图所示，最高内存使用5.28G，平均内存使用4.87G。 yusur-overlaybd两次测试结果：如图所示， 最高内存使用5.62G，平均内存使用5.01G。 汇总结果如下 ： 从以上所有图片，得出如下结论： 本方案的消耗的内存最低； 本方案的内存高消耗维持时间最短，只有60s左右。 4.总结 4.1. 测试结果总结 在 K8s 场景下，本方案的 yusur-overlayfs 相比于传统方案 overlayfs，性能提升了 57%；而相比改进方案 DADI，yusur-overlaybd 的性能也提升了 20% 在 Containerd 场景下，本方案的 yusur-overlayfs 相比传统方案 overlayfs，性能提升了 63%；而 yusur-overlaybd 相较于改进方案 DADI，性能也提升了 34%。 控制面和数据面下沉至 DPU，有效减少了主机资源的消耗。从测试结果来看，本方案的 CPU 和内存占用率以及持续时间均为最低。 从镜像cypress-chrome（624.2 MiB）、centos(1.3GiB)、tensorflow-notebook(1.7 GiB)的启动时间看，在本方案中，容器冷启动时间随着镜像大小的增加，其时间优势变得越加明显。 从镜像转换的测试结果来看，镜像越大，基于 DPU 的方案在时间上表现出越明显的优势，因为它能够利用 DPU 的 RDMA 能力。类推到容器启动过程中，所需的数据量越大，本方案的优势也会越加显著。 4.2. 方案价值 基于DPU的容器冷启动加速解决方案具有如下价值： 1、提升服务响应速度和用户体验： 在FaaS中，由于函数实例是动态创建的，首次调用函数时可能会遇到冷启动延迟，即容器从停止状态到运行状态所需的时间。快速冷启动技术能够显著缩短这一时间，使得用户请求能够更快地得到响应，从而提升用户体验。 2、提高业务吞吐量： 快速冷启动使得FaaS平台能够在短时间内启动更多的函数实例，以应对突发的流量高峰，从而提高业务的整体吞吐量。 3、提高系统可用性： 在微服务架构和分布式系统中，服务的快速冷启动可以确保在服务实例故障时，能够迅速恢复服务，减少服务中断时间，提高系统的整体可用性。 4、提升资源利用效率： 控制面和数据面下沉至 DPU，有效减少了主机资源的消耗，这意味着在实际应用场景中，将大大节省了宝贵的CPU和内存资源，让这些资源能够被应用服务更高效地利用。 综上所述，基于DPU的容器冷启动加速解决方案对于提升服务响应速度和用户体验、提高业务吞吐量、提高系统可用性、提升资源利用效率等方面都具有重要的价值和意义，随着云原生和无服务器计算的不断发展，该方案将具有广阔的应用前景。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

1. 方案背景 1.1. Kubernetes Service介绍 Kubernetes Service是Kubernetes中的一个核心概念，它定义了一种抽象，用于表示一组提供相同功能的Pods（容器组）的逻辑集合，并提供了一种方式让这些Pods能够被系统内的其他组件发现并访问。简单来说，Service提供了一种让客户端能够稳定地连接到后端Pods的机制，即使这些Pods会动态地创建、销毁或迁移。 Kubernetes Service主要特性和用途 服务发现： Service允许客户端（如Pods中的应用程序）通过稳定的IP地址和端口号访问后端Pods集合，而无需关心实际Pod的IP地址或端口号，因为这些信息可能会因为Pod的重启或迁移而改变。 负载均衡： Kubernetes会自动在Service后面创建的Pods之间分配进入的流量，实现了简单的负载均衡。这意味着当多个Pods提供了相同的服务时，客户端的请求可以被均衡地分发到这些Pods上。 支持DNS： Kubernetes支持基于DNS的服务发现，允许Pods通过服务名（而不是IP地址）来相互通信。这大大简化了服务之间的调用和依赖关系的管理。 定义服务类型： Service可以有多种类型，最常见的是ClusterIP（默认，仅集群内部可访问）、NodePort（通过集群中每个节点的静态端口暴露服务）、LoadBalancer（在Cloud环境中，使用云提供商的负载均衡器暴露服务）和ExternalName（将服务映射到DNS名称，而不是选择Pods）。 在Kubernetes集群中，kube-proxy作为Service的代理组件，负责实现集群内部及外部对Service的访问。kube-proxy通过监听Kubernetes API Server中的Service和Endpoint资源变化，动态地在每个节点上配置网络规则，确保对Service的请求能够被正确地路由到后端的Pod实例上。 在iptables 模式下，kube-proxy会在每个节点上通过iptables规则来实现请求的转发。它会创建一系列的iptables规则，这些规则根据Service的IP和端口，将访问Service的流量重定向到后端的Pod IP和端口上。这种方式简单直接，但随着Service和Pod数量的增加，iptables规则会急剧膨胀，影响性能。 作为iptables的改进，ipvs（IP Virtual Server）模式提供了更高的性能和更好的扩展性。ipvs使用更高效的哈希表来管理网络规则，可以更快地查找和转发流量。这使得在大规模集群中，Service的访问性能得到显著提升。 1.2. 问题与挑战 尽管kube-proxy在大多数基础场景中表现良好，但它也存在一些明显的局限性： 1、场景简单： kube-proxy主要适用于简单的网络拓扑结构，对于复杂的IaaS（Infrastructure as a Service）场景，如需要支持VPC（Virtual Private Cloud）网络隔离、灵活的EIP（Elastic IP）使用等高级网络功能时，显得力不从心。 2、性能瓶颈： 由于kube-proxy的报文转发完全依赖于软件实现（无论是iptables还是ipvs），这意味着它无法利用现代硬件（如DPU、SmartNIC）进行网络加速，在高负载跨节点转发的情况下，这种软件实现的性能瓶颈尤为明显。 3、资源消耗： 基于软件实现的Kubernetes Service，在高负载跨节点转发的情况下会导致CPU资源消耗过高，从而影响整体系统的稳定性和性能。 与kube-proxy相似，许多开源的容器网络接口（CNI）插件，如使用Open vSwitch（OVS）的kube-ovn、Antrea等，通常依赖于自己的数据面处理机制来转发Service网络流量，在没有硬件加速的情况下，也面临类似的性能瓶颈和资源消耗问题。 2. 方案介绍 2.1.整体架构 本方案基于DPU&SmartNIC实现了Kubernetes Service的解决方案，简称“驭云Service”。 驭云Service在驭云SDN的架构中实现，其中驭云SDN通过ovn/ovs机制将DPU&SmartNIC加入到同一个ovn集群，对网络进行统一的虚拟化，整体物理架构图如所示: 在Pod/裸机/VM接入DPU卡或SmartNIC卡后，用户的请求由Service处理后送往对应的Pod/裸机/VM。 软件整体架构如下： 如图所示，驭云Service基于驭云SDN，上图各个组件中均会参与处理Service的逻辑，下面分别进行介绍： ycloud-controller，是SDN系统的控制平面，处理Service的主要逻辑，将用户创建的Service数据通过ovn转换成实际的网络拓扑。 yusurService-controller，处理用户创建的YusurService资源，翻译成内置Service资源给ycloud-controller使用。 ycloud-cni，该组件作为一个DaemonSet运行在每个节点上，是SDN的CNI接口，同时也会负责各个节点上Service的一些处理逻辑。 注：驭云SDN参见《基于DPU&SmartNIC的云原生SDN解决方案》 2.2.方案描述 在驭云SDN的概念中，所有后端资源，无论是Pod、VM还是裸金属服务器，都属于某一个VPC（虚拟私有云）。VPC实现了逻辑隔离的网络空间，这意味着不同VPC内的网络流量不会相互干扰，这提供了重要的安全边界，同时也便于多租户环境中的资源管理和隔离。然而，这种隔离也带来了一个挑战：如何允许不同VPC之间或者外部网络访问这些VPC内的资源。 Service需要解决的就是从不同地方经过Service访问到这些VPC内的资源，并且根据策略进行请求的负载均衡。在驭云Service中，具体包含以下场景： 集群内部互通（ClusterIP类型Service） 场景①：客户端在集群VPC内，访问同VPC下的后端服务： 在这种情况下，客户端可以直接通过Service的ClusterIP访问后端服务。ClusterIP是一种虚拟IP地址，由Kubernetes为Service分配，只在集群内部可见。流量在VPC内直接转发，无需经过额外的网关或负载均衡器。 场景②：客户端在集群节点上，访问默认VPC下的一组后端服务： 当客户端运行在集群节点上时，它同样可以通过ClusterIP访问服务。Kubernetes的网络策略确保流量在节点和后端服务之间正确路由。这种访问方式同样限于集群内部，不需要EIP。 集群外部访问集群内（LoadBalancer类型Service） 场景③：客户端在集群外部，通过EIP访问一个VPC下的一组后端服务： 在此场景下，客户端通过云外访问集群内的服务。LoadBalancer类型Service会分配一个EIP，此时外部流量通过EIP被路由到集群内部的Service。 场景④：客户端在集群外部，通过EIP访问多个VPC下的一组后端服务： 当客户端需要访问跨多个VPC的服务时，情况变得复杂。在这种情况下，当外部流量通过EIP进入集群内Service时，Servcie会同时充当网关，将流量正确地路由到目标VPC。 本方案主要从控制面和数据面2各方面进行介绍。 2.2.1. 控制面 在控制层，我们对原生Service进行了封装，在Kubernetes基础上扩展了对Service的管理能力，整体控制面结构如下图所示： Service和Endpoint是Kubernetes内置资源。资源Service定义了构造一个Service的基本信息。 由于内置资源无法满足我们需要功能，包括网络访问场景，和多种后端，于是驭云Service增加了YusurService与NetworkProbe两种自定义资源定义（CRDs）： YusurService: 一种扩展的Service概念，允许定义更广泛的后端资源，包括Pod、VM、BM（裸金属服务器）、VNicIP（虚拟网络接口IP）。通过使用选择器（selectors），可以灵活地匹配不同类型的后端资源，而不仅仅是Pod。支持定义多种网络场景，灵活的指定eip和clusterIP等。 NetworkProbe: 用于健康检查的新CRD，为每个后端资源生成相应的探针，实时监控其健康状态。这可以确保负载均衡器只将请求转发给健康的实例。 用户只需要和YusurService进行交互，yusurService-controller会根据YusurService的信息创建Networkprobe，Endpoint和Service这3种资源。 Service包含网络配置的大多基本信息，Endpoint资源包含本次配置的所有后端；Networkprobe返回后端健康检查结果，yusurService-controller会根据Networkprobe的返回结果调整Endpoint所包含的健康后端。 yscloud-controller则会根据Endpoint和Service的信息通过ovn绘制出整个网络拓扑，打通网络通路。 通过这样的架构，系统不仅提供了高级别的抽象来简化Service管理和后端资源的健康监控，还实现了跨VPC的负载均衡，增强了Kubernetes集群的网络功能。 2.2.2. 数据面 Service的数据面依赖OVN和OpenVswitch，根据不同的访问场景，在不同的地方配置Load_Balancer，Load_Balancer是OVN的逻辑概念，可以应用在OVN的逻辑交换机或者逻辑路由器上面，它将在对应的地方上配置DNAT的规则，将访问VIP的报文转到合适的后端上去。 下文分别针对控制面中所描述的4种Service使用场景进行说明。 2.2.2.1 同vpc下访问资源 当创建了Service之后，LoadBalancer的网络策略会确保应用在vpc1内的所有Subnet上。当subnet3上的client访问10.0.0.100时，其请求将首先被subnet3上的LoadBalancer接收。LoadBalancer会基于其算法（例如轮询、最少连接数等）选择一个后端Pod，并将数据包的目标地址转换为所选Pod的实际IP地址。数据包随后会通过vpc1被转发到选定的Pod所在的Subnet，例如subnet1，最后转发至Pod1。 2.2.2.2.从集群节点上访问vpc内资源 当集群节点上的client访问10.0.0.100时，报文经过node-interface进入subnet0，经过LoadBalancer将数据包的目标地址转换为所选Pod的实际IP地址后，通过ovn-cluster到对应subnet，完成一次转发。 2.2.2.3.从集群外部访问同一个vpc内资源 当创建了Service之后，LoadBalancer的网络策略会应用在vpc1上，当client访问200.0.0.100时，其请求将首先被这个EIP子网所属的eipGateway接收。eipGateway会将报文路由到Servic所属的VPC，vpc1内，此时LoadBalancer规则会基于其算法（例如轮询、最少连接数等）选择一个后端Pod，并将数据包的目标地址转换为所选Pod的实际IP地址。数据包随后会通过vpc1被转发到选定的Pod，完成一次转发。 2.2.2.4.从集群外部访问多个vpc内资源 当创建了Service之后，控制器会创建一个service-gateway的逻辑路由器，LoadBalancer的网络策略会应用在该路由器上，当client访问200.0.0.100时，其请求将首先被这个eip子网所属的eipGateway接收。eipGateway会将报文路由到service-gateway上，此时LoadBalancer规则会基于其算法（例如轮询、最少连接数等）选择一个后端Pod，并将数据包的目标地址转换为所选Pod的实际IP地址，源地址转换为所选service-gateway的系统IP地址。数据包随后会被转发到选定的Pod的vpc上，然后vpc将数据包送到Pod，完成一次转发。 3. 方案测试结果 3.1.创建Service 创建一个带有特定选择器和端口映射的Service YAML文件ysvc1.yaml，如下： apiVersion: iaas.yusur.io/v1 kind: YusurService metadata: name: ysvc1 spec: type: ClusterIP scope: vpc vpc: vpc1 ports: - port: 5001 name: iperf protocol: TCP targetPort: 5001 selector: svc: svc1-ep 使用kubectl apply -f ysvc1.yaml命令创建Service。 使用kubectl get ysvc ysvc1检查Service，如下： 访问Service clusterIP，访问成功。 图中的netns为service后端同vpc下的一个pod，10.233.46.185为service的clusterIP，5001是service暴露的端口。 3.2.性能对比 3.2.1 Pod的带宽 带宽单位Gbits/s。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 163 166 2 物理节点访问后端在远端的Service 152 130 3 Pod访问后端在远端的Service 151 138 从上面测试数据得出以下结论： 1. 卸载模式下，驭云访问远端Service能够达到接近物理机的带宽。 2. 卸载模式比非卸载在带宽上性能提升了20%左右。 3.2.2 Pod的pps pps单位为Mpps。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 45 45 2 物理节点访问后端在远端的Service 25.5 12.1 3 Pod访问后端在远端的Service 24.5 12.2 从下面数据得出以下结论： 1. 卸载模式下，驭云访问远端Service能够达到接近物理机的60%pps。 2. 卸载模式比非卸载在pps上性能提升了2倍以上。 3.2.3 Pod的延时 延时单位为us。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 32 32 2 物理节点访问后端在远端的Service 33 48 3 Pod访问后端在远端的Service 33 44 从上面测试数据得出以下结论： 1. 卸载模式下，驭云访问远端Service能够达到接近物理机的延迟。 2. 卸载模式比非卸载在延迟上降低了20%以上。 3.2.4 RPS 单位为Requests/s。 测试用例 驭云卸载方案 未卸载方案 1 物理节点之间基准测试 15999 2 Pod跨节点访问Service 15139 11040 从上面测试数据得出以下结论： 1. 卸载模式下，驭云访问远端Service能够达到接近物理机的rps。 2. 卸载模式比非卸载在rps上提升了40%左右。 3.2.5 每条request的CPU指令数以及CPI 每条request的CPU指令数，单位为instructions/request。 测试用例 驭云卸载方案 未卸载方案 Pod跨节点访问Service 122,613 171,405 CPI，单位为cycles/instruction。 测试用例 驭云卸载方案 未卸载方案 Pod跨节点访问Service 1.94 1.69 从上面测试数据得出以下结论： 1. 一个请求消耗的CPU指令数量，卸载模式比非卸载模式降低30%左右。 2. 在CPI方面，卸载模式比非卸载模式增大了15%左右。 3. 综合消耗的CPU指令数量来看，对CPU的消耗减少了25%左右。 4. 优势总结 基于DPU和SmartNIC的K8s Service解决方案展现出显著的优势，具体总结如下： ① 支持复杂网络拓扑与高级功能 在复杂的网络拓扑下实现K8s Service，支持VPC网络隔离和EIP等高级网络功能，大大增强了Kubernetes集群在IaaS环境中的网络灵活性和安全性，满足复杂场景下的网络需求。 ② 显著提升K8s Service性能 根据测试数据，本方案在带宽上性能提升了20%左右，pps上性能提升了2倍以上，延迟降低了20%以上。DPU和SmartNIC内置了强大的网络处理引擎，能够直接在硬件上完成报文的解析、转发和路由决策等任务，这种硬件加速机制使得在高负载跨节点转发时，仍能保持低延迟和高吞吐量，显著提升了Kubernetes Service的性能。 ③ 降低资源消耗与优化系统性能 根据测试数据，本方案对CPU的消耗减少了25%左右。由于DPU和SmartNIC承担了大部分的网络处理工作，CPU从繁重的网络转发任务中解放出来，可以专注于执行其他更关键的计算任务，这不仅降低了CPU的资源消耗，还提升了整体系统的稳定性和性能。 综上所述，基于DPU和SmartNIC的K8s Service解决方案在应对复杂网络拓扑、性能瓶颈和资源消耗等方面具有明显的优势，能够显著提升Kubernetes集群在复杂IaaS环境中的网络性能和整体稳定性。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

1. 方案背景和挑战 1.1. Mayastor简介 OpenEBS是一个广受欢迎的开源云原生存储解决方案，托管于CNCF（云原生计算基金会）之下，旨在通过扩展Kubernetes的能力，为有状态应用提供灵活的持久性存储。Mayastor是OpenEBS项目中的关键存储引擎，它以其高性能、耐久性和易于管理的特点，为云原生应用提供了理想的存储解决方案。Mayastor的特点包括： 基于NVMe-oF： Mayastor利用NVMe-oF协议，这是一种基于网络的NVMe访问方法，允许NVMe设备通过以太网或其他网络结构进行远程访问，这有助于提高存储系统的性能和可扩展性。 支持多种设备类型： 虽然Mayastor优化了NVMe-oF的使用，但它并不要求必须使用NVMe设备或云卷，也可以与其他类型的存储设备配合使用。 与Kubernetes集成： Mayastor作为OpenEBS的一部分，与Kubernetes紧密集成，允许开发人员和运维人员使用Kubernetes的原生工具（如kubectl）来管理和监控存储资源。 Mayastor适用于需要高性能和耐久性存储解决方案的云原生应用场景，特别是在边缘计算、大数据分析、流媒体处理等领域。它可以帮助开发人员构建高可用性和可扩展性的有状态应用，同时降低存储系统的复杂性和成本。通过利用NVMe-oF协议和最新一代固态存储设备的性能能力，Mayastor能够提供低开销的存储抽象，满足有状态应用对持久性存储的需求。 1.2. 问题与挑战 当前Mayastor只提供了NVMe over TCP技术实现数据存储服务，不支持NVMe over RDMA技术，这就不能充分挖掘NVMe SSD盘的性能优势，主要问题和挑战包括： 1、性能瓶颈： Mayastor依赖于TCP来实现NVMe SSD的数据传输，这意味着它不可避免地继承了TCP的性能瓶颈。TCP的头部开销和拥塞控制机制限制了数据传输的有效速率，尤其是在处理大量小数据包时更为明显。对于需要高速访问和处理的NVMe SSD来说，这种限制可能显著影响Mayastor的整体性能。 2、延迟敏感应用的挑战： 对于那些对延迟要求极高的应用（如高频交易、实时数据分析等），Mayastor当前的TCP实现可能无法提供足够的低延迟保证。TCP的延迟增加和抖动问题可能导致这些应用的性能下降，从而影响业务决策的时效性和准确性。 3、资源消耗： 在高并发场景下，Mayastor处理TCP数据包时涉及的频繁中断和上下文切换会显著增加CPU的负载。这不仅会降低系统整体的计算效率，还可能影响Mayastor处理其他存储请求的能力，导致整体性能下降。 2. 方案介绍 2.1. 整体架构 本方案是基于驭云ycloud-csi架构，将Mayastor整合进来，通过Gateway提供数据通路的RDMA加速，提高IO性能。在Host侧通过DPU卸载，可以进一步解放工作节点上的CPU负载，获取更好的应用性能。整体架构如下所示（标绿和标蓝部分是自研组件）： 本方案将不同的组件分别部署在不同的node，主要包含： Master Node上，部署 csi的控制器csi-controller，用于创建volume和NVMe-oF target。 Worker Node上，部署csi-node-host，配合csi-node-dpu，通过volumeattachment发现DPU挂载的NVMe盘，然后执行绑定或者格式化。 DPU上，部署csi-node-dpu和opi-bridge。opi-bridge是卡对opi-api存储的实现；csi-node-dpu 负责给host侧挂盘。 Storage Node上，部署Mayastor和GATEWAY，GATEWAY是对SPDK封装的一个服务，用于后端Mayastor存储，对外提供NVMe target访问。 2.2. 方案描述 本方案主要由ycloud-csi、RDMA Gateway和Mayastor后端存储三个部分组成，下面将对这三个部分进行介绍。 2.2.1.ycloud-csi 通过ycloud-csi架构可以接入第三方的存储，让第三方存储很方便的使用DPU的能力。其包括ycloud-csi-controller、ycloud-csi-node-host和ycloud-csi-node-dpu，主要职责是为K8s的负载提供不同的存储能力。 2.2.1.1.Ycloud-csi-controller Ycloud-csi-controller主要实现以下两类功能： 针对pvc，调用第三方的controller，创建卷，创建快照和扩容等； 针对pod，提供存储的两种连接模式：AIO和NVMe-oF（因为opi目前只支持这两种）。如果是NVMe-oF，则调用不同的plugin在GATEWAY上创建NVMe-oF target。 2.2.1.2.Ycloud-csi-node Ycloud-csi-node使用插件系统，对接不同的第三方存储。 ycloud-csi-node按node角色分为ycloud-csi-node-dpu、ycloud-csi-node-host和ycloud-csi-node-default，不同角色的csi-node功能不同，下面分别加以说明： Ycoud-csi-node-dpu需要处理host和DPU侧的挂盘请求，根据不同的连接模式(AIO或者NVMe-oF)，连接远程存储。 Ycloud-csi-node-host把DPU侧导出的volume挂载到pod中。 Ycloud-csi-node-default 也就是默认的工作模式，工作于smartNic场景。完成挂载volume，导入pod中。 2.2.2.RDMA Gateway RDMA Gateway是基于SPDK开发的存储服务，可以部署在io-engine相同的节点上，负责连接本地Mayastor的target，对外提供NVMe oF存储服务。 2.2.3. Mayastor storage 后端存储采用Mayastor，管理不同节点上的硬盘存储。 2.3. 工作流程 2.3.1.存储卷创建流程 用户的App运行在POD中。为了能存放持久的数据，需要给POD挂载存储卷。在启动POD之前，可以先创建好PVC，以供后面使用。创建PVC的过程如下： 图中除了包含上一章节介绍的组件外，还有两个k8s系统提供的用于方便对接csi的组件： external-provisioner：用户创建pvc时，该sidecar 会调用csi-controller的CreateVolume创建存储并创建pv与之前的pvc绑定。 Pv-controller：当底层存储准备好存储空间后，该sidecar会更新PVC的状态为bound。 2.3.2.存储卷挂载流程 在POD的描述yaml文件里，会指定使用的存储卷PVC。创建POD后，K8s的调度器会选择一个合适的节点来启动POD，然后attacher会把PVC连接到指定节点上，csi-node会把存储卷挂载到POD中。 图中包含两个k8s系统提供的用于对接csi的组件： external-attacher：会 watch VolumeAttachment 对象。根据 .spec.attacher 判断是不是需要自己处理，如果是则调用ControllerPublishVolume 方法，将.spec.persistentVolumeName 这个 Volume attach 到 .spec.nodeName 这个节点上。 AD controller： 会 watch Pod 对象，利用Pod 的 Volume 列表计算出 该 Node 上的 PV 列表，然后和 node.Status.VolumesAttached 值进行对比，没有attach 的话就执行 attach 操作。 3. 方案测试结果 3.1. Pod挂盘 通过相应的 yaml 描述文件，可以完成创建PVC，删除PVC，创建/删除snapshot，在POD中挂载PVC，并验证操作成功。经验证可知，Mayastor原生支持的操作，在添加Gateway之后，仍可以支持。 操作截图如下： 运行kubectl describe pod snap-mayagate-1命令查看pod，结果如下： 可以连进pod进行简单的写操作测试： 3.2. 性能对比 本方案基于单节点Mayastor创建单副本存储池，在以下测试场景与传统Mayastor方案进行对比： io-engine threads：设置io-engine的线程个数为2，4，6，8，分别测试； Transport：Mayastor采用NVMe over TCP，Gateway采用NVMe over RDMA； IO方式：随机读，随机写，顺序读，顺序写，30%写的混合读写； 不同的测试采样位置： 在Gateway/io-engine本地，目标是使用本地连接提供测试基准数据 在host通过nvme-cli的connect创建盘符来访问，这是host侧采用smartNic的场景 在host通过DPU直通来访问存储，是我们主要关注的测试case 考虑多个性能指标：测试的性能指标包括iops，吞吐，延迟和host cpu消耗。 (1) 随机写延迟分析 随机写延迟的测试结果，如下图所示： 对比TCP和RDMA在不同地方的采样，可知，io-engine所在节点本地访问延迟较小，在另外一个节点访问，TCP延迟增加了一个数量级，而RDMA延迟增加较小。 （2）顺序写带宽分析 顺序写带宽的测试结果，如下图所示： 通过在本地直接对于NVMe SSD硬盘测试，发现SSD可支持带宽大约2680MiB/s左右。从表中可以看到，使用nvme cli连接，无论是TCP还是RDMA，都可以接近后端存储支持的最大带宽。单独看DPU直通的数据，RDMA的性能远远超过TCP的性能。这是因为TCP由软件栈处理，需要消耗大量CPU资源，DPU内仅有4core，CPU资源不足造成的。 (3) 随机写IOPS分析 随机写IOPS的测试结果，如下图所示： 可以看到： 1.RDMA的io-engine本地和host nvme-cli两个测试位置曲线接近，说明RDMA是完全卸载到硬件处理，性能好； 2. TCP的两种方式性能有差别，特别是TCP DPU直通方式的上限是200kiops，说明瓶颈是在DPU的CPU上。 另外把Host cli访问的数据单独拿出来，用这两行单独作图，如下： 可以看到，当io-engine thread个数为4时，RDMA Gateway已经基本可以压满后端存储；再增加threads个数影响不大。但TCP直连时，性能还是会随着threads增加而增大。这说明RDMA在相对较低的资源条件下就可以达到较高的性能，其加速效果较好。 （4）随机读IOPS分析 随机读IOPS的测试结果，如下图所示： 可以看到TCP DPU直通方式随机读的上限是150kiops，说明瓶颈是在DPU的CPU上。 另外把Host cli访问的数据单独拿出来，用这两行单独作图，如下： 可以看到，当io-engine thread个数为2时，Mayastor TCP方式与RDMA Gateway相差不大，说明瓶颈在于存储后端；当io-engine thread个数大于等于4时，RDMA Gateway的性能要比TCP方式大约提高20%左右。 对于30%写的混合读写方式，由于读操作占主体，跟上面读操作的结果类似，在Host cli情形下，RDMA Gateway的性能要比TCP方式大约提高20%左右。 (5) Host侧CPU使用分析 在fio测试过程中，通过脚本记录Host上top命令的输出信息，获取CPU的使用信息。 下图是用Host cli连接时使用CPU的截图记录， TCP协议与RDMA协议的对比。（测试中Mayastor io-engine 采用8 core。） 测试命令是： fio -direct=1 -iodepth=64 -rw=randwrite -ioengine=libaio -size=100G -bs=4k -numjobs=16 -runtime=300 -group_reporting -filename=/dev/filename -name=Rand_Write_Testing 依次对于三个不同的挂接设备进行测试：/dev/nvme2n1是Host侧TCP cli；/dev/nvme3n1是Host侧RDMA cli；/dev/nvme0n26是DPU侧RDMA直通。 在3个挂载盘上分别做fio测试的IOPS结果分别是：655k，684k，646k。可以看到测试出的性能结果相差不大。上图是测试过程中通过脚本记录的CPU使用情况。可以看到，相对于TCP，使用RDMA协议可以节省大量的CPU。 4. 方案优势总结 1、显著提升性能： 通过前面测试数据可以看到，在DPU直通连入的场景下，本方案比原生的Mayastor方案随机写IOPS性能提升40%左右，随机读IOPS性能提升20%左右。在DPU直通的场景下，TCP方式延约200毫秒，RDMA方式约80毫秒，本方案可以减少60%左右的时延。这是因为本方案充分利用了RDMA的超低延迟和高性能特性。RDMA的零拷贝和绕过CPU的传输方式极大地减少数据传输过程中的延迟和CPU消耗，使Mayastor能够更高效地处理NVMe SSD的读写请求。 2、优化资源利用： 通过前面测试数据可以看到，采用RDMA的方式连接后端存储，相对于TCP方式可以节省50%左右的Host cpu。本方案通过NVMe over RDMA减少Mayastor对CPU和内存的占用，使系统资源能够更多地用于其他计算任务，这有助于提升Mayastor的整体稳定性和可靠性，同时降低运营成本。 3、增强可扩展性和灵活性： RDMA技术还提供了更好的可扩展性和灵活性。随着数据中心规模的扩大和存储需求的增长，Mayastor可以通过支持NVMe over RDMA来更轻松地应对这些挑战。RDMA的远程直接内存访问特性使得跨节点的数据传输更加高效和可靠，有助于构建更强大的分布式存储系统。 4、支持更多应用场景： 有了NVMe over RDMA的支持，Mayastor将能够更好地满足那些对性能有极高要求的应用场景。无论是高频交易、实时数据分析还是大规模数据库事务处理，Mayastor都将能够提供更加稳定和高效的数据存储服务。 综上所述，从Mayastor影响的角度来看，NVMe over RDMA技术相较于TCP在性能、延迟和资源消耗方面均展现出显著优势。对于追求极致性能的数据中心和应用场景来说，Mayastor未来能够支持NVMe over RDMA将是一个重要的里程碑，有助于进一步提升其市场竞争力和用户体验。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。