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

《边缘云原生虚拟化研究报告2024.docx》由会员分享，可在线阅读，更多相关《边缘云原生虚拟化研究报告2024.docx（28页珍藏版）》请在优知文库上搜索。

1、前言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 nBSaaBAS. JD工 叫*空基网反方,4. JS有其电&向iW条，僖.1 .进能省利：进聚邺顿万份行业研、If理方案及其 也学习费;*Z 每日分享：6f行女恰是、3个行业主题a 掖含有词：密里宜桂咨囱,免费杪吃忘找4 产RL含：仅成行止报告交

2、诵.Iht一切无关信息知识星球行业与管理资源专业知螟壮薛：银月分享3000份行业研犬界告、导拉计划、中场第充.企业这拿支专迩管理方案等.其差*4技、金融.般肓、互联河.为电产、生衬凯若像行佗货等：己成为仅资、产业研究、企业用富、价值传格等工作毗手.参与单位（排名不分先后）：中国联合网络通信有限公司研究院，中国联合网络通信有限公司智网创新中心、可信边缘计算推进计划编写人：黄蓉庞博黄倩陈丹肖羽蔡超侯迎龙隗英英高沛李晓旭隋佳良王蕴婷李昂1技术与需求概述随着网络技术和云技术的发展，边缘计算得到了广泛的应用。边缘计算可以解决高可靠低延迟的设备接入和海量数据的实时计算问题，云技术有力的保障和推动了边缘计算

3、的应用。1.1 虚拟机和容器虚拟机和容器是云计算中最常用到的应用部署和运行方式。虚拟机是伴随着虚拟化的技术出现的，容器则云原生技术的典型特征之一，他们的架构对比如下图所示：虚拟机1虚拟机N应用1应用n应用1应用m容器1容黜容器n薛文件库文件应用1应用2应用n客户机操作系统客户机操作系统库文件库文件库文件图1:虚拟机与容器架构对比图如上图所示，虚拟化技术一般通过虚拟化层（hypervisor）来实现,通过虚拟化技术,虚拟机可以共享物理机的CPU、内存、IO等硬件资源，并在逻辑上实现相互隔离。每一个虚拟机都拥有独立的操作系统（客户机操作系统），所以虚拟机不依赖于宿主机操作系统，其安全性和隔离性更强

4、。但是虚拟机占用的资源较多，而且由于要模拟硬件，虚拟化层本身也会占用部分资源，对宿主机性能有一定的消耗。比较而言，容器则是使用宿主机的内核系统加上自身的文件系统。运行容器时是在使用宿主机的内核情况下加载文件系统，一般可以将容器看作是在内核上运行的独立进程。而精简的文件系统可以小到100MB以内，因此容器比虚拟机占用资源的更少、启动速度更快。容器缺点是隔离性不如虚拟机，而且由于依赖宿主机内核，所以容器的操作系统选择一般会受到限制。两种技术的特点对比如下表：表1:虚拟机与容器技术特点对比对比项虚拟机技术容器技术安全隔离性强，操作系统级别弱，进程级又指主机操作系统依赖无有,需要相同操作系统内核启动时

5、间慢，分钟级快，秒级磁盘占用大（GB）小（MB）虚拟化性能损耗大I小1.2 OpenStack与Kubemetes从运行和管理平台来看，OPenStaCk2与KUbemetes（K8s尸分别是对虚拟机和容器进行运行和管理的典型开源项目。OPenStaCk是开源的云计算平台，利用虚拟化技术和底层存储服务，提供了可扩展、灵活、适应性强的云计算服务。OPenStaCk的服务分为核心功能和非核心功能。核心功能是指运行OPenStaCk系统必须的功能的组件，包括：Keystone（身份识S明踪）、Glance（镜像B踪）、Nova（计算棚艮务）、Neutron（网络服务）、Cinder（块存储服务）、S

6、wift（对象存储服务）、Horizon（控制面板务）.三阪心功能指的是实现附加功能的组件，如Ceilometer（测量功能）、Heat（部署编排）、Trove（数据库服务）等。OPenStaCk的各个组件（服务）之间使用标准的API接口调用，减少了服务之间的依赖。下图是OpenStack的逻辑架构图。KnSlackL UrtiW,OpnSud IdrntthAFlOpmStxfc Urmffyr API图2:OpenStack逻W图KUberneteS是容器管理编排引擎，可以自动完成容器的部署、管理和扩展等操作，部署KUbemeteS的设备环境通常被成为Kubernetes集群。Kubern

7、etes集群逻辑上可以分为两个部分：控制平面与计算设备（瞬为节点）OJS!lS5fi5:kube-apiserver（接邙踞,ffi=4B里内甑的脚请求）、kube-scheduler（调度程序）、kube-controller-manager（集群控制管理程序）、etcd（数据库）。计算设备包含容器运行时引擎、kubelet（节点代理程序）、kube-proxy（网络谴程序）。KUberneteS的设计原则包括：安全、易于使用和可扩展。KUberneteS同样遵循标准化APl接口，而且KUbemeteS实现了CNI（容器网络接口）、CRI（容器运行时接口）、CSI（容器存储接口）等接口和CR

