《边缘云原生虚拟化研究报告-31页.docx》由会员分享，可在线阅读，更多相关《边缘云原生虚拟化研究报告-31页.docx（27页珍藏版）》请在三一办公上搜索。
1、前言III1技术与需求概述11.1虚拟机和容器112OpenStack与Kubemetes11.3 融合管理的演进：K8s环境下运行虚拟机31.4 开源项目简介42技术实践92.1 生命周期管理92.2 镜像管理102.3 存储管理132.4 网络能力151技术与需求概述随着网络技术和云技术的发展，边缘计算得到了广泛的应用。边缘计算可以解决高可靠低延迟的设备接入和海量数据的实时计算问题，云技术有力的保障和推动了边缘计算的应用。1.1虚拟机和容器虚拟机和容器是云计算中最常用到的应用部署和运行方式。虚拟机是伴随着虚拟化的技术出现的,容器则云原生技术的典型特征之一，他们的架构对比如下图所示：曲机1J
2、OttN应用1 应用n应用1应用m容器1容器2容器n图1:虚拟机与容器架构对比图如上图所示，虚拟化技术一般通过虚拟化层(hypervisor)来实现，通过虚拟化技术，虚拟机可以共享物理机的CPU、内存、IO等硬件资源，并在逻辑上实现相互隔离。每一个虚拟机都拥有独立的操作系统(客户机操作系统)，所以虚拟机不依赖于宿主机操作系统，其安全性和隔离性更强。但是虚拟机占用的资源较多，而且由于要模拟硬件，虚拟化层本身也会占用部分资源，对宿主机性能有一定的消耗。比较而言，容器则是使用宿主机的内核系统加上自身的文件系统。运行容器时是在使用宿主机的内核情况下加载文件系统，般可以将容器看作是在内核上运行的独立进程
3、。而精简的文件系统可以小到100MB以内，因此容器比虚拟机占用资源的更少、启动速度更快。容器缺点是隔离性不如虚拟机，而且由于依赖宿主机内核，所以容器的操作系统选择一般会受到限制。两种技术的特点对比如下表：表1:虚拟机与容器技术特点对比对比项虚拟机技术容器技术安全隔离性强，操作系统级别弱，进程级别对宿主机操作系统依赖无有，需要相同操作系统内核启动时间慢，分钟级快，秒级磁盘占用大(GB)小（MB虚拟化性能损耗大1小1.2OpenStack与Kubemetes从运行和管理平台来看，OPenStaCk2与Kubernetes(KSs)3分别是对虚拟机和容器进行运行和管理的典型开源项目。OPenStaC
4、k是开源的云计算平台，利用虚拟化技术和底层存储服务，提供了可扩展、灵活、适应性强的云计算服务。OPenStaCk的服务分为核心功能和非核心功能。核心功能是指运行OPenStaCk系统必须的功能的组件，包括：KeyStOne（身份识别服务）、Glance（镜像服务）、Nova（计算机服务）、Neutron（网络服务）、Cinder（块存储服务）、Swift（对象存储服务）、Horizon（控制面板服务）。非核心功能指的是实现附加功能的组件，如Ceilometer（测量功能）、Heat（部署编排）、Trove（数据库服务）等。OPenStaCk的各个组件（服务）之间使用标准的APl接口调用，减少了
5、服务之间的依赖。下图是OpenStack的逻辑架构图。-Command-Ineratfacesm,ePJHV-CloudMaAaQemeeToote(RJghecae.Entf8ivs0JW1GUIoIDasHjoartltCyberdw*,o119MmXaInternet图2:0PenStaCk逻辑架构图KUberneteS是容器管理编排引擎，可以自动完成容器的部署、管理和扩展等操作，部署KUberneteS的设备环境通常被成为KUbemeIeS集群。KUberneIeS集群逻辑上可以分为两个部分：控制平面与计算设备（或称为节点）.控制平面的包含：kube-apiserver（接口程序，用于
6、处理内部和外部请求）、kube-scheduler（调度程序）、kube-controller-manager（集群控制管理程序）、etcd（数据库）。计算设备包含容器运行时引擎、kubelet（节点代理程序）、kube-proxy（网络代理程序）。KUberneteS的设计原则包括：安全、易于使用和可扩展。KUbemeteS同样遵循标准化APl接口，而且KUberneteS实现了CNl（容器网络接口）、CRI（容器运行时接口）、CSI（容器存储接口）等接口和CRD（用户自定义资源）等，便于实现功能的扩展。下图是KUberneteS的逻辑架构图。KubernetesclusterCompute
7、 machinesPersistantstoragekube*apiserverkube-schedulerkubeletkube-proxykube-controller-managerContainer runtimePodLJLJ ContainersContainer registryUnderlying infrastructurePhysicalVirtualPrivatePublicHybridControlplane图3:Kubemetes逻辑架构图OpenStack的设计比较全面，组件众多，部署相对复杂，难于运维，使用成本较高，更适合作为大规模云的管理系统。相对而言，Kube
8、metes的设计更加简洁，其核心组件少，便于运维，同时K8s的生态很庞大，可以很方便地对其进行扩展或者定制，更适用于资源受限的边缘环境。1. 3融合管理的演进：K8s环境下运行虚拟机当前，通过容器部署的应用越来越广泛。但是，通过虚拟机部署的应用也会存在相当长的时间。首先，有不少现存的应用程序是运行在虚拟机上的，其中一些程序无法轻松地进行容器化重构。其次，即便对程序进行容器化改造，之后的系统调试和问题定位又会带来很大的挑战，尤其是对于通信行业来说，多代通信设备并存，对设备和应用程序的稳定性要求又非常高，对原有的应用程序进行容器化改造的成本和风险都是较大的。最后，一些应用或者场景更加适合使用虚拟机
9、来进行部署。比如下面这些场景更适合使用虚拟机来运行而不是容器：* NFV(networkfunctionvirtualization)网络功能虚拟化的场景：将传统的网元虚拟化，使用虚拟机会比使用容器更方便，因为容器在接入多网卡方面比起虚拟机的能力来说还有一定的差距；* 大模型的研发测试：大模型在研发测试阶段进场需要使用多张GPU协同配合，同时要安装很多多软件依赖包来进行调试和使用，这时宜接将多张GPU挂载到一个虚拟机里，然后在虚拟机里来实验开发要比在容器里方便很多；* 数据库：不是所有的数据库都适合放在容器里运行，比如部分数据库的特定算法需要限制IP的变化，在虚拟机里部署可以有一个固定的IP,
10、会更加方便；* 很多进程的应用：在容器使用上，有个核心概念就是部署任务单一的进程，比如一个简单的叩i服务进程加一个日志收集的进程组合成为了一个容器，有些多进程的应用就不适合放在容器中运行了。于是，随着时间推移，企业会遇到这样的情况，有些应用还是只能运行在虚拟机上，有些应用已经完成了容器化，企业管理员不得不同时运维管理多套平台，这大大增加了运维的难度：* 计算资源：从管理角度来说计算资源的管理不同的平台的管理方法也是截然不同的，比如OpenStackSgaprqjectquota来窗里,而K8s贝UiffiSrequest/Iimit来,员必学蜂全了麒篇几制才能完全很好的管理起来；* 网络资源：
11、同样，对于网络管理来说，不同的平台也是完全不同的，K8s使用CNI来管理网络，同时OPenStaCk通过neutron来管理网络，他们的使用理念上也是截然不同的,这样很大程度上增加了学习成本；* 监控/日志：各种平台都有自己的完整的监控/日志收集系统，它们会占用大量的计算、存储和网络资源，同时部署这样2套平台，从资源使用的角度上来说也是一种很大的浪费；* 存储资源：相同的存储资源对接K8s和OPenStaCk方式都是截然不同的，出现问题后找根因的思路和角度也都是不一样的，这样也大大加大了运维的成本和难度。* 安全风险：软件是由不同工程师编写的代码，运行在不同的操作系统上，每个环境都会遇到安全漏
12、洞，越多组件则面临更多的安全漏洞，同时运维2套平台就意味着面临安全漏洞也会更多,企业面临的安全风险也就更大。从各个方面来看，企业内部的虚拟机平台和容器平台合并成为同一套平台来进行管理是一个趋势。那么是将K8s合并到OPenStaCk呢?还是反过来呢？业内也在研究虚拟机和容器的共平台的部署和管理，从OPenStaCk和K8s各自的发展来看，两个平台也在进行虚拟机和容器共同管理的探索，比如OPenStaCk的ZUn服务将容器作为一种OPenStaCk资源来进行管理，并通过集成OPenStaCk的其他服务，为用户呈现统一的、简化的APl接口，用户可以通过这些接口来创建、管理容器；K8s也有多个相关的
13、开源项目在研究如何实现对虚拟机的管理（见下文）。从云技术的现状和发展来看，容器的应用越来越广泛，而且K8s在容器编排领域成为了业内事实上的标准。在边缘环境下，K8s的适用范围也更加广泛，因此，本文将进一步探讨在K8s环境下运行虚拟机的技术和实践范例。1.4开源项目简介本节介绍在K8s环境下运行虚拟机的相关开源项目。当前这些项目还在发展之中，功能还在不断地迭代和完善。1.4.1 KubeVirtKUbeVirt4是一个K8s插件，由Redhat开源，云原生计算基金会（CNCF）赞助的开源项目。KubeVirt插件可以在K8s平台上调度传统的虚拟机。KUbeVirt使用自定义资源（CRD）将VM管
14、理接口接入到K8s中，通过一个Pod去使用IibVirtd管理VM的方式，实现Pod与VM的对应，做到如同容器一般去管理虚拟机，并且做到与容器一样的资源管理、调度规划。KUbeVirt的架构图如下。图4:KUbeVirt架构图KUbeVirt主要由下列五个部分组成：VirLaPQkubevirt是以CRD形式去管理VMPOd,virLapi就是所有虚拟化操作的入口，这里面包括常规的CDR更新验证、以及ConSOle、vmstartStoP等操作。Virt-Controllerivirt-Controller会根据VMlCRD,生成对应的Virt-IaUnCherPod,并且维护CRD的状态。与
15、K8s的api-server通讯监控VMI资源的创建删除等状态。virt-handlenvirt-handler会以deamonset形式部署在每个节点上，负责监控节点上的每个虚拟机实例状态变化，一旦检测到状态的变化，会进行响应并且确保相应的操作能够达到所需(理想)的状态。Virt-handler还会保持集群级别VMISPeC与相应Iibvirt域之间的同步；报告IibVirI域状态和集群SPeC的变化；调用以节点为中心的插件以满足VMlSPeC定义的网络和存储要求。Virt-Iauncher:每个Virt-IaUnCherPOd对应着一个VMLkUbeIet只负责VirI-IaUnCherP
16、Od运行状态，不会去关心VMl创建情况。Virt-hander会根据CRD参数配置去通知VirtTaUnCher去使用本地的IibVirtd实例来启动VML随着POd的生命周期结束，Vin-IanUnCher也会去通知VMl去执行终止操作；其次在每个Virt-IauncherPOd中还对应着一个IibVirtd,Viri-Iauncher通过IibVind去管理VM的生命周期，不再是以前的虚拟机架构那样一个IibVirtd去管理多个VM。virtctl:Virtctl是kubevirt自带类似kubect1的命令行工具，它是越过VirtTaUnCherPOd这一层去直接管理VM虚拟机，可以控制
17、VM的Start、stop、restart.KubeVirt利用CRD的功能定义了若干种资源对象。VirtualMachinelnstance(VMI):类似于KubernetesPod,是管理虚拟机的最小资源。一个VirtualMachinelnstance对象即表示一台正在运行的虚拟机实例，包含一个虚拟机所需要的各种配置。VirtualMachine(VM):为群集内的VirtualMachinelnstance提供管理功能，例如开机/关机/重启虚拟机，确保虚拟机实例的启动状态，与虚拟机实例是1:1的关系，类似与spec.replica为1的StatefulSet.VirtualMachi
18、nelnstanceMigralions:提供虚拟机迁移的能力，虽然并不会指定具体迁移的目的节点，但要求提供的存储支持RWX读写模式。VirtualMachinelnstanceReplicaSet:类似RePliCaSeL可以启动指定数量的VirtualMachinelnstance,并且保证指定数量的VirtUaIMaChinelnStanCe运行，可以配置HPAoKUbeVirt虚拟机生命周期管理主要分为以下几种状态：1.虚拟机创建：创建VM对象，并同步创建DataVolUnle/PVC,从HarbOr镜像仓库中拉取系统模板镜像拷贝至目标调度主机，通过调度、IP分配后生成VMl以及管理V
19、M的LaUnCherPOd从而启动供业务使用的VMo2 .虚拟机运行：运行状态下的VM可以进行控制台管理、快照备份/恢复、热迁移、磁盘热挂载/热删除等操作，此外还可以进行重启、下电操作，提高VM安全的同时解决业务存储空间需求和主机异常HUng等问题。3 .虚拟机关机：关机状态下的VM可以进行快照备份/恢复、冷迁移、CPU/MEM规格变更、重命名以及磁盘挂载等操作，同时可通过重新启动进入运行状态，也可删除进行资源回收。4 .虚拟机删除：对虚机资源进行回收，但VM所属的磁盘数据仍将保留、具备恢复条件。1.4.2KataContainerKataContainer5社区由C)PenStaCkFOUn
20、dation(OSF)领导，KataCOntainer是一个开放源代码的容器,运行时可以构建无缝插入容器生态系统的轻量级虚拟机，通过轻量级虚拟机来构建安全的容器，这些虚拟机的运行方式和性能类似于容器，但是使用硬件虚拟化技术作为第二程防御层，可以提供更强的工作负载隔离。相较于普通的容器技术，KataContainer的优点如下：安全：在专用的内核中运行，提供网络，IO和内存的隔离，并可以通过虚拟化扩展利用硬件强制隔离。J兼容性：支持行业标准，包括开放容器格式、KubernetesCRl等。性能：提供与标准Liunx容器一致的性能。简单：易于集成和使用。katatainers KataShim V
21、2QRPCKata Shim V2Virtual MachineContainermmandContainerExecNamespacesContainerHypervisor图5:KataCOntainer架构图KataContainer主要由由如下几部分组成：kata-agent:在虚拟机内kata-agent作为一个daemon进程运行，并拉起个或多个容器的进程。kata-agent使用VlRTIo或VSoCK接口(QEMU在主机上暴露的SoCket文件)在gues嘘拟机中运行gRPC服务器。kata-runtime通过grpc协议与kata-agent通信，向kata-agent发送管
22、理容器的命令。该协议还用于容器和管理引擎(例如DOCkerEngine)之间传送I/O流(stdout,stderr,stdin),容器内所有的执行命令和相关的IO流都需要通过QEMU在宿主机暴露的VirIiO-Serial或VSOCk接口，当使用VIRTIO的情况下，每个虚拟机会创建一个KalaContainersproxy(kata-proxy)来处理命令和K)流。kata-runtime:KataContainersruntime(kata-runtime)通过QEMU/KVM技术创建了一种轻量型的虚拟机,兼容OClruntimespecification标准，支持KUbemeteS的C
23、ontainerRuntimeInterface(CRl)接口,可替换CRlShimruntime(rune)通过K8s来创建POd或容器。kata-proxy:kata-proxy提供了kata-shim和kata-runtime与VM中的kata-agent通信的方式，其中通信方式是使用VirtiO-Serial或VSoCk,默认是使用VirtiO-Seria1。Shimzkata-Shim类似DoCker的containerd-shim或CRLO的conmon,主要用来监控和回收容器的进程，kata-shim需要处理所有的容器的IO流(stdout,stdinandstderr)和转发相
24、关信号。当前KataConIainer发展到了KataShimV2(containerd-shim-ka(a-v2)版本，实现了ComainerdRUnlimeV2(ShimAPI),集成了kata-runtime、kata-shimkata-proxy的功能，所以架构图中不再包含这几部分。其演进方式如下图所ZJ卜0图6:KataShimV2演进图Hypennsonkata-Container通过QEMU/KVM来创建虚拟机给容器运行，可以支持多种hypervisors。1.4.3Kube-OVNKube-OVN6是一款CNCF旗下的企业级云原生网络编排系统，将SDN的能力和云原生结合，提供丰
25、富的功能，极致的性能以及良好的可运维性。KUbe-OVN可提供跨云网络管理、传统网络架构与基础设施的互联互通、边缘集群落地等复杂应用场景的能力支持，解除KUbemeteS网络面临的性能和安全监控的掣肘，为基于KUberneteS架构原生设计的系统提供成熟的网络底座，提升用户对KUberneteS生态RUmime的稳定性和易用性。Kube-OVN的设计原则和思路是，平移OPenStaCk网络的概念和功能到KUbernetes。OPenSIaCk的网络己经发展了很多年，很多设计和概念也基本成了SDN的标准。KUbe-OVN通过引入高级功能和成熟的网络概念，从整体上增强KUberneteS网络的能力
26、，并通过OVN实现网络的数据平面，简化维护工作。Kube-OVN的组件可以大致分为三类： 上游OVN/OVS组件。 核心控制器和Agent. 监控，运维工具和扩展组件。ControllerannotationPCi 1VPC2vpoaWorklOMlSpaceZSefvice updateAnnotateIR1MAC-SubneVgwAnnotateIP/MAC/Subnet/gwMetrics图7:KUbe-OVN架构图上Bovvovs姐件该类型组件来自OVN/OVS社区，并针对KUbe-OVN的使用场景做了特定修改。OVN/OVS本身是一套成熟的管理虚机和容器的SDN系统。KUbe-OVN
27、使用OVN的北向接口创建和调整虚拟网络，并将其中的网络概念映射到KUbemeIeS之内。Ovn-Centra1:DePIOynIenl运行OVN的管理平面组件，包括OVn-nb、OVn-Sb和ovn-northd。多个Ovn-Central实例通过Raft协议同步数据保证高可用。ovn-nb:保存虚拟网络配置，并提供APl进行虚拟网络管理。kube-ovn-controller将会主要和ovn-nb进行交互配置虚拟网络。ovn-sb:保存从ovn-nb的逻辑网络生成的逻辑流表，以及各个节点的实际物理网络状态。-ovn-northd:将ovn-nb的虚拟网络翻译成ovn-sb中的逻辑流表。ovs
28、-ovn:ovs-ovn以DaeInonSet形式运行在每个节点，在Pod内运行了OPenVSWitch、OvSdb和ovn-controllero这些组件作为OVn-CentraI的Agent将逻辑流表翻译成真实的网络配置。核心控制器和Agent该部分为KUbe-OVN的核心组件，作为OVN和KUbemeteS之间的一个桥梁，将两个系统打通并将网络概念进行相互转换。kube-ovn-controller:该组件为个DePIOyment执行所有KUberneteS内资源到OVN资源的翻译工作，其作用相当于整个KUbe-OVN系统的控制平面。kube-ovn-controller监听了所有和网络
29、功能相关资源的事件，并根据资源变化情况更新OVN内的逻辑网络。主要监听的资源包括：Pod、Service.Endpoint.Node、NetworkPolicyVPCSubnetVlanProviderNetworkokube-ovn-cni:该组件为一个DaemOnSet运行在每个节点上，实现CNl接口，并操作本地的OVS配置单机网络。kube-ovn-cni会配置具体的网络来执行相应流量操作。监控，运维工具和扩展组件该部分组件主要提供监控，诊断，运维操作以及和外部进行对接，对KUbe-OVN的核心网络能力进行扩展，并简化日常运维操作。kube-ovn-speaker:该组件为一个DaemO
30、nSet运行在特定标签的节点上，对外发布容器网络的路由，使得外部可以直接通过PodIP访问容器。kube-ovn-pinger:该组件为一个DaemOnSet运行在每个节点上收集OVS运行信息，节点网络质量，网络延迟等信息，收集的监控指标可参考KUbeQVN监控指标。kube-ovn-monitor:该组件为一个DePIOylnenl收集OVN的运行信息，收集的监控指标可参考KUbe-OVN监控指标。kubectl-ko:该组件为kubectl插件，可以快速运行常见运维操作。2技术实践本章通过一些典型地范例介绍对于在K8s环境下运行虚拟机的功能增强的技术实践。2. 2.1生命周期管理3. 1.
31、l在K8s环境下实现虚拟机热调整资源在K8s中启动的虚拟机都是在一个POd里面运行着IibVirtd和qemu等依赖组件，这样kube-scheduler不需要感知POd里是一个虚拟机还是一个容器，都按照统一的方式进行管理。既然虚拟机运行在了K8s平台上，那么我们管理虚拟有可以通过kubectl进行管理。创建虚拟机通过kubectlcreate-fvmLyaml直接通过一个yaml文件来创建一个虚拟机。更新虚拟机通过kubectleditvm-nnamespace1即会打开一个Vim编辑器，让用户直接可以修改虚拟机的yaml文件。删除虚拟机通过kubectldeleteVmvml-nnames
32、pace1来删除在namespacel下的一个虚拟机Vmlo虚拟机热调整资源由于K8s最近的版本已经支持POd原地扩容了，可以利用了这个功能，实现kubevirt的虚拟机的CPU和memory热添加的功能，社区目前只支持叩U的热插。*社区的热扩容的实现：社区目前之实现了通过了IiVemigmtion（热迁移）功能来实现的，这样的实现依赖虚拟机是否可以进行热迁移，比如虚拟机如果有gpu挂载的话，就不能实现热迁移，也就不能热扩容。node图8:社区版热扩容*改进的实现：首先使用了L27x版本的特性POd原地扩容的特性(Podin-placeVPA)先将外部的virt-lancherPOd的Iimi
33、I调整到期望的大小，然后再调用IibVirtapi去扩容虚拟日侄U期望的大小。node图9:改进版虚拟机热扩容2.2镜像管理2. 2.1从Hartior镜像仓库拉取镜像在容器云平台启动虚拟机，那么虚拟机镜像最好是能和容器镜像一起管理，避免增加不必要的管理成本，所以可以将制作好的虚拟机镜像伪装成为了一个容器镜像存放在Hart)Or中，这样就不用单独管理虚拟机的镜像了。HarbO门是山VMWare公司开源的企业级的DoCkerRegiStIy管理项目，它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。HarbOr镜像仓库地址为：harbor.mec.lo
34、cal,首先通过kubect】命令进行配置：Skubectlgetcm-nmec-imageshci-controller-config-oyaml# 1CUbeCtleditcm-nmec-imageshci-controller-config-oyamlapiVersion:vldata:config,yaml:healthzPort:8080resyncPeriod:IOmIeaderElection:IeaderElectitrue1easeDuration:30srenewDeadline:15sresyncPeriod:5sioresourceName:hci-controller
35、resourceLockendpointsleasesFesourceNamespace:mec-imagesControIIerConfig:basdmageNamespace:mec-imagessnapshotclass:csi-rbdplugin-snapclass#nameofVolumeSnapshotClassglanceBaseURLhttps:/172.18.22.100:9292registryAddr:hartxx.mec.kxlkind:ConfigMapmetadataannotationskubectl.kubemetes.io/last-applied-confi
36、guration:apiVersion,fvl,data,config.yam*,healthzPort8080nresyncPeriod:CreationTimestamp:2022-07-06T14:44:34Zname:hci-controller-confignamespace:mec-imagesresourceversion:18229389uid:3de8bcfc-f87d-4be5-9c85-d84198866133在HarbO呛库中的镜像有kubevirtfedora36,创建EVM时采用该镜像：# kubectlcreate-fevm-registry-fedora.yam
37、l# catevm-registry-fedora.yamlapiVersion:mececsio/vlbetalkind:EnhancedVirtuaIMachinemetadataname:ecs-registry-fedoranamespace:wq-testspectemplate:specrunning:truetemplate:metadatalabels:kubevitiovm:ecs-registry-fedoraannotationsovn.kubemetes.io/allow_live_migration:trueKcf.ionetworks:mec-nets/attach
38、netlattachnetl.mec-nets.ovn.kubemetes.io/logical_switch:subnet-ipv4attachnetl.mec-nets.ovn.kubemetes.io/default_route:trueattachnetLmec-nets.ovn.kubemetes.io/allow_live_migration:truespecdomain:cpu:sockets:4cores:1threads:1memory:guest8192Miclock:timezone:Asia/Shanghaitimerrtcpresenttruedevices:disk
39、s:- disk:bus:virtioname:cloudindiskinterfaces:- bridge:name:attachnetlresources:requests:cpu:2memory:2048MidnsPolicy:NonednsConfig:nameservers:- 114.114.114.114options:- name:ndotsvalue:5hostname:ecs-registry-fedoranetworks:-name:attachnetlmuhs:networkName:mec-nets/attachnetlvolumes:-name:Cloudinitd
40、iskCloudInitNoCIoud:userData:-#cloud-configpassword:fedorassh_pwauth:Truechpasswd:expire:Falsesource:registrylmageURL:kubevirt/fedora36:latestbtVolume:resources:requests:storage:IOGi创建成功，EVM可正常访问。#kubectlgetevmecs-registry-fedora-nwq-testNAMEAGEecs-registry-fedora3hlm#kubectlgetvmecs-registry-fedora
41、-nwq-testNAMEAGESTATUSREADYecs-registry-fedora3hlmRunningTrue#kubectlgetvmiecs-registry-fedora-nwq-testNAMEAGEPHASEIPNODENAMEREADYecs-registry-fedora3hlmRunning192.168.100.26ecs8True2.3存储管理2.3.1KataContainer使用卷的存储直通模式本项优化是为了提高使用Kata作为容器运行时提高CePhrbd作为磁盘时的IO性能。原有挂载是储存卷（RBDimage）挂载到宿主机的目录中，然后通过Virtio-f
42、s协议，将存储卷的内容共享到KataCOntainer中。如下图所示：可以添加卷直通功能，分为半直通（块宜通）和全直通（rbd直通）两个模式。其中半直通如下图所示，去掉了中间的协议Virtio-fs,将映射到宿主机上面的块设备通过qmp命令直接添加到了KaIaContainer+,KataComainer再通过moum块设备进行内容的读写。全直通如下图所示，进一步的去掉了挂载到宿主机上面的动作，将rbdimage直接通过qmp指令作为块设备添加到了KataContainer，KataContainer再通过mount块设备进行内容的读写。卷直通功能是否开启通过PVC的annotations进行
43、控制。在PVC的annotations中添加了volume.katacontainers.iodirect-mode1Ko1 .当VOlUme.katacontainers.iodirect-mode值为“block”时，为半直通模式；2 .当VOlUme.katacontainers.iodirect-modeS为rbd时，为全直通模式；3 .在字段的值不为上述两个或者不添加该字段时为原有模式。直通模式，通过kubectlexec-itcentos-blk-test-bash进入到对应容器后可以看到对应的块设备且对应的FiIeSyStem不为none:rootdeployersimple-t
44、est#kubectlexec-itcentos-blk-test-bashrootcentos-bIk-test/#df-hFilesystemSizeUSedAvai1Use%Mountedondevsdb4.9G265M4.4G6%tmpfs64M064M0%devtmpfs998M0998M0%sys/fs/cgroupdev/sdc2.OG6.OM1.9Gl%databddevsdd2.OG6.OM1.9G1%/data-blockshm998M0998M0%devshmrootentos-blk-testftlsblkNAMEMAJiMINRMSIZEROTYPEMOlNTPOIN
45、Tsda8:005G0disksdb8:1605G0disk/sdc8:3202G0diskdata-bdsdd8:4802G0diskdata-blockpmem0259:00382M1disk-pmempl259:10380M1part半直通模式，创建Pod之前通过ISbIk查看hosl的块设备信息，如果为半直通则创建完Pod之后host会多出来一个rbd的块设备ErootQhostlSbIkNAMEMAJiMINRMSIZEROTYPEMOUNTPOINTsr11:O1486K0romrbdl25kl602G0diskvda252:005060disk-vdal252:1050G0par
46、t/2.3.2KataContainer和OpenEBS适配优化本项优化是为了提高使用Kata作为容器运行时提高OPenEBS作为磁盘时的I。性能。OPenEBS8是一种开源云原生存储解决方案,托管于CNCF基金会。OPenEBS是K8s本地超融合存储解决方案，它管理节点可用的本地存储，并为有状态工作负载提供本地或高可用的分布式持久卷。OPenEBS支持两大类卷，本地卷和复制卷。管理员和开发人员可以使用kubectl、Helm、Prometheus.Grafana.WeaveSCoPe等K8s可用的工具来交互和管理OPenEBS。为了实现KataContainer使用OPenEBS的本地卷直通
47、方式，修改OPenEBS的IVm-IoCaIPV直通的实现。OPenEBS的CSInodeDriver主要功能包括挂载、卸载、扩容和状态获取四项：1. NodePublishVolume:格式化块设备并将块设备挂载SJtargetPath。2. NodeUnPublishVolume:将块设备从targetPath隹曦。3. NodeExpandVoIume:4. NodeGetVoIumeStats:获取卷的使用t奇兄。修改方案依赖PVCannotations实现是否为直通卷的判断，在CSl中针对上述四项功能分别对kata进行适配：1.NodePublishVolume:a.通过annota
