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

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

1、前 言III1技术与需求概述11.1 虚拟机和容器11.2 OpenStack 与 Kubernetes11.3 融合管理的演进：K8s环境下运行虚拟机31.4 开源项目简介42技术实践92.1 生命周期管理92.2 镜像管理102.3 存储管理132.4 网络能力15L 本内等率里/仓内,2. 1强七奈Jr互耽网K开勤警I Xf3. IIlB暂近HO人W. 5c 用房空”或反方4. R-其经樗鼻马天，倡.行业报告资源群MB1珀长晦*敛I.进菸理利：蜜能即领万份行业研、管理方案及其 也学习货源，曼度打包下我Z 每日分享；6伤行生情迂、3个行业主题a 报含多询I群里盲卷咨询,免费协鲂秀找4.产修

2、L吉：仅限行业报告交谦,禁止一切无关信息知识星球行业与管理资源E门国仃无忧专业知馍社酢：每月分享8000+侪行业诉先报告、我蛀计划、 市场研究.企业运营及咨询管理方案等.建英斗技、金曜、 收青、互联网,为电产、生物断药、匿行使曦獐：已成为投 突、产业研竞、企业运营、价叁传播等工作助手.参与单位（排名不分先后）：中国联合网络通信有限公司研究院，中国联合网络通信有限公司智网 创新中心、可信边缘计算推进计划编写人：黄蓉庞博黄倩 陈丹肖羽 蔡超 侯迎龙 隗英英 高沛 李晓旭 隋佳良王蕴婷 李昂1技术与需求概述随着网络技术和云技术的发展，边缘计算得到了广泛的应用。边缘计算可以解决高可靠低延迟的设 备接入

3、和海量数据的实时计算问题，云技术有力的保障和推动了边缘计算的应用。1.1虚拟机和容器虚拟机和容器是云计算中最常用到的应用部署和运行方式。虚拟机是伴随着虚拟化的技术出现的， 容器则云原生技术的典型特征之一，他们的架构对比如下图所示：虚拟机1应用1 应用n障文件客户机操作系统虚拟机N应用1 应用m库文件客户机操作系统容器1容器2容器n应用1应用2应用n库文件库文件库文件虚拟化层容器引擎宿主机操作系统硬件容器架构宿主机操作系统硬件虚拟机架构图1:虚拟机与容器架构对比图如上图所示，虚拟化技术一般通过虚拟化层(hypervisor)来实现，通过虚拟化技术，虚拟机可以 共享物理机的CPU、内存、IO等硬件

4、资源，并在逻辑上实现相互隔离。每一个虚拟机都拥有独立的操 作系统(客户机操作系统)，所以虚拟机不依赖于宿主机操作系统，其安全性和隔离性更强。但是虚拟 机占用的资源较多，而且由于要模拟硬件，虚拟化层本身也会占用部分资源，对宿主机性能有一定的消 耗。比较而言，容器则是使用宿主机的内核系统加上自身的文件系统。运行容器时是在使用宿主机的内 核情况下加载文件系统，一般可以将容器看作是在内核上运行的独立进程。而精简的文件系统可以小到 IOOMB以内，因此容器比虚拟机占用资源的更少、启动速度更快。容器缺点是隔离性不如虚拟机，而 且由于依赖宿主机内核，所以容器的操作系统选择一般会受到限制。两种技术的特点对比如

5、下表：表1 :虚拟机与容器技术特点对比对比项虚拟机技术容器技术安全隔离性强，操作系统级别弱，进程级SU对宿生机操作系统依赖无有，需要相同操作系统内核启动时间慢，中级快，级磁盘占用大(GB)J( MB)虚拟化性能损耗大小1.2 OpenStack 与 Kubernetes从运行和管理平台来看，OPenStack?与KUbemetes( K8s ) 3分别是对虚拟机和容器进行运行和管理 的典型开源项目。OPenStaCk是开源的云计算平台，利用虚拟化技术和底层存储服务，提供了可扩展、灵活、适应性强的云计算服务。OPerlStaCk的服务分为核心功能和非核心功能。核心功能是指运行OPerlStaCk

6、系统必 须的功能的组件，包括：Keystone （身份识服务）、Glance （镜像服务）、Nova （计算机服务）、Neutron （网络服务）、Cinder （块存储服务）、Swift （对象存储服务）、Horizon （控制面板服务）。非核心功 能指的是实现附加功能的组件,如Ceilometer （测量功能）、Heat （部署编排）、Trove （数据库服务） 等。OpenStack的各个组件（服务）之间使用标准的API接口调用,减少了服务之间的依赖。下图是OpenStack的逻辑架构图。gfl (omwd c mfcs now, wfrc*, wift. etc)Hp Ooud Mnr

7、mp! jpk IAightv iIr. fntrjtJu et GUI IodS DMhbMfd1 (FbefA iPw dem, K()HTThSl0Surt MAQfSefMctQPrnsUCh kktn, ARQ9cnStKk Ek Stojgr APIHnP向 (Omlutr 5,Mm APIOpcoSh IdrntnyAPI图2 : OpenStack逻辑架构图KUbemeteS是容器管理编排引擎，可以自动完成容器的部署、管理和扩展等操作，部署KUbeITleteS 的设备环境通常被成为Kubernetes集群。Kubernetes集群逻辑上可以分为两个部分：控制平面与计算设 备（

8、或称为节点）。控制平面的包含：kube-apiserver （接口程序，用于处理内部的陪晴求）、kube-scheduler （调度程序）、kube-contr。IIer-manager（集群控制管理程序）、etcd（数据库）。计算设备包含容器运 行时引擎、kubelet （节点代理程序）、kube-proxy （网络代理程序）。KUbeITleteS的设计原则包括：安 全、易于使用和可扩展。Kubernetes同样遵循标准化API接口 ,而且Kubernetes实现了 CNI （容器网络 接口）、CRI （容器运行时接口）、CSI （容器存储接口）等接口和CRD （用户自定义资源）等，便于

9、实现功能的扩展。下图是Kubernetes的逻辑架构图。Kubernetes clusterControl planeCompute machineskube-apiserverkube-schedulerkube-controller-manager(j etcdkubeletkube-proxyContainer runtimePodContainersUnderlying infrastructurePhysicalVirtualPrivatePuMkHybridPersistantstorage昌Container registry图3 : Kubernetes逻辑触勾图OpenSta

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

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

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

13、StaCk是通过ProjeCtqUta来管理，而K8s则通过request/Iimi俅管理，管理人员必须完全了解2套机制 才能完全很好的管理起来；* 网络资源：同样，对于网络管理来说，不同的平台也是完全不同的，K8s使用CNl来管理网络， 同时OPerlStaCk通过neutron来管理网络，他们的使用理念上也是截然不同的，这样很大程度上增加了学 习成本；* 监控/日志：各种平台都有自己的完整的监控/日志收集系统，它们会占用大量的计算、存储和网 络资源，同时部署这样2套平台，从资源使用的角度上来说也是一种很大的浪费；* 存储资源：相同的存储资源对接K8s和OPenStaCk方式都是截然不同的，

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

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