8、D（用户自定义资源）等，便于实现功能的扩展。下图是Kubernetes的逻辑架构图。Kubernetes clusterControl planekube-apiserverkube-schedulerkube-controller-manager(2etCompute machineskubeletkube-proxyContainer runtimePod ContainersPersistantstorageiContainerregistryUnderlying infrastructurePhysicalVirtualPrivatePublicHybrid图3:Kubernetes逻

9、辑架构图OpenStack的设计比较全面，组件众多，部署相对复杂，难于运维，使用成本较高，更适合作为大规模云的管理系统。相对而言，Kubernetes的设计更加简洁，其核心组件少，便于运维，同时K8s的生态很庞大，可以很方便地对其进行扩展或者定制，更适用于资源受限的边缘环境。1.3 融合管理的演进：K8s环境下运行虚拟机当前，通过容器部署的应用越来越广泛。但是，通过虚拟机部署的应用也会存在相当长的时间。首先，有不少现存的应用程序是运行在虚拟机上的，其中一些程序无法轻松地进行容器化重构。其次，即便对程序进行容器化改造，之后的系统调试和问题定位又会带来很大的挑战，尤其是对于通信行业来说，多代通信设

10、备并存，对设备和应用程序的稳定性要求又非常高，对原有的应用程序进行容器化改造的成本和风险都是较大的。最后，一些应用或者场景更加适合使用虚拟机来进行部署。比如下面这些场景更适合使用虚拟机来运行而不是容器：* NFV(networkfunctionvirtualization)网络功能颜化的场景：将传统的网元团以化，使用虚拟机会比使用容器更方便，因为容器在接入多网卡方面比起虚拟机的能力来说还有一定的差距；* 大模型的研发测试：大模型在研发测试阶段进场需要使用多张GPU协同配合，同时要安装很多多软件依赖包来进行调试和使用，这时直接将多张GPU挂载到一个虚拟机里，然后在虚拟机里来实验开发要比在容器里方

11、便很多；* 数据库：不是所有的数据库都适合放在容器里运行，比如部分数据库的特定算法需要限制IP的变化，在虚拟机里部署可以有一个固定的IP,会更加方便；* 很多进程的应用：在容器使用上，有个核心概念就是部署任务单一的进程，比如一个简单的叩i服务进程加一个日志收集的进程组合成为了一个容器，有些多进程的应用就不适合放在容器中运行了。于是，随着时间推移，企业会遇到这样的情况，有些应用还是只能运行在虚拟机上，有些应用已经完成了容器化，企业管理员不得不同时运维管理多套平台，这大大增加了运维的难度：* 计算资源：从管理角度来说计算资源的管理不同的平台的管理方法也是截然不同的，比如OpenStackSgapr

12、qjectquota来窗里,而K8s贝UiffiSrequest/Iimit来,员必学蜂全了麒篇几制才能完全很好的管理起来；* 网络资源：同样，对于网络管理来说，不同的平台也是完全不同的，K8s使用CNI来管理网络，同时OPenStaCk通过neutron来管理网络，他们的使用理念上也是截然不同的,这样很大程度上增加了学习成本；* 监控/日志：各种平台都有自己的完整的监控/日志收集系统，它们会占用大量的计算、存储和网络资源，同时部署这样2套平台，从资源使用的角度上来说也是一种很大的浪费；* 存储资源：相同的存储资源对接K8s和OPenStaCk方式都是截然不同的，出现问题后找根因的思路和角度也

13、都是不一样的，这样也大大加大了运维的成本和难度。* 安全风险：软件是由不同工程师编写的代码，运行在不同的操作系统上，每个环境都会遇到安全漏洞，越多组件则面临更多的安全漏洞，同时运维2套平台就意味着面临安全漏洞也会更多,企业面临的安全风险也就更大。从各个方面来看，企业内部的虚拟机平台和容器平台合并成为同一套平台来进行管理是一个趋势。那么是将K8s合并到OPenStaCk呢?还是反过来呢？业内也在研究虚拟机和容器的共平台的部署和管理，从OPenStaCk和K8s各自的发展来看，两个平台也在进行虚拟机和容器共同管理的探索，比如OPenStaCk的ZUn服务将容器作为一种OPenStaCk资源来进行管

14、理，并通过集成OPenStaCk的其他服务，为用户呈现统一的、简化的APl接口，用户可以通过这些接口来创建、管理容器；K8s也有多个相关的开源项目在研究如何实现对虚拟机的管理（见下文）。从云技术的现状和发展来看，容器的应用越来越广泛，而且K8s在容器编排领域成为了业内事实上的标准。在边缘环境下，K8s的适用范围也更加广泛，因此，本文将进一步探讨在K8s环境下运行虚拟机的技术和实践范例。1.4 开源项目简介本节介绍在K8s环境下运行虚拟机的相关开源项目。当前这些项目还在发展之中，功能还在不断地迭代和完善。1.4.1 KubeVirtKUbeVirt4是一个K8s插件，由Redhat开源，云原生计

15、算基金会（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形式部署在每一节点上，负责节点上的每个虚拟机实例状态变化，一旦检测到状态的变化