邊緣云原生虛擬化研究報告

II前言 III1技術(shù)與需求概述 11.1虛擬機(jī)和容器 1 1.3融合管理的演進(jìn)：K8s環(huán)境下運(yùn)行虛擬機(jī) 31.4開源項目簡介 42技術(shù)實踐 92.1生命周期管理 92.2鏡像管理 2.3存儲管理 2.4網(wǎng)絡(luò)能力 11技術(shù)與需求概述隨著網(wǎng)絡(luò)技術(shù)和云技術(shù)的發(fā)展，邊緣計算得到了廣泛的應(yīng)用。邊緣計算可以解決高可靠低延遲的設(shè)備接入和海量數(shù)據(jù)的實時計算問題，云技術(shù)有力的保障和推動了邊緣計算的應(yīng)用。1.1虛擬機(jī)和容器虛擬機(jī)和容器是云計算中最常用到的應(yīng)用部署和運(yùn)行方式。虛擬機(jī)是伴隨著虛擬化的技術(shù)出現(xiàn)的，容器則云原生技術(shù)的典型特征之一，他們的架構(gòu)對比如下圖所示：圖1:虛擬機(jī)與容器架構(gòu)對比圖如上圖所示，虛擬化技術(shù)一般通過虛擬化層(hypervisor)來實現(xiàn)，通過虛擬化技術(shù)，虛擬機(jī)可以共享物理機(jī)的CPU、內(nèi)存、IO等硬件資源，并在邏輯上實現(xiàn)相互隔離。每一個虛擬機(jī)都擁有獨(dú)立的操作系統(tǒng)(客戶機(jī)操作系統(tǒng)),所以虛擬機(jī)不依賴于宿主機(jī)操作系統(tǒng)，其安全性和隔離性更強(qiáng)。但是虛擬機(jī)占用的資源較多，而且由于要模擬硬件，虛擬化層本身也會占用部分資源，對宿主機(jī)性能有一定的消耗。比較而言，容器則是使用宿主機(jī)的內(nèi)核系統(tǒng)加上自身的文件系統(tǒng)。運(yùn)行容器時是在使用宿主機(jī)的內(nèi)核情況下加載文件系統(tǒng)，一般可以將容器看作是在內(nèi)核上運(yùn)行的獨(dú)立進(jìn)程。而精簡的文件系統(tǒng)可以小到100MB以內(nèi)，因此容器比虛擬機(jī)占用資源的更少、啟動速度更快。容器缺點(diǎn)是隔離性不如虛擬機(jī)，而且由于依賴宿主機(jī)內(nèi)核，所以容器的操作系統(tǒng)選擇一般會受到限制。兩種技術(shù)的特點(diǎn)對比如下表：表1:虛擬機(jī)與容器技術(shù)特點(diǎn)對比強(qiáng)，操作系統(tǒng)級別弱，進(jìn)程級別無啟動時間快，秒級磁盤占用大(GB)大1小從運(yùn)行和管理平臺來看，OpenStack2與Kubernetes(K8s)3分別是對虛擬機(jī)和容器進(jìn)行運(yùn)行和管理的典型開源項目。OpenStack是開源的云計算平臺，利用虛擬化技術(shù)和底層存儲服務(wù)，提供了可擴(kuò)展、靈活、適應(yīng)性2(網(wǎng)絡(luò)服務(wù))、Cinder(塊存儲服務(wù))、Swift(對象存儲服務(wù))、Horizon(控制面板服務(wù))。非核心功能指的是實現(xiàn)附加功能的組件，如Ceilometer(測量功能)、Heat(部署等。OpenStack的各個組件(服務(wù))之間使用標(biāo)準(zhǔn)的API接口調(diào)用，減少了服務(wù)之間的依賴。-Command-lineinterfaces(nova,neutron,swift,etc)-CloudManagementTools(Rightscale,Enstrati-GUltools(Dashboard,Cyberduck,iPhoneage⑥0Kubernetes是容器管理編排引擎，可以自動完成容器的部署、管理和擴(kuò)展等操作，部署Kubernetes (調(diào)度程序)、kube-controller-manager(集群控制管理程序)、etcd(數(shù)據(jù)庫)。計算設(shè)備包含容器運(yùn)行時引擎、kubelet(節(jié)點(diǎn)代理程序)、kube-proxy(網(wǎng)絡(luò)代理程序)。Kubernetes的設(shè)計原則包括：安全、易于使用和可擴(kuò)展。Kubernetes同樣遵循標(biāo)準(zhǔn)化API接口，而且Kubernetes實現(xiàn)了CNI(容器網(wǎng)絡(luò)接口)、CRI(容器運(yùn)行時接口)、CSI(容器存儲接口)等接口和CRD(用戶自定義資源)等，便于3*大模型的研發(fā)測試：大模型在研發(fā)測試階段進(jìn)場需要使用多張GPU協(xié)同配合，同時要安裝很多多*數(shù)據(jù)庫：不是所有的數(shù)據(jù)庫都適合放在容器里運(yùn)4*很多進(jìn)程的應(yīng)用：在容器使用上，有個核心概念就是部署任務(wù)單一的進(jìn)程，比如一個簡單的api服務(wù)進(jìn)程加一個日志收集的進(jìn)程組合成為了一個容器，有些多進(jìn)程的應(yīng)用就不適合放在容器中運(yùn)行了。于是，隨著時間推移，企業(yè)會遇到這樣的情況，有些應(yīng)用還是只能運(yùn)行在虛擬機(jī)上，有些應(yīng)用已經(jīng)完成了容器化，企業(yè)管理員不得不同時運(yùn)維管理多套平臺，這大大增加了運(yùn)維的難度：*計算資源：從管理角度來說計算資源的管理不同的平臺的管理方法也是截然不同的，比如才能完全很好的管理起來；*網(wǎng)絡(luò)資源：同樣，對于網(wǎng)絡(luò)管理來說，不同的平臺也是完全不同的，K8s使用CNI來管理網(wǎng)絡(luò)，同時OpenStack通過neutron來管理網(wǎng)絡(luò)，他們的使用理念上也是截然不同的，這樣很大程度上增加了學(xué)習(xí)成本；*監(jiān)控/日志：各種平臺都有自己的完整的監(jiān)控/日志收集系統(tǒng)，它們會占用大量的計算、存儲和網(wǎng)絡(luò)資源，同時部署這樣2套平臺，從資源使用的角度上來說也是一種很大的浪費(fèi)；*存儲資源：相同的存儲資源對接K8s和OpenStack方式都是截然不同的，出現(xiàn)問題后找根因的思路和角度也都是不一樣的，這樣也大大加大了運(yùn)維的成本和難度。*安全風(fēng)險：軟件是由不同工程師編寫的代碼，運(yùn)行在不同的操作系統(tǒng)上，每個環(huán)境都會遇到安全漏洞，越多組件則面臨更多的安全漏洞，同時運(yùn)維2套平臺就意味著面臨安全漏洞也會更多，企業(yè)面臨的安全風(fēng)險也就更大。從各個方面來看，企業(yè)內(nèi)部的虛擬機(jī)平臺和容器平臺合并成為同一套平臺來進(jìn)行管理是一個趨勢。業(yè)內(nèi)也在研究虛擬機(jī)和容器的共平臺的部署和管理，從OpenStack和K8s各自的發(fā)展來看，兩個平臺管理，并通過集成OpenStack的其他服務(wù)，為用戶呈現(xiàn)統(tǒng)一的、簡化的API接口，用戶可以通過這些接口來創(chuàng)建、管理容器；K8s也有多個相關(guān)的開源項目在研究如何實現(xiàn)對虛擬機(jī)的管理（見下文）。從云技術(shù)的現(xiàn)狀和發(fā)展來看，容器的應(yīng)用越來越廣泛，而且K8s在容器編排領(lǐng)域成為了業(yè)內(nèi)事實上的標(biāo)準(zhǔn)。在邊緣環(huán)境下，K8s的適用范圍也更加廣泛，因此，本文將進(jìn)一步探討在K8s環(huán)境下運(yùn)行虛擬機(jī)的技術(shù)和實踐范例。1.4開源項目簡介本節(jié)介紹在K8s環(huán)境下運(yùn)行虛擬機(jī)的相關(guān)開源項目。當(dāng)前這些項目還在發(fā)展之中，功能還在不斷地迭代和完善。插件可以在K8s平臺上調(diào)度傳統(tǒng)的虛擬機(jī)。KubeVirt使用自定義資源（CRD）將VM管理接口接入到K8s中，通過一個Pod去使用libvirtd管理VM的方式，實現(xiàn)Pod與VM的一一對應(yīng)，做到如同容器一般去管理虛擬機(jī)，并且做到與容器一樣的資源管理、調(diào)度規(guī)劃。KubeVirt的架構(gòu)圖如下。5virt-controller:virt-controller會根據(jù)VMICRD,生成對應(yīng)的virt-launcherPod,并且維護(hù)CRD的狀態(tài)。例狀態(tài)變化，一旦檢測到狀態(tài)的變化，會進(jìn)行響應(yīng)并且確保相應(yīng)的操作能夠達(dá)到所需(理想virt-launcher:每個virt-launcherPod對應(yīng)著一個VMI,kubelet只負(fù)責(zé)virt-launcherPod運(yùn)行狀態(tài)，不啟動VMI,隨著Pod的生命周期結(jié)束，virt-lanuncher也會去通知VMI去執(zhí)行終止操作；其次在每個virt-launcherPod中還對應(yīng)著一個libvirtd,virt-launcher通過libvirtVirtualMachinelnstance(VMI):類似于KubernetesPod,是管理虛擬機(jī)的最小資源。一個擬機(jī)，確保虛擬機(jī)實例的啟動狀態(tài)，與虛擬機(jī)實例是1:1的關(guān)系，類似與spec.replica為1的VirtualMachinelnstanceReplicaSet:類似R61.虛擬機(jī)創(chuàng)建：創(chuàng)建VM對象，并同步創(chuàng)建DataVolume/PVC,從Harbor鏡像倉庫中拉取系統(tǒng)模板鏡像拷貝至目標(biāo)調(diào)度主機(jī)，通過調(diào)度、IP分配后生成VMI以及管理VM的LauncherPod從而啟動供業(yè)務(wù)使用的2.虛擬機(jī)運(yùn)行：運(yùn)行狀態(tài)下的VM可以進(jìn)行控制臺管理、快照備份/恢復(fù)、熱遷移、磁盤熱掛載/熱刪除等操作，此外還可以進(jìn)行重啟、下電操作，提高VM安全的同時解決業(yè)務(wù)存儲空間需求和主機(jī)異常Hung3.虛擬機(jī)關(guān)機(jī)：關(guān)機(jī)狀態(tài)下的VM可以進(jìn)行快照備份/恢復(fù)、冷遷移、CPU/MEM規(guī)格變更、重命名以及磁盤掛載等操作，同時可通過重新啟動進(jìn)入運(yùn)行狀態(tài)，也可刪除進(jìn)行資源回收。4.虛擬機(jī)刪除：對虛機(jī)資源進(jìn)行回收，但VM所屬的磁盤數(shù)據(jù)仍將保留、具備恢復(fù)條件。KataContainer?社區(qū)由OpenStackFoundation(OSF)領(lǐng)導(dǎo)，KataContainer是一個開放源代碼的容器，運(yùn)行時可以構(gòu)建無縫插入容器生態(tài)系統(tǒng)的輕量級虛擬機(jī)，通過輕量級虛擬機(jī)來構(gòu)建安全的容器，這些虛擬機(jī)的運(yùn)行方式和性能類似于容器，但是使用硬件虛擬化技術(shù)作為第二程防御層，可以提供更強(qiáng)的工作負(fù)載隔離。相較于普通的容器技術(shù)，KataContainer的優(yōu)點(diǎn)如下：√安全：在專用的內(nèi)核中運(yùn)行，提供網(wǎng)絡(luò)，IO和內(nèi)存的隔離，并可以通過虛擬化擴(kuò)展利用硬件強(qiáng)制隔離?！碳嫒菪裕褐С中袠I(yè)標(biāo)準(zhǔn)，包括開放容器格式、KubernetesCRI等?！绦阅埽禾峁┡c標(biāo)準(zhǔn)Liunx容器一致的性能?！毯唵危阂子诩珊褪褂?。圖5:KataContainer架構(gòu)圖kata-agent:在虛擬機(jī)內(nèi)kata-agent作為一個daemon進(jìn)程運(yùn)行，并拉起一個或多個容器的進(jìn)程。kata-agent使用VIRTIO或VSOCK接口(QEMU在主機(jī)上暴露的socket文件)在guest虛擬機(jī)中運(yùn)行g(shù)RPC服務(wù)器。kata-runtime通過grpc協(xié)議與kata-agent通信，向kata-agent發(fā)送管理容器的命令。該協(xié)議還用于容器和管理引擎(例如DockerEngine)之間傳送I/O流(stdout,stderr,stdin)。容器內(nèi)所有的執(zhí)行命令和相關(guān)的IO流都需要通過QEMU在宿主機(jī)暴露的virtio-serial或vsock接口，當(dāng)使用VIRTIO的情況下，每個虛擬機(jī)會創(chuàng)建一個KataContainersproxy(kata-proxy)來處理命令和IO流。7kata-proxy:kata-proxy提供方式是使用virtio-serial或vsShim:kata-shim類似Docker的containerd-shim或CRI-O的conmon,主要用來監(jiān)控和回收容器的進(jìn)發(fā)展到了KataShimV2(containerd-shim-(ShimAPI)Kube-OVN?是一款CNCF旗下的企業(yè)級云原生網(wǎng)絡(luò)編排系統(tǒng)，將SDN8ovn-central:Deployment運(yùn)行OVN的管理平面組件，包括ovn-nb、ovn-sb和ovn-northd。多個·ovn-nb:保存虛擬網(wǎng)絡(luò)配置，并提供API進(jìn)行虛擬網(wǎng)絡(luò)管理。kube-ovn-controller將會主要和ovs-ovn:ovs-ovn以DaemonSet形式運(yùn)行在每個節(jié)點(diǎn)，在Pod內(nèi)運(yùn)行了openvswitch、ovsdb和該部分為Kube-OVN的核心組件，作為OVN和Kubernetes之間的一個橋梁，將兩個系統(tǒng)打通并將網(wǎng)9kube-ovn-monitor:該組件為一個Deployment收集OVN的運(yùn)行信息，收集的監(jiān)控指標(biāo)可參考*改進(jìn)的實現(xiàn)：首先使用了1.27x版本的特性Pod原地擴(kuò)容的特性(Podin-placeVPA)先將外部的Harbor鏡像倉庫地址為：harbor.mec.local,首先通過kubectl命令進(jìn)行配置：#kubectlgetcm-nmec-imageshci-con#kubectleditcm-nmec-imageshci-controller-c創(chuàng)建成功，EVM可正常訪問。#kubectlgetvmecs-registry-feecs-registry-fedora#kubectlgetvmiecs-registry-fedora原有掛載是儲存卷(RBDimage)掛載到宿主機(jī)的目錄中可以添加卷直通功能，分為半直通(塊直通)和全直通(rbd直通)兩個模式。全直通如下圖所示，進(jìn)一步的去掉了掛載到宿主機(jī)上面的動作，將rbdimage直接通過qmp指令作為塊設(shè)備添加到了KataContainer中，KataContainer再通過mount塊設(shè)備進(jìn)行內(nèi)容的讀寫。直通模式，通過kubectlexec-itcentos-blk-test--bash進(jìn)入到對應(yīng)容器后可以看到對應(yīng)的塊設(shè)備且對應(yīng)的Filesystem不為none:[root@deployersimple-teroot@centos-blk-testFilesystemSizeUsedAvailUse%Mountedon[root@centos-blk-teNAMEMAJ:MINRMSIZEROTYPEMOUNT半直通模式，創(chuàng)建Pod之前通過lsblk查看host的塊設(shè)備信息，如果為半直通則創(chuàng)建完P(guān)od之后host會多出來一個rbd的塊設(shè)備NAMEMAJ:MINRMSIZEROTYPEMOUNT本項優(yōu)化是為了提高使用Kata作為容器運(yùn)行時提高OpenEBS作為磁盤時的IO性能。OpenEBS8是一種開源云原生存儲解決方案，托管于CNCF基金會。OpenEBS是K8s本地超融合存儲解決方案，它管理節(jié)點(diǎn)可用的本地存儲，并為有狀態(tài)工作負(fù)載提供本地或高可用的分布式持久卷。OpenEBS修改方案依賴PVCannotations實現(xiàn)是否為直通卷的判斷，在CSI中針對上述四項功能分別對kata進(jìn)?適配：b.通過targetPath目錄下的文件判斷該直通卷是否已經(jīng)掛載，已經(jīng)掛載則直接重新調(diào)用c.如果未掛載則先對塊設(shè)備進(jìn)?格式化（OpenEBS通過調(diào)用K8s的庫實現(xiàn)格式化并掛載publishVolume階段可以獲取到，其他階段無法獲取并在文件中寫?掛載狀態(tài)；b.如果為直通卷則在使用lvextend對文件系統(tǒng)進(jìn)?擴(kuò)容；2.4網(wǎng)絡(luò)能力DPDK是X86平臺報文快速處理的庫和驅(qū)動的集合，不是網(wǎng)絡(luò)協(xié)議棧，不提供二層，三層轉(zhuǎn)發(fā)功能，不具備防?墻ACL功能，但通過DPDK可以輕松的開發(fā)出上述功能。DPDK的優(yōu)勢在于，可以將用戶態(tài)的數(shù)據(jù)，不經(jīng)過內(nèi)核直接轉(zhuǎn)發(fā)到網(wǎng)卡，實現(xiàn)加速目的。DPDK加速的OVS與原始OVS的區(qū)別在于，從OVS社區(qū)方案里，虛擬機(jī)/容器不能利用DPDK技術(shù)來提高網(wǎng)絡(luò)的流量，本節(jié)描述的解決方案中加入使用DPDK技術(shù)來讓虛擬機(jī)網(wǎng)絡(luò)包可以直接通過userspace來交互通訊，大大提高的了可以處理的網(wǎng)絡(luò)流量。②n圖10:DPDK加速的OVSDPDK加速的OVS數(shù)據(jù)流轉(zhuǎn)發(fā)的大致流程如下：1.0VS的ovs-vswitchd接收到從OVS連接的某個網(wǎng)絡(luò)端口發(fā)來的數(shù)據(jù)包，從數(shù)據(jù)包中提取源/目的IP、源/目的MAC、端口等信息。2.0VS在用戶態(tài)查看精確流表和模糊流表，如果命中，則直接轉(zhuǎn)發(fā)。3.如果不命中，在SDN控制器接入的情況下，經(jīng)過OpenFlow協(xié)議，通告給控制器，由控制器處理。4.控制器下發(fā)新的流表，該數(shù)據(jù)包重新發(fā)起選路、匹配和報文轉(zhuǎn)發(fā)?？偨Y(jié)：主要區(qū)別在于流表的處理，普通OVS流表轉(zhuǎn)發(fā)在內(nèi)核態(tài)，而OVS-DPDK流表轉(zhuǎn)發(fā)在用戶態(tài)。查看Pod,vmi可正常啟動：NAMEREADYSTATUSRESTARTSvirt-launcher-vm-dpdk-6nrqt2/2Running03m1查看OVS-DPDK創(chuàng)建了vmi對應(yīng)的vhostuserclientport(ede503eO_net2_h)340aee64-le86-486a-a99e-樣也為了提高虛擬機(jī)/容器的網(wǎng)絡(luò)性能，SRIOV技術(shù)可以將一張物理網(wǎng)卡變?yōu)槿舾蓚€虛擬的物理網(wǎng)卡，并直接接入虛擬機(jī)/容器從而提高網(wǎng)絡(luò)性能。內(nèi)核編譯Container中，不能通過啟動時加載驅(qū)動模塊，所以需要在編譯kernel時將需要的驅(qū)動模塊通過配置編譯到內(nèi)核文件中。Kata提供編譯腳本和內(nèi)核配置模板，可以修改配置文件或者通進(jìn)?修改。因為模塊間的依賴和互斥關(guān)系相當(dāng)復(fù)雜，建議通過makemenuconfig啟動圖形界面來開啟下列模塊：Mellanox驅(qū)動安裝需要依賴kernel-header模塊，所以需要提前準(zhǔn)備和鏡像制作系統(tǒng)相同內(nèi)核的在第一步的內(nèi)核文件夾使用下列命令可以生成.deb的包。#安裝編譯需要的軟件和庫......#運(yùn)行DPDK相關(guān)應(yīng)用......2.4.3開啟IPv4v6雙棧功能開啟雙棧可以讓K8s平臺上的虛擬機(jī)/容器能夠同時支持ipv4/ipv6（可選）雙協(xié)議棧。虛擬機(jī)開啟K8s啟用雙棧要啟用IPv4v6雙協(xié)議棧，需要為集群的相關(guān)組件啟用IPv6DualStack特性，并且設(shè)置雙協(xié)議棧的集群......在Kube-ovn的安裝腳本中打開對IPv4v6雙棧的支持。開啟雙棧部署好Koube-ovn后，在配置?網(wǎng)雙棧時，需要設(shè)置?網(wǎng)CIDR格式為cidr=<IPv4正常指定?網(wǎng)啟動Pod。......Pod可以正常獲取IPv4和IPv6地址，并且路由正常。..................OVN邏輯網(wǎng)關(guān)和邏輯路由配置正常。....................在宿主機(jī)上查看ovn0網(wǎng)絡(luò)正常。...............................................社區(qū)實現(xiàn)的虛擬機(jī)網(wǎng)卡熱插拔的方式不符合用戶的使用習(xí)慣，本節(jié)描述的方法可以給用戶更好的界面體驗。本節(jié)新開發(fā)了一個CRD叫做NicPort，該CRD的每個實