边缘云原生虚拟化研究报告2024.docx

前言III1技术与需求概述11.1 虚拟机和容器11.2 OpenStack与Kubernetes11.3 融合管理的演进：K8s环境下运行虚拟机31.4 开源项目简介42技术实践92.1 生命周期管理92.2 镜像管理102.3 存储管理132.4 网络能力15免发*男L 本内，本天褶台书多2. 3B安JtH,同入开效超，Xf RF><*I. MMX nBSaaB÷AS. JD工 叫*空基网反方,4. JS有其电&向iW条，僖.1 .进能省利：进聚邺顿万份行业研£、If理方案及其 也学习费;*Z 每日分享：6f行女恰是、3个行业主题a 掖含有词：密里宜桂咨囱,免费杪吃忘找4 产RL含：仅成行止报告交诵.Iht一切无关信息知识星球行业与管理资源专业知螟壮薛：银月分享3000份行业研犬界告、导拉计划、中场第充.企业这拿支专迩管理方案等.其差*4技、金融.般肓、互联河.为电产、生衬凯若'像行佗货等：己成为仅资、产业研究、企业用富、价值传格等工作毗手.参与单位（排名不分先后）：中国联合网络通信有限公司研究院，中国联合网络通信有限公司智网创新中心、可信边缘计算推进计划编写人：黄蓉庞博黄倩陈丹肖羽蔡超侯迎龙隗英英高沛李晓旭隋佳良王蕴婷李昂1技术与需求概述随着网络技术和云技术的发展，边缘计算得到了广泛的应用。边缘计算可以解决高可靠低延迟的设备接入和海量数据的实时计算问题，云技术有力的保障和推动了边缘计算的应用。1.1 虚拟机和容器虚拟机和容器是云计算中最常用到的应用部署和运行方式。虚拟机是伴随着虚拟化的技术出现的，容器则云原生技术的典型特征之一，他们的架构对比如下图所示：虚拟机1虚拟机N应用1应用n应用1应用m容器1容黜容器n薛文件库文件应用1应用2应用n客户机操作系统客户机操作系统库文件库文件库文件图1:虚拟机与容器架构对比图如上图所示，虚拟化技术一般通过虚拟化层（hypervisor）来实现,通过虚拟化技术,虚拟机可以共享物理机的CPU、内存、IO等硬件资源，并在逻辑上实现相互隔离。每一个虚拟机都拥有独立的操作系统（客户机操作系统），所以虚拟机不依赖于宿主机操作系统，其安全性和隔离性更强。但是虚拟机占用的资源较多，而且由于要模拟硬件，虚拟化层本身也会占用部分资源，对宿主机性能有一定的消耗。比较而言，容器则是使用宿主机的内核系统加上自身的文件系统。运行容器时是在使用宿主机的内核情况下加载文件系统，一般可以将容器看作是在内核上运行的独立进程。而精简的文件系统可以小到100MB以内，因此容器比虚拟机占用资源的更少、启动速度更快。容器缺点是隔离性不如虚拟机，而且由于依赖宿主机内核，所以容器的操作系统选择一般会受到限制。两种技术的特点对比如下表：表1:虚拟机与容器技术特点对比对比项虚拟机技术容器技术安全隔离性强，操作系统级别弱，进程级又指主机操作系统依赖无有,需要相同操作系统内核启动时间慢，分钟级快，秒级磁盘占用大（GB）小（MB）虚拟化性能损耗大I小1.2 OpenStack与Kubemetes从运行和管理平台来看，OPenStaCk2与KUbemetes（K8s尸分别是对虚拟机和容器进行运行和管理的典型开源项目。OPenStaCk是开源的云计算平台，利用虚拟化技术和底层存储服务，提供了可扩展、灵活、适应性强的云计算服务。OPenStaCk的服务分为核心功能和非核心功能。核心功能是指运行OPenStaCk系统必须的功能的组件，包括：Keystone（身份识S明踪）、Glance（镜像B踪）、Nova（计算棚艮务）、Neutron（网络服务）、Cinder（块存储服务）、Swift（对象存储服务）、Horizon（控制面板务）.三阪心功能指的是实现附加功能的组件，如Ceilometer（测量功能）、Heat（部署编排）、Trove（数据库服务）等。OPenStaCk的各个组件（服务）之间使用标准的API接口调用，减少了服务之间的依赖。下图是OpenStack的逻辑架构图。KnSlackL UrtiW,OpnSud IdrntthAFlOpmStxfc Urmffyr API图2:OpenStack逻W¾图KUberneteS是容器管理编排引擎，可以自动完成容器的部署、管理和扩展等操作，部署KUbemeteS的设备环境通常被成为Kubernetes集群。Kubernetes集群逻辑上可以分为两个部分：控制平面与计算设备（瞬为节点）OJS!lS5fi5:kube-apiserver（接邙踞,ffi=4B里内甑的脚请求）、kube-scheduler（调度程序）、kube-controller-manager（集群控制管理程序）、etcd（数据库）。计算设备包含容器运行时引擎、kubelet（节点代理程序）、kube-proxy（网络谴程序）。KUberneteS的设计原则包括：安全、易于使用和可扩展。KUberneteS同样遵循标准化APl接口，而且KUbemeteS实现了CNI（容器网络接口）、CRI（容器运行时接口）、CSI（容器存储接口）等接口和CRD（用户自定义资源）等，便于实现功能的扩展。下图是Kubernetes的逻辑架构图。Kubernetes clusterControl planekube-apiserverkube-schedulerkube-controller-manager(2et"Compute machineskubeletkube-proxyContainer runtimePod ContainersPersistantstorageiContainerregistryUnderlying infrastructurePhysicalVirtualPrivatePublicHybrid图3:Kubernetes逻辑架构图OpenStack的设计比较全面，组件众多，部署相对复杂，难于运维，使用成本较高，更适合作为大规模云的管理系统。相对而言，Kubernetes的设计更加简洁，其核心组件少，便于运维，同时K8s的生态很庞大，可以很方便地对其进行扩展或者定制，更适用于资源受限的边缘环境。1.3 融合管理的演进：K8s环境下运行虚拟机当前，通过容器部署的应用越来越广泛。但是，通过虚拟机部署的应用也会存在相当长的时间。首先，有不少现存的应用程序是运行在虚拟机上的，其中一些程序无法轻松地进行容器化重构。其次，即便对程序进行容器化改造，之后的系统调试和问题定位又会带来很大的挑战，尤其是对于通信行业来说，多代通信设备并存，对设备和应用程序的稳定性要求又非常高，对原有的应用程序进行容器化改造的成本和风险都是较大的。最后，一些应用或者场景更加适合使用虚拟机来进行部署。比如下面这些场景更适合使用虚拟机来运行而不是容器：* NFV(networkfunctionvirtualization)网络功能颜化的场景：将传统的网元团以化，使用虚拟机会比使用容器更方便，因为容器在接入多网卡方面比起虚拟机的能力来说还有一定的差距；* 大模型的研发测试：大模型在研发测试阶段进场需要使用多张GPU协同配合，同时要安装很多多软件依赖包来进行调试和使用，这时直接将多张GPU挂载到一个虚拟机里，然后在虚拟机里来实验开发要比在容器里方便很多；* 数据库：不是所有的数据库都适合放在容器里运行，比如部分数据库的特定算法需要限制IP的变化，在虚拟机里部署可以有一个固定的IP,会更加方便；* 很多进程的应用：在容器使用上，有个核心概念就是部署任务单一的进程，比如一个简单的叩i服务进程加一个日志收集的进程组合成为了一个容器，有些多进程的应用就不适合放在容器中运行了。于是，随着时间推移，企业会遇到这样的情况，有些应用还是只能运行在虚拟机上，有些应用已经完成了容器化，企业管理员不得不同时运维管理多套平台，这大大增加了运维的难度：* 计算资源：从管理角度来说计算资源的管理不同的平台的管理方法也是截然不同的，比如OpenStackSgaprqjectquota来窗里,而K8s贝UiffiSrequest/Iimit来,员必学蜂全了麒篇几制才能完全很好的管理起来；* 网络资源：同样，对于网络管理来说，不同的平台也是完全不同的，K8s使用CNI来管理网络，同时OPenStaCk通过neutron来管理网络，他们的使用理念上也是截然不同的,这样很大程度上增加了学习成本；* 监控/日志：各种平台都有自己的完整的监控/日志收集系统，它们会占用大量的计算、存储和网络资源，同时部署这样2套平台，从资源使用的角度上来说也是一种很大的浪费；* 存储资源：相同的存储资源对接K8s和OPenStaCk方式都是截然不同的，出现问题后找根因的思路和角度也都是不一样的，这样也大大加大了运维的成本和难度。* 安全风险：软件是由不同工程师编写的代码，运行在不同的操作系统上，每个环境都会遇到安全漏洞，越多组件则面临更多的安全漏洞，同时运维2套平台就意味着面临安全漏洞也会更多,企业面临的安全风险也就更大。从各个方面来看，企业内部的虚拟机平台和容器平台合并成为同一套平台来进行管理是一个趋势。那么是将K8s合并到OPenStaCk呢?还是反过来呢？业内也在研究虚拟机和容器的共平台的部署和管理，从OPenStaCk和K8s各自的发展来看，两个平台也在进行虚拟机和容器共同管理的探索，比如OPenStaCk的ZUn服务将容器作为一种OPenStaCk资源来进行管理，并通过集成OPenStaCk的其他服务，为用户呈现统一的、简化的APl接口，用户可以通过这些接口来创建、管理容器；K8s也有多个相关的开源项目在研究如何实现对虚拟机的管理（见下文）。从云技术的现状和发展来看，容器的应用越来越广泛，而且K8s在容器编排领域成为了业内事实上的标准。在边缘环境下，K8s的适用范围也更加广泛，因此，本文将进一步探讨在K8s环境下运行虚拟机的技术和实践范例。1.4 开源项目简介本节介绍在K8s环境下运行虚拟机的相关开源项目。当前这些项目还在发展之中，功能还在不断地迭代和完善。1.4.1 KubeVirtKUbeVirt4是一个K8s插件，由Redhat开源，云原生计算基金会（CNCF）赞助的开源项目。KubeVirt插件可以在K8s平台上调度传统的虚拟机。KUbeVirt使用自定义资源（CRD）将VM管理接口接入到K8s中，通过一个Pod去使用IibVirtd管理VM的方式，实现Pod与VM的对应，做到如同容器一般去管理虚拟机，并且做到与容器一样的资源管理、调度规划。KUbeVirt的架构图如下。图4:KUbeVirt架构图KUbeVirt主要由下列五个部分组成：virt-api:kubevirt是以CRD形式去管理VMPod,Virt-api就是所有虚拟化操作的入口，这里面包括常规的CDR更新验证、IiCRconsoIexVmStart、StOP乍。Virt-Controller:Virt-ContrOlIe哙牛雕VMlCRD,寸应的Virt-IaUnCherPod,并包耕CRD的状态。与K8s的叩i-serve谴讯监控VMI资源的创建删除等状态。virt-handler:Virt-handle哙以deamonset形式部署在每一节点上，负责节点上的每个虚拟机实例状态变化，一旦检测到状态的变化，会进行响应并且确保相应的操作能够达到所需(理想)的状态。Virt-handle好会保持集群级别VMlSPeC与相应IibVirti蛇间的同步；报告IibVirt域状态和集群SPeC的变化；调用以节点为中心的插件以满足VMlSPeC定义的网络和存储要求。Virt-Iauncher:每ZZbVirt-IaUnCherPOd对应WZbVMI,kubelet只负责Virt-IaUneherPOd谢亍状态,不会去关心VM呛犍情况。Virt-handle哙根据CRD参数配置去通知Virt-IaUnCher去使用本地的IibVirtd实例来启动VMI,随着Pod的生命周期结束，Virt-IanUnChe也会去通知VMl去执行终止操作；其次在每个Virt-IauncherPod中还对应着一个IibVirtd,Virt-IaUnCherS过IibVirtd去管理VM的生命周期，不再是以前的虚拟机架构那样一个IibVirtd去管理多个VM。Virtctl:VirtCtl是kubevirt自带类似kubectl的命令行工具,它是越过Virt-IaUnCherPOd这一层去直接管理VM虚拟机，可明制VM的start、stop,restart,KUbeVirt利用CRD的功能定义了若干种资源对象。VirtuaIMachineInstance(VMI):类似于KubernetesPod,是管理虚拟机的最小资源。一个VirtuaIMachineInstance对象即表示一台正在运行的虚拟机实例，包含一个虚拟机所需要的各种配置。VirtuaIMachine(VM):为群集内的VirtuaIMachineInstance提供管理功能，例如开机/关机ZB启虚拟机，确保虚拟机实例的启动状态，与虚拟机实例是1:1的关系，类似与spec.replica为1的StatefuISetoVirtualMachineInstanceMigrations:提供金以机迁移的能力，虽然并不会指定具体迁移的目的节点，但要求提供的存储支持RWX读写模式。VirtualMachinelnstanceRepIicaSet:判以RePIiCaSet,可IiUS的VirtuaIMachineInstance,并且保证指定数量的VirtuaIMachineInstance运行，可以配置HPAoKUbeVirt虚拟机生命周期管理主要分为以下几种状态：1 .虚拟机创建：创建VM对象,并同步创建DataVoIUme/PVC,从HarbO醺像仓库中拉取系统模板镜像拷贝至目标调度主机，通过调度、IP分配后生成VMI以及管理VM的LaUnCherPOd从而启动供业务使用的VMo2 .虚拟机运行：运行状态下的VM可以进行控制台管理、快照备份/恢复、热迁移、磁盘热挂载/热删除等操作，此外还可以进行重启、下电操作，提高VM安全的同时解决业务存储空间需求和主机异常HUng等问题。3 .虚拟机关机：关机状态下的VM可以进行快照备份/恢复、冷迁移、CPU/MEM规格变更、重命名以及磁盘挂载等操作，同时可通过重新启动进入运行状态，也可删除进行资源回收。4 .虚拟机删除：对虚机资源进行回收，但VM所属的磁盘数据仍将保留、具备恢复条件。1.4.2KataContainerKataContainer5社区由OpenStackFoundation(OSF),KataContainerZN=F旗原代码,运行时可以构建无缝插入容器生态系统的轻量级虚拟机，通过轻量级虚拟机来构建安全的容器，这些虚拟机的运行方式和性能类似于容器，但是使用硬件虚拟化技术作为第二程防御层，可以提供更强的工作负载隔离。相较于普通的容器技术，KataComainer的优点如下：/安全：在专用的内核中运行，提供网络，1/0和内存的隔离，并可以通过虚拟化扩展利用硬件强制隔离。/兼容性：支持行业标准，包括开放容器格式、KUbemeteSCRI等。/性能：提供与标准Liunx容器一致的性能。/简单：易于集成和使用。> Dtaconfoiners KMUSMM 丫？Hypervlsor VSOCK SocketVirtual MachineContairwr CommandConUinrExcNamespacesContainerHypervlsor图5:KataContaine1图KataCOntainer主要由由如下几部分组成:kata-agent:在虚拟机内kata-agent作为一个daemon进程运行，并拉起一个或多个容器的进程。kata-agent使用VlRTlO或VSoCK接口(QEMU在主机上暴露的s。Cket文件)在guest醐机中运行gRPC服务器。kata-runtime通过grpcf办议与kata-agent®信，向kata-agen侬送管理容器的命令。该协议还用于容器和管理引擎(例如DOCkerEngine)之间传送1/0流(StdOUt,stderr,stdin)。容器内所有的执行命令和相关的10流都需要通过QEMU在宿主机暴露的VirtioTerial或vs。Ck接口，当使用VlRTlo的情况下，每个虚拟机会创建一个KataContainersproxy(kata-proxy)来处理命令和10流。kata-runtime:KataContainersruntime(kata-runtime)通过QEMU/KVM技术创建了一种轻量型的虚拟机，兼容OCIruntimespecification,33寺KUbemeteS的ContainerRuntimeInterface(CRl)接口,qJCRIshimruntime(rune)通过K8s来创建POd或容器。kata-proxy:kata-ProXy提供了kata-shim和kata-runtime与VM中的kata-agentil信的方式，其中通信方式是使用Virtio-Serial或VSOCk,默认是使用VirtiO-SeriaLShim:kata-shim类似DOCker的containerd-shim或CRI-O的conmon,主要用来1!游和回收容器的进程，kata-shim需要处理所有的容器的IO流(stdout,stdinandstderr)和转发相关信号。当前KataContainer了KataShimV2(containerd-shim-kata-v2)版本，实现了ContainerdRuntimeV2(ShimAPI),Tkata-runtimexkata-shimxkata-proxy的功能，所以架构图中不再包含这几部分。其演进方式如下图所7J×PodSandbox图6:KataShimV2演进图Hypervisor:kata-container®过QEMU/KVM来仓J建虚拟机给容器运行，可以支持多种hypervisors。1.4.3Kube-OVNKUbe-OVN6是一款CNCF旗下的企业级云原生网络编排系统，将SDN的能力和云原生结合，提供丰富的功能，极致的性能以及良好的可运维性。KUbe-OVN可提供跨云网络管理、传统网络架构与基础设施的互联互通、边缘集群落地等复杂应用场景的能力支持，解除KUberneteS网络面临的性能和安全监控的掣肘，为基于KUbemeteS架构原生设计的系统提供成熟的网络底座，提升用户对KUberneteS生态RUntime的稳定性和易用性。KUbe-OVNfiiS威U和®SS三,平移OPenStaCk网络的M口功能至JKUbemetes。OPenStaCk的网络已经发展了很多年，很多设计和概念也基本成了SDN的标准。KUbe-OVN通过引入高级功能和成熟的网络概念，从整体上增强KUberneteS网络的能力，并通过OVN实现网络的数据平面，简化维护工作。Kube-OVN的组件可以大致分为三类： 上游OVN/OVS组件。 核心强制器和Agent。 监控，运维工具和扩展组件。图7:KUbe-OVN架构图±J0VN0VS:该类型组件来自OVN/0VS社区，并针对KUbe-OVN的使用场景做了特定修改。C)VN/0VS本身是一套成熟的管理虚机和容器的SDN系统。KUbe-OVN使用OVN的北向接口创建和调整虚拟网络，并将其中的网络概念映射到KUbemetes之内。ovn-central:DePIOymenti亍OVN的IsI里平面组件，包括OVn-nb、OVn-Sb和OVn-northd。多个OVn-CentraI实例通过Raft协议同步数据保证高可用。- ovn-nb:保存虚拟网络配置，并提供API进行虚拟网络管理。kube-ovn-controller将会主要和ovn-nb进行交互配置虚拟网络。- ovn-sb:保存从ovn-nb的逻辑网络生成的逻辑流表，以及各个节点的实际物理网络状态。- ovn-northd:将ovn-nb的以网译成ovn-sb中0¾igS三0ovs-ovn:ovs-ovn以DaemOnSet形式运行在每个节点，在Pod内运行了Openvswitchxovsdb和Ovn-Controllere这些组件作为OVn-CemraI的Agent将逻辑流表翻译成真实的网络配置。Agent该部分为KUbe-OVN的核心组件，作为OVN和KUbemeteS之间的一个桥梁，将两个系统打通并将网络概念进行相互转换。kube-ovn-controller:该组件XbDePIOyment执行所有KUberneteS内资艇IOVN资源工作,其作用相当于整个KUbe-OVN系统的控制平面。1(此0-枚48卅。1国监听了所有和网络功能相关资源的事件，并根据资源变化情况更新OVN内的逻辑网络。主要监听的资源包括：Pod、Service.Endpoint.Node、NetworkPoIicyxVPCxSubnet.VlansProviderNetworkekube-ovn-cni:该组件为TDaemonSet运行在每个节点上，实现CNl接口，并操作本地的OVS配置单机网络。kube-OVn-Cni会配置具体的网络来执行相应流量操作。监控，运维工具和扩展组件该部分组件主要提供监控，诊断，运维操作以及和外部进行对接，对KUbe-OVN的核心网络能力进行扩展，并简化日常运维操作。kube-ovn-speaker:该组件为一个DaemonSet运行在特定标签的节点上，对外发布容器网络的路由,使得外部可以直接通过PodIP访问容器。kube-ovn-pinger:该组件为一个DaemOnSet运行在每个节点上收集OVS运行信息，节点网络质量,网络延迟等信息，收集的监控指标可参考KUbe-OVN触指标。kube-ovn-monitor:该组件为一个DePloyrnent收集OVN的运行信息，收集的监控指标可参考KUbe-OVN监控指标。kubectl-ko:该组件为kubectl插件，可以快速运行常见运维操作。2技术实践本章通过一些典型地范例介绍对于在K8s环境下运行虚拟机的功能增强的技术实践。2.1 生命周期管理2.1.1 在K8s环境下实现虚拟机热调整资源在K8s中启动的虚拟机都是在TPod里面运行着IibVirtd和qemu等依赖组件，这样kube-scheduler不需要感知Pod里是一个虚拟机还是一个容器，都按照统一的方式进行管理。既然虚拟机运行在了K8s平台上，那么我们管理虚拟有可以通过kubectl进行管理。创建虚拟机SiSkubectIcreate-fVmLyaml直接通过一zyaml文件来创建T虚拟机。更新虚拟机通过kubectleditvm-nnamespacel即会打开一个Vim编辑器，让用户直接可以修改虚拟机的yaml文件。删除虚拟机IffiSkubectIdeletevmvml-nnamespacelffl5namespacel-FK）Z以机VmL虚拟机热调整资源由于K8s最近的版本已经支持Pod原地扩容了，可以利用了这个功能，实现kubevirt的虚拟机的卬U和memory热添加的功能，社区目前只支持CPU的热插。*社区的热扩容的实现：社区目前之实现了通过了IiVemigration（热迁移）功能来实现的，这样的实现依赖虚拟机是否可以进行热迁移，比如虚拟机如果有gpu挂载的话，就不能实现热迁移，也就不能热扩容。node图8:社区版热扩容*改进的实现：首先使用了1.27.x版本的特性POd原地扩容的特性(Podin-placeVPA)先将外部的Virt-IauncherPod的Iimi明整到期望的大小，然后再调用IibVirt叩法扩容虚拟机到期望的大小。node图9:改进版虚拟机热扩容2.2镜像管理2.2.1 从Harbor镜像仓库拉取镜像在容器云平台启动虚拟机，那么虚拟机镜像最好是能和容器镜像一起管理，避免增加不必要的菅理成本，所以可以将制作好的虚拟机镜像伪装成为了一个容器镜像存放在Harbor中，这样就不用单独管理虚拟机的镜像了。HarbOr7是由VMWare公司开源的企业级的DOCkerRegiStry管理项目，它包括权限管理(RBAC)、LDAPx日志审核、管理界面、自我注册、镜像复制和中文支持等功能。HarbO镜像仓t:harbor.mec.local,首513831<12(11命<2彳5置：# kubectlgetcm-nmec-imageshci-controller-config-oyaml#kubectleditcm-nmec-imageshci-controller-config-oyamlapiVersion:vldata:config.yaml:heahzPort8080resyncPeriod:IOmIeaderEIection:IeaderEIect:trueIeaseDuration:30srenewDeadline:15sresyncPeriod:5sresourceName:hci-controllerresourceLockendpointsleasesFesourceNamespace:mec-imagesControIIerConfig:basdmageNamespace:mec-imagessnapshotclass:csi-rbdplugin-snapclass#nameofVolumeSnapshotClassglanceBaseURLhttps:/172.18.22.100:9292IBgtstryAddrharborJiiedocaIkind:ConfigMapmetadataannotationskubectl.kubemetes.io/last-applied-configuration:"apiVersion,fvl",data,"config.yam*,healthzPort8080nresyncPeriod:CreationTimestamp:"2022-07-06T14:44:34Z"name:hci-controller-confignamespace:mec-imagesresourceversion:"18229389"uid:3de8bcfc-f87d-4be5-9c85-d84198866133在HarbO呛库中的镜像有kubevirtfedora36,创建EVM时采用该镜像：# kubectlcreate-fevm-registry-fedora.yaml# catevm-registry-fedora.yamlapiVersion:mececsio/vlbetalkind:EnhancedVirtuaIMachinemetadataname:ecs-registry-fedoranamespace:wq-testspectemplate:specrunning:truetemplate:metadatalabels:kubevitiovm:ecs-registry-fedoraannotationsovn.kubemetes.io/allow_live_migration:'true'Kcf.ionetworks:mec-nets/attachnetlattachnetl.mec-nets.ovn.kubemetes.io/logical_switch:subnet-ipv4attachnetl.mec-nets.ovn.kubemetes.io/default_route:'true'attachnetLmec-nets.ovn.kubemetes.io/allow_live_migration:'true'specdomain:cpu:sockets:4cores:1threads:1memory:guest"8192Mi"clock:timezone:"Asia/Shanghai"timerrtcpresenttruedevices:disks:- disk:bus:virtioname:cloudindiskinterfaces:- bridge:name:attachnetlresources:requests:cpu:2memory:2048MidnsPolicy:"None"dnsConfig:nameservers:- 114.114.114.114options:- name:ndotsvalue:"5"hostname:"ecs-registry-fedora"networks:-name:attachnetlmuhs:networkName:mec-nets/attachnetlvolumes:-name:CloudinitdiskCloudInitNoCIoud:userData:-#cloud-configpassword:fedorassh_pwauth:Truechpasswd:expire:Falsesource:registr>dmageURLtbHrtfedora36datestbtVolume:resources:requests:storage:IOGi创建成功，EVM可正常访问。#kubectlgetevmecs-registry-fedora-nwq-testNAMEAGEecs-registry-fedora3hlm#kubectlgetvmecs-registry-fedora-nwq-testNAMEAGESTATUSREADYNODENAME READY Trueecs-registry-fedora3hlmRunningTrue#kubectlgetvmiecs-registry-fedora-nwq-testNAMEAGEPHASEIPecs-registry-fedora3hlmRunning192.168.100.26ecs82.3存储管理2.3.1 KataCOntainer使用卷的存储直通模式本项优化是为了提高使用Kata作为容器运行时提高CePhrbd作为磁盘时的IO性能。原有挂载是储存卷（RBDimage）挂载到宿主机的目录中，然后通过Virtio-fs协议，将存储卷的内容共享到KataContainer+如下图所示:可以添加卷直通功能，分为半直通（块直通）和全直通（rbd直通）两个模式。其中半直通如下图所示，去掉了中间的协议Virtio-fs,将映射到宿主机上面的块设备通过qmp命令直接添加到了KataContainer中，KataCOmainer再通过m。Un曲设备进行内容的读写。全直通如下图所示，进一步的去掉了挂载到宿主机上面的动作，将rbdimage直接通过qmp指令作为块®&添力唯!J了KataContainer中，KataContainer再iSi3：moun曲IggiS行内容断期。卷直通功能是否开启通过PVC的annotations进行控制。在PVC的annotations中添加了VOIUme.kataContainerS.iodirect-mod与段O1 .当VOlUme.katacontainers.iodirect-modefi为"block”时，为半直通衡C;2 .当VOIUme.kataContainerS.iodirect-modefl为"rbd"时,为全盲通模式;3 .在字段的值不为上述两个或者不添加该字段时为原有模式。直通模式，通过kubectlexec-itcentos-blk-test-bash进入到对应容器后可以看到对应的块设备且对应的FileSyStem不为none:rt(a)deployersimple-test#kubectlexec-itcentos-blk-test-bashroOtcentos-blk-test/#df-hFilesystemSizeUsedAvailUse%Mountedondevsdb4.9G265M4.4G6%/tmpfs64M064M0%devtmpfs998M0998M0%sysfscgroupdesdc20Ga0ML9G1%/data-rtxidevsddZ0G6,0ML9G1%/data-blockshm998MO998M0%devshmrt(S>centos-blk-test/#IsblkNAMEMAJ:MINRMSIZEROTYPEMOUNTPOINTsda8:005G0disksdb81605GOdisk/sdc83202G0diskdata>rxisdd8:4802G0diskdata-bk×kpmem25900382MIdisk'-pmempl259:10380M1part半直通模式，创建Pod之前通过ISblk查看host的块设备信息,如果为半直通则创建完Pod之后host会多出来一个rbd的块设备卜oothostl#IsblkNAMEMAJ:MINRMSIZEROTYPEMOUNTPOINTsr11:01486K0romrbdl251:1602GOdiskvda252:0050GOdisk-dal252:1OSOGOpart/2.3.2KataContainer和OpenEBS适配优化本项优化是为了提高使用Kata作为容器运行时提高OPenEBS作为磁盘时的I。性能。OPenEBS8是一种开源云原生存储解决方案,托管于CNCF基金会。OPenEBS是K8s本地超融合存储解决方案，它管理节点可用的本地存储，并为有状态工作负载提供本地或高可用的分布式持久卷。OPenEBS支持两大类卷，本地卷和复制卷。管理员和开发人员可以使用kubectl、Helm、Prometheus.Grafana.WeaveSCoPe等K8s可用的工具来交互和管理OPenEBS。为了实现KataContainer使用OPenEBS的本地卷直通方式，修改OPenEBS的IVm-IoCaIPV直通的实现。O