《可信邊緣計算推進計劃：2024邊緣云原生虛擬化研究報告（31頁）.pdf》由會員分享，可在線閱讀，更多相關《可信邊緣計算推進計劃：2024邊緣云原生虛擬化研究報告（31頁）.pdf（31頁珍藏版）》請在三個皮匠報告上搜索。

1、I邊緣云原生虛擬化研究報告2024 年 1 月可信邊緣計算推進計劃II目次前言.III1 技術與需求概述.11.1 虛擬機和容器.11.2 OpenStack 與 Kubernetes.11.3 融合管理的演進：K8s 環境下運行虛擬機.31.4 開源項目簡介.42 技術實踐.92.1 生命周期管理.92.2 鏡像管理.102.3 存儲管理.132.4 網絡能力.15III前言參與單位（排名不分先后）：中國聯合網絡通信有限公司研究院，中國聯合網絡通信有限公司智網創新中心、可信邊緣計算推進計劃編寫人：黃蓉 龐博 黃倩 陳丹 肖羽 蔡超 侯迎龍 隗英英 高沛 李曉旭 隋佳良 王蘊婷 李昂11技術與

2、需求概述隨著網絡技術和云技術的發展，邊緣計算得到了廣泛的應用。邊緣計算可以解決高可靠低延遲的設備接入和海量數據的實時計算問題，云技術有力的保障和推動了邊緣計算的應用。1.1虛擬機和容器虛擬機和容器是云計算中最常用到的應用部署和運行方式。虛擬機是伴隨著虛擬化的技術出現的，容器則云原生技術的典型特征之一，他們的架構對比如下圖所示：圖 1：虛擬機與容器架構對比圖如上圖所示，虛擬化技術一般通過虛擬化層（hypervisor）來實現，通過虛擬化技術，虛擬機可以共享物理機的 CPU、內存、IO 等硬件資源，并在邏輯上實現相互隔離。每一個虛擬機都擁有獨立的操作系統（客戶機操作系統），所以虛擬機不依賴于宿主機

3、操作系統，其安全性和隔離性更強。但是虛擬機占用的資源較多，而且由于要模擬硬件，虛擬化層本身也會占用部分資源，對宿主機性能有一定的消耗。比較而言，容器則是使用宿主機的內核系統加上自身的文件系統。運行容器時是在使用宿主機的內核情況下加載文件系統，一般可以將容器看作是在內核上運行的獨立進程。而精簡的文件系統可以小到100MB 以內，因此容器比虛擬機占用資源的更少、啟動速度更快。容器缺點是隔離性不如虛擬機，而且由于依賴宿主機內核，所以容器的操作系統選擇一般會受到限制。兩種技術的特點對比如下表：表 1：虛擬機與容器技術特點對比對比項虛擬機技術容器技術安全隔離性強，操作系統級別弱，進程級別對宿主機操作系統

4、依賴無有，需要相同操作系統內核啟動時間慢，分鐘級快，秒級磁盤占用大（GB）?。∕B）虛擬化性能損耗大1小1.2OpenStack 與 Kubernetes從運行和管理平臺來看，OpenStack2與 Kubernetes（K8s）3分別是對虛擬機和容器進行運行和管理的典型開源項目。OpenStack 是開源的云計算平臺，利用虛擬化技術和底層存儲服務，提供了可擴展、靈活、適應性2強的云計算服務。OpenStack 的服務分為核心功能和非核心功能。核心功能是指運行 OpenStack 系統必須的功能的組件，包括：Keystone（身份識別服務）、Glance（鏡像服務）、Nova（計算機服務）、N

5、eutron（網絡服務）、Cinder（塊存儲服務）、Swift（對象存儲服務）、Horizon（控制面板服務）。非核心功能指的是實現附加功能的組件，如 Ceilometer（測量功能）、Heat（部署編排）、Trove（數據庫服務）等。OpenStack 的各個組件（服務）之間使用標準的 API 接口調用，減少了服務之間的依賴。下圖是 OpenStack 的邏輯架構圖。圖 2：OpenStack 邏輯架構圖Kubernetes 是容器管理編排引擎，可以自動完成容器的部署、管理和擴展等操作，部署 Kubernetes的設備環境通常被成為 Kubernetes 集群。Kubernetes 集群邏

6、輯上可以分為兩個部分：控制平面與計算設備（或稱為節點）?？刂破矫娴陌簁ube-apiserver（接口程序，用于處理內部和外部請求）、kube-scheduler（調度程序）、kube-controller-manager（集群控制管理程序）、etcd（數據庫）。計算設備包含容器運行時引擎、kubelet（節點代理程序）、kube-proxy（網絡代理程序）。Kubernetes 的設計原則包括：安全、易于使用和可擴展。Kubernetes 同樣遵循標準化 API 接口，而且 Kubernetes 實現了 CNI（容器網絡接口）、CRI（容器運行時接口）、CSI（容器存儲接口）等接口和 C

7、RD（用戶自定義資源）等，便于實現功能的擴展。下圖是 Kubernetes 的邏輯架構圖。3圖 3：Kubernetes 邏輯架構圖OpenStack 的設計比較全面，組件眾多，部署相對復雜，難于運維，使用成本較高，更適合作為大規模云的管理系統。相對而言，Kubernetes 的設計更加簡潔，其核心組件少，便于運維，同時 K8s 的生態很龐大，可以很方便地對其進行擴展或者定制，更適用于資源受限的邊緣環境。1.3融合管理的演進：K8s 環境下運行虛擬機當前，通過容器部署的應用越來越廣泛。但是，通過虛擬機部署的應用也會存在相當長的時間。首先，有不少現存的應用程序是運行在虛擬機上的，其中一些程序無法

8、輕松地進行容器化重構。其次，即便對程序進行容器化改造，之后的系統調試和問題定位又會帶來很大的挑戰，尤其是對于通信行業來說，多代通信設備并存，對設備和應用程序的穩定性要求又非常高，對原有的應用程序進行容器化改造的成本和風險都是較大的。最后，一些應用或者場景更加適合使用虛擬機來進行部署。比如下面這些場景更適合使用虛擬機來運行而不是容器：*NFV（network function virtualization）網絡功能虛擬化的場景：將傳統的網元虛擬化，使用虛擬機會比使用容器更方便，因為容器在接入多網卡方面比起虛擬機的能力來說還有一定的差距；*大模型的研發測試：大模型在研發測試階段進場需要使用多張GP

9、U協同配合，同時要安裝很多多軟件依賴包來進行調試和使用，這時直接將多張GPU掛載到一個虛擬機里，然后在虛擬機里來實驗開發要比在容器里方便很多；*數據庫：不是所有的數據庫都適合放在容器里運行，比如部分數據庫的特定算法需要限制IP的變化，在虛擬機里部署可以有一個固定的IP，會更加方便；4*很多進程的應用：在容器使用上，有個核心概念就是部署任務單一的進程，比如一個簡單的api服務進程加一個日志收集的進程組合成為了一個容器，有些多進程的應用就不適合放在容器中運行了。于是，隨著時間推移，企業會遇到這樣的情況，有些應用還是只能運行在虛擬機上，有些應用已經完成了容器化，企業管理員不得不同時運維管理多套平臺，

10、這大大增加了運維的難度：*計算資源：從管理角度來說計算資源的管理不同的平臺的管理方法也是截然不同的，比如OpenStack是通過project quota來管理，而K8s則通過request/limit來管理，管理人員必須完全了解2套機制才能完全很好的管理起來；*網絡資源：同樣，對于網絡管理來說，不同的平臺也是完全不同的，K8s使用CNI來管理網絡，同時OpenStack通過neutron來管理網絡，他們的使用理念上也是截然不同的，這樣很大程度上增加了學習成本；*監控/日志：各種平臺都有自己的完整的監控/日志收集系統，它們會占用大量的計算、存儲和網絡資源，同時部署這樣2套平臺，從資源使用的角度

11、上來說也是一種很大的浪費；*存儲資源：相同的存儲資源對接K8s和OpenStack方式都是截然不同的，出現問題后找根因的思路和角度也都是不一樣的，這樣也大大加大了運維的成本和難度。*安全風險：軟件是由不同工程師編寫的代碼，運行在不同的操作系統上，每個環境都會遇到安全漏洞，越多組件則面臨更多的安全漏洞，同時運維2套平臺就意味著面臨安全漏洞也會更多，企業面臨的安全風險也就更大。從各個方面來看，企業內部的虛擬機平臺和容器平臺合并成為同一套平臺來進行管理是一個趨勢。那么是將K8s合并到OpenStack呢？還是反過來呢？業內也在研究虛擬機和容器的共平臺的部署和管理，從OpenStack和K8s各自的發

12、展來看，兩個平臺也在進行虛擬機和容器共同管理的探索，比如OpenStack的zun服務將容器作為一種OpenStack資源來進行管理，并通過集成OpenStack的其他服務，為用戶呈現統一的、簡化的API接口，用戶可以通過這些接口來創建、管理容器；K8s也有多個相關的開源項目在研究如何實現對虛擬機的管理（見下文）。從云技術的現狀和發展來看，容器的應用越來越廣泛，而且K8s在容器編排領域成為了業內事實上的標準。在邊緣環境下，K8s的適用范圍也更加廣泛，因此，本文將進一步探討在K8s環境下運行虛擬機的技術和實踐范例。1.4開源項目簡介本節介紹在K8s環境下運行虛擬機的相關開源項目。當前這些項目還在

13、發展之中，功能還在不斷地迭代和完善。1.4.1KubeVirtKubeVirt4是一個K8s插件，由Redhat開源，云原生計算基金會（CNCF）贊助的開源項目。KubeVirt插件可以在K8s平臺上調度傳統的虛擬機。KubeVirt使用自定義資源（CRD）將VM管理接口接入到K8s中，通過一個Pod去使用libvirtd管理VM的方式，實現Pod與VM的一一對應，做到如同容器一般去管理虛擬機，并且做到與容器一樣的資源管理、調度規劃。KubeVirt的架構圖如下。5圖4：KubeVirt架構圖KubeVirt主要由下列五個部分組成：virt-api：kubevirt是以CRD形式去管理VM P

14、od，virt-api就是所有虛擬化操作的入口，這里面包括常規的CDR更新驗證、以及console、vm start、stop等操作。virt-controller：virt-controller會根據VMI CRD，生成對應的virt-launcher Pod，并且維護CRD的狀態。與K8s的api-server通訊監控VMI資源的創建刪除等狀態。virt-handler：virt-handler會以deamonset形式部署在每一個節點上，負責監控節點上的每個虛擬機實例狀態變化，一旦檢測到狀態的變化，會進行響應并且確保相應的操作能夠達到所需（理想）的狀態。virt-handler還會保持集

15、群級別VMI Spec與相應libvirt域之間的同步；報告libvirt域狀態和集群Spec的變化；調用以節點為中心的插件以滿足VMI Spec定義的網絡和存儲要求。virt-launcher：每個virt-launcher Pod對應著一個VMI，kubelet只負責virt-launcher Pod運行狀態，不會去關心VMI創建情況。virt-handler會根據CRD參數配置去通知virt-launcher去使用本地的libvirtd實例來啟動VMI，隨著Pod的生命周期結束，virt-lanuncher也會去通知VMI去執行終止操作；其次在每個virt-launcher Pod中還對

16、應著一個libvirtd，virt-launcher通過libvirtd去管理VM的生命周期，不再是以前的虛擬機架構那樣一個libvirtd去管理多個VM。virtctl：virtctl是kubevirt自帶類似kubectl的命令行工具，它是越過virt-launcher Pod這一層去直接管理VM虛擬機，可以控制VM的start、stop、restart。KubeVirt利用CRD的功能定義了若干種資源對象。VirtualMachineInstance（VMI）：類似于 Kubernetes Pod，是管理虛擬機的最小資源。一個VirtualMachineInstance 對象即表示一臺正

17、在運行的虛擬機實例，包含一個虛擬機所需要的各種配置。VirtualMachine（VM）：為群集內的 VirtualMachineInstance 提供管理功能，例如開機/關機/重啟虛擬機，確保虛擬機實例的啟動狀態，與虛擬機實例是 1:1 的關系，類似與 spec.replica 為 1 的StatefulSet。VirtualMachineInstanceMigrations：提供虛擬機遷移的能力，雖然并不會指定具體遷移的目的節點，但要求提供的存儲支持 RWX 讀寫模式。VirtualMachineInstanceReplicaSet：類似ReplicaSet，可以啟動指定數量的 Virtu

18、alMachineInstance，并且保證指定數量的 VirtualMachineInstance 運行，可以配置 HPA。KubeVirt虛擬機生命周期管理主要分為以下幾種狀態：61.虛擬機創建：創建VM對象，并同步創建DataVolume/PVC，從Harbor鏡像倉庫中拉取系統模板鏡像拷貝至目標調度主機，通過調度、IP分配后生成VMI以及管理VM的Launcher Pod從而啟動供業務使用的VM。2.虛擬機運行：運行狀態下的VM可以進行控制臺管理、快照備份/恢復、熱遷移、磁盤熱掛載/熱刪除等操作，此外還可以進行重啟、下電操作，提高VM安全的同時解決業務存儲空間需求和主機異常Hung等問

19、題。3.虛擬機關機：關機狀態下的VM可以進行快照備份/恢復、冷遷移、CPU/MEM規格變更、重命名以及磁盤掛載等操作，同時可通過重新啟動進入運行狀態，也可刪除進行資源回收。4.虛擬機刪除：對虛機資源進行回收，但VM所屬的磁盤數據仍將保留、具備恢復條件。1.4.2Kata ContainerKata Container5社區由 OpenStack Foundation（OSF）領導，Kata Container 是一個開放源代碼的容器，運行時可以構建無縫插入容器生態系統的輕量級虛擬機，通過輕量級虛擬機來構建安全的容器，這些虛擬機的運行方式和性能類似于容器，但是使用硬件虛擬化技術作為第二程防御層，

20、可以提供更強的工作負載隔離。相較于普通的容器技術，Kata Container 的優點如下：安全：在專用的內核中運行，提供網絡，I/O 和內存的隔離，并可以通過虛擬化擴展利用硬件強制隔離。兼容性：支持行業標準，包括開放容器格式、Kubernetes CRI 等。性能：提供與標準 Liunx 容器一致的性能。簡單：易于集成和使用。圖5：Kata Container架構圖Kata Container主要由由如下幾部分組成：kata-agent：在虛擬機內kata-agent作為一個daemon進程運行，并拉起一個或多個容器的進程。kata-agent使用VIRTIO或VSOCK接口（QEMU在主機

21、上暴露的socket文件）在guest虛擬機中運行gRPC服務器。kata-runtime通過grpc協議與kata-agent通信，向kata-agent發送管理容器的命令。該協議還用于容器和管理引擎（例如Docker Engine）之間傳送I/O流（stdout，stderr，stdin）。容器內所有的執行命令和相關的IO流都需要通過QEMU在宿主機暴露的virtio-serial或vsock接口，當使用VIRTIO的情況下，每個虛擬機會創建一個Kata Containers proxy(kata-proxy)來處理命令和IO流。7kata-runtime：Kata Containers

22、runtime(kata-runtime)通過QEMU/KVM技術創建了一種輕量型的虛擬機，兼容 OCI runtime specification 標準，支持Kubernetes的Container Runtime Interface(CRI)接口，可替換CRIshim runtime(runc)通過K8s來創建Pod或容器。kata-proxy：kata-proxy提供了 kata-shim 和 kata-runtime 與VM中的kata-agent通信的方式，其中通信方式是使用virtio-serial或vsock，默認是使用virtio-serial。Shim：kata-shim類似

23、Docker的 containerd-shim 或CRI-O的 conmon，主要用來監控和回收容器的進程，kata-shim需要處理所有的容器的IO流（stdout,stdin and stderr）和轉發相關信號。當前Kata Container發展到了Kata Shim V2（containerd-shim-kata-v2）版本，實現了Containerd Runtime V2(Shim API)，集成了kata-runtime、kata-shim、kata-proxy的功能，所以架構圖中不再包含這幾部分。其演進方式如下圖所示。圖6：Kata Shim V2演進圖Hypervisor：k

24、ata-container通過QEMU/KVM來創建虛擬機給容器運行，可以支持多種hypervisors。1.4.3Kube-OVNKube-OVN6是一款CNCF旗下的企業級云原生網絡編排系統，將SDN的能力和云原生結合，提供豐富的功能，極致的性能以及良好的可運維性。Kube-OVN可提供跨云網絡管理、傳統網絡架構與基礎設施的互聯互通、邊緣集群落地等復雜應用場景的能力支持，解除Kubernetes網絡面臨的性能和安全監控的掣肘，為基于Kubernetes架構原生設計的系統提供成熟的網絡底座，提升用戶對Kubernetes生態Runtime的穩定性和易用性。Kube-OVN的設計原則和思路是，

25、平移OpenStack網絡的概念和功能到Kubernetes。OpenStack的網絡已經發展了很多年，很多設計和概念也基本成了SDN的標準。Kube-OVN通過引入高級功能和成熟的網絡概念，從整體上增強Kubernetes網絡的能力，并通過OVN實現網絡的數據平面，簡化維護工作。Kube-OVN 的組件可以大致分為三類：上游OVN/OVS組件。核心控制器和Agent。監控，運維工具和擴展組件。8圖7：Kube-OVN架構圖上游上游OVN/OVSOVN/OVS組件組件該類型組件來自OVN/OVS社區，并針對Kube-OVN的使用場景做了特定修改。OVN/OVS本身是一套成熟的管理虛機和容器的S

26、DN系統。Kube-OVN使用OVN的北向接口創建和調整虛擬網絡，并將其中的網絡概念映射到Kubernetes之內。ovn-central：Deployment運行OVN的管理平面組件，包括ovn-nb、ovn-sb和ovn-northd。多個ovn-central實例通過Raft協議同步數據保證高可用。ovn-nb：保存虛擬網絡配置，并提供 API 進行虛擬網絡管理。kube-ovn-controller 將會主要和ovn-nb 進行交互配置虛擬網絡。ovn-sb：保存從 ovn-nb 的邏輯網絡生成的邏輯流表，以及各個節點的實際物理網絡狀態。ovn-northd：將 ovn-nb 的虛擬網

27、絡翻譯成 ovn-sb 中的邏輯流表。ovs-ovn：ovs-ovn以DaemonSet形式運行在每個節點，在Pod內運行了openvswitch、ovsdb和ovn-controller。這些組件作為ovn-central的Agent將邏輯流表翻譯成真實的網絡配置。核心控制器和核心控制器和 AgentAgent該部分為Kube-OVN的核心組件，作為OVN和Kubernetes之間的一個橋梁，將兩個系統打通并將網絡概念進行相互轉換。kube-ovn-controller：該組件為一個Deployment執行所有Kubernetes內資源到OVN資源的翻譯工作，其作用相當于整個Kube-OVN

28、系統的控制平面。kube-ovn-controller監聽了所有和網絡功能相關資源的事件，并根據資源變化情況更新OVN內的邏輯網絡。主要監聽的資源包括：Pod、Service、Endpoint、Node、NetworkPolicy、VPC、Subnet、Vlan、ProviderNetwork。kube-ovn-cni：該組件為一個DaemonSet運行在每個節點上，實現CNI接口，并操作本地的OVS配置單機網絡。kube-ovn-cni會配置具體的網絡來執行相應流量操作。監控，運維工具和擴展組件監控，運維工具和擴展組件該部分組件主要提供監控，診斷，運維操作以及和外部進行對接，對Kube-OV

29、N的核心網絡能力進行擴展，并簡化日常運維操作。kube-ovn-speaker：該組件為一個DaemonSet運行在特定標簽的節點上，對外發布容器網絡的路由，使得外部可以直接通過Pod IP訪問容器。9kube-ovn-pinger：該組件為一個DaemonSet運行在每個節點上收集OVS運行信息，節點網絡質量，網絡延遲等信息，收集的監控指標可參考Kube-OVN監控指標。kube-ovn-monitor：該組件為一個Deployment收集OVN的運行信息，收集的監控指標可參考Kube-OVN監控指標。kubectl-ko：該組件為kubectl插件，可以快速運行常見運維操作。2技術實踐本章

30、通過一些典型地范例介紹對于在K8s環境下運行虛擬機的功能增強的技術實踐。2.1生命周期管理2.1.1在 K8s 環境下實現虛擬機熱調整資源在K8s中啟動的虛擬機都是在一個Pod里面運行著libvirtd和qemu等依賴組件，這樣kube-scheduler不需要感知Pod里是一個虛擬機還是一個容器，都按照統一的方式進行管理。既然虛擬機運行在了K8s平臺上，那么我們管理虛擬有可以通過kubectl進行管理。創建虛擬機創建虛擬機通過kubectl create-f vm1.yaml直接通過一個yaml文件來創建一個虛擬機。更新虛擬機更新虛擬機通過kubectl edit vm-n namespac

31、e1即會打開一個vim編輯器，讓用戶直接可以修改虛擬機的yaml文件。刪除虛擬機刪除虛擬機通過kubectl delete vmvm1-n namespace1來刪除在namespace1下的一個虛擬機vm1。虛擬機熱調整資源虛擬機熱調整資源由于K8s最近的版本已經支持Pod原地擴容了，可以利用了這個功能，實現kubevirt的虛擬機的cpu和memory熱添加的功能，社區目前只支持cpu的熱插。*社區的熱擴容的實現：社區目前之實現了通過了live migration（熱遷移）功能來實現的，這樣的實現依賴虛擬機是否可以進行熱遷移，比如虛擬機如果有gpu掛載的話，就不能實現熱遷移，也就不能熱擴容

32、。10圖8：社區版熱擴容*改進的實現：首先使用了1.27.x版本的特性Pod原地擴容的特性(Pod in-place VPA)先將外部的virt-launcher Pod的limit調整到期望的大小，然后再調用libvirt api去擴容虛擬機到期望的大小。圖9：改進版虛擬機熱擴容2.2鏡像管理2.2.1從 Harbor 鏡像倉庫拉取鏡像在容器云平臺啟動虛擬機，那么虛擬機鏡像最好是能和容器鏡像一起管理，避免增加不必要的管理成本，所以可以將制作好的虛擬機鏡像偽裝成為了一個容器鏡像存放在Harbor中，這樣就不用單獨管理虛擬機的鏡像了。Harbor7是由VMware公司開源的企業級的Docker

33、Registry管理項目，它包括權限管理(RBAC)、LDAP、日志審核、管理界面、自我注冊、鏡像復制和中文支持等功能。Harbor鏡像倉庫地址為：harbor.mec.local，首先通過kubectl命令進行配置：#kubectl get cm-n mec-images hci-controller-config-o yaml#kubectl edit cm-n mec-images hci-controller-config-o yamlapiVersion:v1data:config.yaml:|healthzPort:8080resyncPeriod:10mleaderElectio

34、n:leaderElect:trueleaseDuration:30srenewDeadline:15sresyncPeriod:5s11resourceName:hci-controllerresourceLock:endpointsleasesresourceNamespace:mec-imagescontrollerConfig:baseImageNamespace:mec-imagessnapshotClass:csi-rbdplugin-snapclass#name of VolumeSnapshotClassglanceBaseURL:https:/172.18.22.100:92

35、92registryAddr:registryAddr:harbor.mec.localharbor.mec.localkind:ConfigMapmetadata:annotations:kubectl.kubernetes.io/last-applied-configuration:|apiVersion:v1,data:config.yaml:healthzPort:8080nresyncPeriod:creationTimestamp:2022-07-06T14:44:34Zname:hci-controller-confignamespace:mec-imagesresourceVe

36、rsion:18229389uid:3de8bcfc-f87d-4be5-9c85-d84198866133在Harbor倉庫中的鏡像有 kubevirt/fedora36，創建EVM時采用該鏡像：#kubectl create-f evm-registry-fedora.yaml#cat evm-registry-fedora.yamlapiVersion:mececs.io/v1beta1kind:EnhancedVirtualMachinemetadata:name:ecs-registry-fedoranamespace:wq-testspec:template:spec:runnin

37、g:truetemplate:metadata:labels:kubevirt.io/vm:ecs-registry-fedoraannotations:ovn.kubernetes.io/allow_live_migration:trueKcf.io/networks:mec-nets/attachnet1attachnet1.mec-nets.ovn.kubernetes.io/logical_switch:subnet-ipv4attachnet1.mec-nets.ovn.kubernetes.io/default_route:trueattachnet1.mec-nets.ovn.k

38、ubernetes.io/allow_live_migration:truespec:domain:cpu:sockets:4cores:1threads:112memory:guest:8192Miclock:timezone:Asia/Shanghaitimer:rtc:present:truedevices:disks:-disk:bus:virtioname:cloudinitdiskinterfaces:-bridge:name:attachnet1resources:requests:cpu:2memory:2048MidnsPolicy:NonednsConfig:nameser

39、vers:-114.114.114.114options:-name:ndotsvalue:5hostname:ecs-registry-fedoranetworks:-name:attachnet1multus:networkName:mec-nets/attachnet1volumes:-name:cloudinitdiskcloudInitNoCloud:userData:|-#cloud-configpassword:fedorassh_pwauth:Truechpasswd:expire:False source:registryImageURL:registryImageURL:k

40、ubevirt/fedora36:latestkubevirt/fedora36:latestbootVolume:resources:requests:storage:10Gi創建成功，EVM可正常訪問。#kubectl get evm ecs-registry-fedora-n wq-test13NAMEAGEecs-registry-fedora 3h1m#kubectl get vm ecs-registry-fedora-n wq-testNAMEAGESTATUSREADYecs-registry-fedora 3h1m Running True#kubectl get vmi e

41、cs-registry-fedora-n wq-testNAMEAGEPHASEIPNODENAME READYecs-registry-fedora 3h1m Running 192.168.100.26 ecs8True2.3存儲管理2.3.1Kata Container 使用卷的存儲直通模式本項優化是為了提高使用Kata作為容器運行時提高Ceph rbd作為磁盤時的IO性能。原有掛載是儲存卷（RBD image）掛載到宿主機的目錄中，然后通過virtio-fs協議，將存儲卷的內容共享到Kata Container中。如下圖所示：可以添加卷直通功能，分為半直通（塊直通）和全直通（rbd 直

42、通）兩個模式。其中半直通如下圖所示，去掉了中間的協議virtio-fs，將映射到宿主機上面的塊設備通過qmp命令直接添加到了Kata Container中，Kata Container再通過mount塊設備進內容的讀寫。全直通如下圖所示，進步的去掉了掛載到宿主機上面的動作，將rbd image直接通過qmp指令作為塊設備添加到了Kata Container中，Kata Container再通過mount塊設備進內容的讀寫。14卷 直 通 功 能 是 否 開 啟 通 過 PVC 的 annotations 進 控 制。在 PVC 的 annotations 中 添 加 了volume.katac

43、ontainers.io/direct-mode字段。1.當volume.katacontainers.io/direct-mode值為“block”時，為半直通模式；2.當volume.katacontainers.io/direct-mode值為“rbd”時，為全直通模式；3.在字段的值不為上述兩個或者不添加該字段時為原有模式。直通模式，通過kubectl exec-it centos-blk-test-bash進到對應容器后可以看到對應的塊設備且對應的Filesystem不為 none：rootdeployer simple-test#kubectl exec-it centos-blk

44、-test-bashrootcentos-blk-test/#df-hFilesystem Size Used Avail Use%Mounted on/dev/sdb 4.9G 265M 4.4G 6%/tmpfs 64M 0 64M 0%/devtmpfs 998M 0 998M 0%/sys/fs/cgroup/dev/sdc/dev/sdc 2.0G2.0G 6.0M6.0M 1.9G1.9G 1%1%/data-rbd/data-rbd/dev/sdd/dev/sdd 2.0G2.0G 6.0M6.0M 1.9G1.9G 1%1%/data-block/data-blockshm 9

45、98M 0 998M 0%/dev/shmrootcentos-blk-test/#lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsda 8:0 0 5G 0 disksdb 8:16 0 5G 0 disk/sdcsdc 8:328:32 0 0 2G2G 0 0 diskdisk/data-rbd/data-rbdsddsdd 8:488:48 0 0 2G2G 0 0 diskdisk/data-block/data-blockpmem0 259:0 0 382M 1 disk-pmem0p1 259:1 0 380M 1 part半直通模式，創

46、建Pod之前通過lsblk查看host的塊設備信息，如果為半直通則創建完Pod之后host會多出來個rbd的塊設備roothost1#lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsr0 11:0 1 486K 0 romrbd1rbd1 251:16251:16 0 0 2G2G 0 0 diskdiskvda 252:0 0 50G 0 diskvda1 252:1 0 50G 0 part/152.3.2Kata Container 和 OpenEBS 適配優化本項優化是為了提高使用Kata作為容器運行時提高OpenEBS作為磁盤時的IO性能。O

47、penEBS8是一種開源云原生存儲解決方案，托管于CNCF基金會。OpenEBS是K8s本地超融合存儲解決方案，它管理節點可用的本地存儲，并為有狀態工作負載提供本地或高可用的分布式持久卷。OpenEBS支持兩大類卷，本地卷和復制卷。管理員和開發人員可以使用kubectl、Helm、Prometheus、Grafana、Weave Scope等K8s可用的工具來交互和管理OpenEBS。為了實現Kata Container使用OpenEBS的本地卷直通方式，修改OpenEBS的lvm-localpv直通的實現。OpenEBS的CSI nodeDriver主要功能包括掛載、卸載、擴容和狀態獲取四項

48、：1.NodePublishVolume：格式化塊設備并將塊設備掛載到targetPath。2.NodeUnPublishVolume：將塊設備從targetPath卸載。3.NodeExpandVolume：對volume進行擴容。4.NodeGetVolumeStats：獲取卷的使用情況。修改方案依賴PVC annotations實現是否為直通卷的判斷，在CSI中針對上述四項功能分別對 kata進適配：1.NodePublishVolume：a.通過annotations判斷是否為直通卷；b.通過targetPath目錄下的文件判斷該直通卷是否已經掛載，已經掛載則直接重新調用kata-ru

49、ntime direct-volume add 即可（重啟后kata-runtime add創建的文件會消失）；c.如果未掛載則先對塊設備進格式化（OpenEBS通過調用K8s的庫實現格式化并掛載）；d.格式化完成后調用kata-runtime direct-volume add命令；e.在targetPath創建個文件用于判斷是否為直通卷（因為annotations只會在stageVolume、publishVolume階段可以獲取到，其他階段無法獲?。?，并在文件中寫掛載狀態；2.NodeUnPublishVolume：a.通過targetPath目錄下的文件判斷是否為直通卷；b.如果為直通

50、卷則調用kata-runtime direct-volume delete命令進刪除；3.NodeExpandVolume：a.通過targetPath目錄下的文件判斷是否為直通卷；b.如果為直通卷則在使用lvextend對文件系統進擴容；c.待塊設備擴容完成后調用kata-runtime direct-volume resize命令調整大??；4.NodeGetVolumeStats：a.通過targetPath目錄下的文件判斷是否為直通卷；b.如果為直通卷則調用kata-runtime direct-volume stats命令獲取volume狀態。2.4網絡能力2.4.1DPDK 加速的

51、OVSDPDK是X86平臺報文快速處理的庫和驅動的集合，不是網絡協議棧，不提供二層，三層轉發功能，不具備防墻ACL功能，但通過DPDK可以輕松的開發出上述功能。DPDK的優勢在于，可以將用戶態的數據，不經過內核直接轉發到網卡，實現加速目的。DPDK加速的OVS與原始OVS的區別在于，從OVS連接的某個網絡端口接收到的報文不需要openvswitch.ko內核態的處理，報文通過DPDK PMD驅動直接到達用戶態ovs-vswitchd里。社區方案里，虛擬機/容器不能利用DPDK技術來提高網絡的流量，本節描述的解決方案中加入使用DPDK技術來讓虛擬機網絡包可以直接通過user space來交互通訊

52、，大大提高的了可以處理的網絡流量。16圖10：DPDK加速的OVSDPDK加速的OVS數據流轉發的大致流程如下：1.OVS的ovs-vswitchd接收到從OVS連接的某個網絡端口發來的數據包，從數據包中提取源/目的IP、源/目的MAC、端口等信息。2.OVS在用戶態查看精確流表和模糊流表，如果命中，則直接轉發。3.如果不命中，在SDN控制器接的情況下，經過OpenFlow協議，通告給控制器，由控制器處理。4.控制器下發新的流表，該數據包重新發起選路、匹配和報文轉發?？偨Y：主要區別在于流表的處理，普通OVS流表轉發在內核態，而OVS-DPDK流表轉發在用戶態。查看Pod,vmi可正常啟動：#k

53、ubectl get PodNAME READY STATUS RESTARTS AGEvirt-launcher-vm-dpdk-6nrqt 2/2 Running 0 3m13s#kubectl get vmi-ANAMEAGEPHASEIPNODENAME READYvm-dpdk3m9s Running 172.18.22.173node173True查看OVS-DPDK創建了vmi對應的vhostuserclient port（ede503e0_net2_h）：#kubectl ko vsctl node173 show340aee64-1e86-486a-a99e-a62481e9

54、d67aBridge br-intfail_mode:securedatapath_type:netdevPort 1e9da8d5d0d7_hInterface 1e9da8d5d0d7_hPort ovn0Interface ovn0type:internalPort 43d5339cda9a_hInterface 43d5339cda9a_h17Port 99e85593750e_hInterface 99e85593750e_hPort d6653a5bbdc2_hInterface d6653a5bbdc2_hPort ede503e0_net2_hInterfaceInterfac

55、e ede503e0_net2_hede503e0_net2_htype:type:dpdkvhostuserclientdpdkvhostuserclientoptions:vhost-serverpath=/var/run/openvswitch/vhost_sockets/578dd327-f9ba-4a1b-8bd3-1a55351e07ab/vhostuser-sockets/net22.4.2Kata Container 使用 SR-IOV 設備并運行 DPDK 應用Kata Container默認采用QEMU作為hypervisor，而QEMU不支持veth，所以一般默認方案是采

56、用TAP來為VM內外打通網絡。本節展示在K8s環境下Kata Container使用Mellanox的設備并運行DPDK應用的能力。本項優化同樣是為了提高網絡流量，同DPDK技術一樣，SRIOV（single root IO virtualization)技術同樣也為了提高虛擬機/容器的網絡性能，SRIOV技術可以將一張物理網卡變為若干個虛擬的物理網卡，并直接接入虛擬機/容器從而提高網絡性能。內核編譯內核編譯通常linux啟動時先加載kernel，再加載initrd.img，initrd.img通常被用來加載驅動模塊。但是在KataContainer中，不能通過啟動時加載驅動模塊，所以需要在編

57、譯kernel時將需要的驅動模塊通過配置編譯到內核文件中。Kata提供編譯腳本和內核配置模板，可以修改配置文件或者通過make menuconfig命令啟動圖形界面進修改。因為模塊間的依賴和互斥關系相當復雜，建議通過make menuconfig啟動圖形界面來開啟下列模塊：CONFIG_DCB networking options-Data Center Bridging support CONFIG_INFINIBAND device Drivers-InfiniBand support CONFIG_DYNAMIC_MEMORY_LAYOUT Processor type and feat

58、res-Randomize the kernelmemory sections CONFIG_COMPAT Binary Emulations-IA32 Emulation CONFIG_NUMA Processor type and features-NUMA Memory Allocation and SchedulerSupport CONFIG_PAGE_POOL General setup-Page allocator randomization CONFIG_MODULES enable_loadable module support CONFIG_PCI device drive

59、r-Userspace I/O drivers CONFIG_MLX5 device driver-network device support-Ethernet driver support-Mellanox devicesKernel-headerKernel-header包制作包制作Mellanox驅動安裝需要依賴kernel-header模塊，所以需要提前準備和鏡像制作系統相同內核的Kernel-header安裝包。在第一步的內核文件夾使用下列命令可以生成.deb的包。$make deb-pkg編譯編譯MellanoxMellanox驅動驅動以Dockerfile為例，編輯鏡像步驟如下

60、：FROM*WORKDIR/18#加入Kernel-header模塊包ADD*.deb./#安裝Kernel-header模塊包RUN dpkg-i*.deb#安裝編譯需要的軟件和庫RUN apt-get update&apt-get install-y gcc.#下載Mellanox驅動編譯包ADD MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64./MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64#編譯安裝Mellanox驅動RUN./mlnxofedinstall-upstream-libs-dpdk

61、#運行DPDK相關應用.之后就可以在Kata Container中使用SR-IOV設備和DPDK的應用了。2.4.3開啟 IPv4v6 雙棧功能開啟雙?？梢宰孠8s平臺上的虛擬機/容器能夠同時支持ipv4/ipv6（可選）雙協議棧。虛擬機開啟IPv4v6雙棧需要K8s和Kube-ovn都開啟雙棧。K8sK8s啟用雙棧啟用雙棧要啟用IPv4v6雙協議棧，需要為集群的相關組件啟用IPv6DualStack特性，并且設置雙協議棧的集群網絡分配。K8s采用kubeadm方式部署，需要修改相關組件的yaml文件。kube-apiserver：啟用IPv4v6雙棧特性。#vim/etc/kubernete

62、s/manifests/kube-apiserver.yaml-feature-gates=IPv6DualStack=true-feature-gates=IPv6DualStack=true-service-cluster-ip-range=10.233.0.0/18,fd00:10:96:/112kube-controller-manager：啟用IPv4v6雙棧特性,并增加Pod/service IPv6 CIDR。#vim/etc/kubernetes/manifests/kube-controller-manager.yaml-feature-gates=IPv6DualStack

63、=true-feature-gates=IPv6DualStack=true-service-cluster-ip-range=10.233.0.0/18,fd00:10:96:/112-cluster-cidr=10.244.0.0/16,fc00:/48-node-cidr-mask-size-ipv4=24-node-cidr-mask-size-ipv6=64Kubelet：啟用IPv4v6雙棧特性。#vim/etc/sysconfig/kubelet#vim/var/lib/kubelet/config.yamlKUBELET_EXTRA_ARGS=-feature-gates=IP

64、v6DualStack=trueKUBELET_EXTRA_ARGS=-feature-gates=IPv6DualStack=truekube-proxy：啟用IPv4v6雙棧特性,并增加Pod IPv6 CIDR。#kubectl-n kube-system edit cm kube-proxydata:config.conf:|-.featureGates:IPv6DualStack:IPv6DualStack:truetrueclusterCIDR:10.244.0.0/16,fc00:/4819Kube-ovnKube-ovn啟用雙棧啟用雙棧在Kube-ovn的安裝腳本中打開對IPv

65、4v6雙棧的支持。#vim install.shDUAL_STACK=$DUAL_STACK:-trueDUAL_STACK=$DUAL_STACK:-true開啟雙棧部署好Koube-ovn后，在配置網雙棧時，需要設置網CIDR格式為cidr=,，CIDR順序要求IPv4在前，IPv6在后。apiVersion:kubeovn.io/v1kind:Subnetmetadata:name:subnet1-bj1namespace:sgbjspec:vpc:vpc-bj1-sgprotocol:IPv4default:falsecidrBlock:cidrBlock:192.168.100.0/

66、24,fd00:10:18:/64192.168.100.0/24,fd00:10:18:/64excludeIps:-192.168.100.1-fd00:10:18:1gateway:192.168.100.1,fd00:10:18:1gatewayNode:disableGatewayCheck:truegatewayType:distributednatOutgoing:trueprivate:false正常指定網啟動Pod。#cat Pod.yamlapiVersion:v1kind:Podmetadata:name:Podnamespace:defaultannotations:o

67、vn.kubernetes.io/logical_switch:ovn-defaultKcf.io/networks:mec-nets/attachnetsg,mec-nets/attachnet1sgattachnetsg.mec-nets.ovn.kubernetes.io/logical_switch:subnet1-bj1attachnet1sg.mec-nets.ovn.kubernetes.io/logical_switch:subnet2-bj1spec:containers:-name:spec-subnet4command:/bin/ash,-c,trap:TERM INT;

68、sleep 36000&waitimage:rancher/curl.Pod可以正常獲取IPv4和IPv6 地址，并且路由正常。#kubectl exec-it Pod-ip a.52:eth0if53:mtu 1400 qdisc noqueue state20UPlink/ether 00:00:00:5d:bd:30 brd ff:ff:ff:ff:ff:ffinet 10.16.0.28/16 brd 10.16.255.255 scope global eth0valid_lft forever preferred_lft foreverinet6 fd00:10:16:1c/64

69、scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe5d:bd30/64 scope linkvalid_lft forever preferred_lft forever54:net1if55:mtu 1400 qdisc noqueue stateUPlink/ether 00:00:00:2f:af:e4 brd ff:ff:ff:ff:ff:ffinet 192.168.100.5/24 brd 192.168.100.255 scope global net1valid_lft forever

70、preferred_lft foreverinet6 fd00:10:18:5/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe2f:afe4/64 scope linkvalid_lft forever preferred_lft forever56:net2if57:mtu 1400 qdisc noqueue stateUPlink/ether 00:00:00:09:8a:5d brd ff:ff:ff:ff:ff:ffinet 192.168.200.10/24 brd 192.168

71、.200.255 scope global net2valid_lft forever preferred_lft foreverinet6 fd00:10:17:a/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe09:8a5d/64 scope linkvalid_lft forever preferred_lft forever.#kubectl exec-it Pod-ip-6 route showfd00:10:16:/64 dev eth0 metric 256fd00:10:17:

72、/64 dev net2 metric 256fd00:10:18:/64 dev net1 metric 256.OVN邏輯網關和邏輯路由配置正常。#kubectl ko nbctl showswitch.port.addresses:00:00:00:E6:21:AE 192.168.100.3 fd00:10:18:3port.addresses:00:00:00:2F:AF:E4 192.168.100.5 fd00:10:18:5port.type:routerrouter-port:.#kubectl ko nbctl lr-route-list ovn-clusterIPv4 R

73、outes10.16.0.4100.64.0.3 src-ip.21IPv6 Routesfd00:10:16:4fd00:100:64:3 src-ip.在宿主機上查看ovn0網絡正常。#ip a.8:ovn0:mtu 1400 qdisc noqueue state UNKNOWN groupdefault qlen 1000link/ether 00:00:00:f0:ac:c6 brd ff:ff:ff:ff:ff:ffinet 100.64.0.2/16 brd 100.64.255.255 scope global ovn0valid_lft forever preferred_l

74、ft foreverinet6 fd00:100:64:2/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fef0:acc6/64 scope linkvalid_lft forever preferred_lft forever.KataKata ContainerContainer使用使用IPv4v6IPv4v6雙棧雙棧ECI指定網啟動Kata Container，可以正常獲取雙棧地址。#cat Pod10.yamlapiVersion:v1kind:Podmetadata:name:Pod1

75、0namespace:sgbjannotations:ovn.kubernetes.io/logical_switch:ovn-defaultKcf.io/networks:mec-nets/attachnetsg,mec-nets/attachnet1sgattachnetsg.mec-nets.ovn.kubernetes.io/logical_switch:subnet1-bj1attachnet1sg.mec-nets.ovn.kubernetes.io/logical_switch:subnet2-bj1spec:runtimeClassName:kata-qemunodeName:

76、mastercontainers:-name:Pod7command:/bin/ash,-c,trap:TERM INT;sleep 36000&waitimage:rancher/curldnsPolicy:NonednsConfig:nameservers:.在Kata Container中查看本地網卡，可以正常獲取IPv4和IPv6地址。#ip a.2:eth0:mtu 1400 qdisc fq state UP qlen 1000link/ether 00:00:00:75:b3:f2 brd ff:ff:ff:ff:ff:ffinet 10.16.0.4/16 brd 10.16.

77、255.255 scope global eth0valid_lft forever preferred_lft forever22inet6 fd00:10:16:4/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe75:b3f2/64 scope linkvalid_lft forever preferred_lft forever3:net1:mtu 1400 qdisc fq state UP qlen 1000link/ether 00:00:00:a8:1a:bb brd ff:ff

78、:ff:ff:ff:ffinet 192.168.100.2/24 brd 192.168.100.255 scope global net1valid_lft forever preferred_lft foreverinet6 fd00:10:18:2/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fea8:1abb/64 scope linkvalid_lft forever preferred_lft forever4:net2:mtu 1400 qdisc fq state UP qle

79、n 1000link/ether 00:00:00:c7:37:2e brd ff:ff:ff:ff:ff:ffinet 192.168.200.2/24 brd 192.168.200.255 scope global net2valid_lft forever preferred_lft foreverinet6 fd00:10:17:2/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fec7:372e/64 scope linkvalid_lft forever preferred_lft

80、forever.VMVM使用使用IPv4v6IPv4v6雙棧雙棧需要修改Kubevirt支持bridge類型IPv4v6雙棧。#kubectl exec-it Pod10-n sgbj-shfedoravm1$ip a.2:eth0:mtu 1400 qdisc fq_codel state UP group defaultqlen 1000link/ether 00:00:00:72:cc:56 brd ff:ff:ff:ff:ff:ffaltname enp1s0inet 192.168.100.9/24 brd 192.168.100.255 scope global dynamic n

81、oprefixroute eth0valid_lft 86313494sec preferred_lft 86313494secinet6 fd00:10:18:9/128 scope global dynamic noprefixroutevalid_lft 86313495sec preferred_lft 86313495secinet6 fe80:200:ff:fe72:cc56/64 scope link noprefixroutevalid_lft forever preferred_lft forever3:eth1:mtu 1400 qdisc fq_codel state U

82、P group defaultqlen 1000link/ether 00:00:00:86:e6:ba brd ff:ff:ff:ff:ff:ffaltname enp2s0inet 192.168.200.9/24 brd 192.168.200.255 scope global dynamic noprefixroute eth1valid_lft 86313494sec preferred_lft 86313494secinet6 fd00:10:17:9/128 scope global dynamic noprefixroutevalid_lft 86313495sec prefe

83、rred_lft 86313495secinet6 fe80:200:ff:fe86:e6ba/64 scope link noprefixroutevalid_lft forever preferred_lft forever.23fedoravm1$ip-6 r:1 dev lo proto kernel metric 256 pref mediumfd00:10:17:9 dev eth1 proto kernel metric 101 pref mediumfd00:10:17:/64 dev eth1 proto ra metric 101 pref mediumfd00:10:17

84、:/64 dev eth1 proto ra metric 101 pref mediumfd00:10:18:9 dev eth0 proto kernel metric 100 pref mediumfd00:10:18:/64 dev eth0 proto ra metric 100 pref mediumfe80:/64 dev eth0 proto kernel metric 100 pref mediumfe80:/64 dev eth1 proto kernel metric 101 pref mediumdefault via fe80:200:ff:fed6:6258 dev

85、 eth0 proto ra metric 100 pref mediumdefault via fe80:200:ff:fe2b:192d dev eth1 proto ra metric 101 pref medium2.4.4NicPort 網卡熱插拔使用社區實現的虛擬機網卡熱插拔的方式不符合用戶的使用習慣，本節描述的方法可以給用戶更好的界面體驗。本節新開發了一個CRD叫做NicPort，該CRD的每個實列即代表了一個IP地址，可以將這個實列單獨創建，然后由管理員決定將創建好的實列分配給需要的虛擬機，從而達到良好的用戶體驗。創建NicPort分為兩種情況：創建NicPort時選擇vm，則

86、直接創建綁定；創建NicPort時不選擇vm，只創建網卡。創建創建NicPortNicPort創建NicPort需要選擇，可以通過kubectl get subnet查看信息和CIDR。創建時可以選擇是否指定IP，指定IP時要滿IP在所選的CIDR范圍內，且不沖突。如果不指定IP，創建時會根據動分配。當前CNI類型只支持kube-ovn，network_type類型只支持bridge。查看子網：#kubectl get subnetNAMEPROVIDER VPCPROTOCOL CIDRPRIVATE NATDEFAULT GATEWAYTYPE V4USED V4AVAILABLE V6U

87、SED V6AVAILABLEEXCLUDEIPS.subnet1-bj1ovnvpc-bj1-sgIPv4192.168.100.0/24falsetrue falsedistributed 225100192.168.100.1式：使API登錄到ecs1節點，例如創建NicPort時不綁定vm，選擇subnet subnet1-bj1，IP為192.168.100.200，MAC為9e:13:e7:31:56:1d，示例如下：curl-v-XPOST-H Accept:application/json-H Content-Type:application/json https:/ecsvi

88、p.lab.ecs.io:6443/apis/ GET NicPort 中的法查看。如果創建NicPort時綁定vm，需要將curl data中的vmi字段選擇指定的vmi。式：使 kubectl創建 nicport1.yaml，示例如下：apiVersion: apply-f nicport.yaml命令創建網卡。獲取獲取NicPortNicPort式：使API登錄到ecs1節點，url的最后要指定NicPort的名字，可以返回NicPort的信息。curl-v-XGET-H Accept:application/json-H Content-Type:application/json ht

89、tps:/ecsvip.lab.ecs.io:6443/apis/ kubectl通過kubectl describe nicport 或者kubectl get nicport -oyaml查看NicPort信息。NicPort有多個狀態。狀態為 phase0.1表示創建了NicPort，正確分配 IP MAC，但未綁定虛擬機；狀態為phase1表示綁定了虛擬機，示例如下：Spec:Cni:kube-ovnIp:192.168.100.200Mac:9e:13:e7:31:56:1dnetwork_type:bridgeSubnet:subnet1-bj1Vmi:Status:dhcp_ad

90、vertising_ip:Stat:phase0.1/NicPort狀態Events:列出列出NicPortNicPort25式：使 API登錄到ecs1節點，使用下列命令，可以看到NicPort列表：curl-v-XGET-H Accept:application/json-H Content-Type:application/json https:/ecsvip.lab.ecs.io:6443/apis/ kubectl使用kubectl get nicports命令可以看到NicPort列表。更新更新NicPortNicPort可以更新NicPort的vmi字段，實現將網卡掛載到虛擬機上

91、和從虛擬機卸載網卡：綁定到虛擬機時，設置vmi-target字段為非空；解綁時設置vmi-target字段為空（）。式：使 API掛載NicPort的示例如下：curl-v-XPATCH-H Accept:application/json-H Content-Type:application/merge-patch+json https:/ecsvip.lab.ecs.io:6443/apis/ metadata:labels:vmi-target:testvmi-target:test,spec:vmi:test綁定后通過查看可以看到NicPort的狀態變為phase1，且有networks

92、字段。還可以查看vm的 annotations可以看到基于該networks字段的信息。需要注意，vm有關聯的Pod存在，所以查看vm時需要查看該Pod，如通過kubectl describe Pod virt-launcher-testvm-lltgc可以看到如下信息：Annotations:attachnet10.mec-nets.ovn.kubernetes.io/allocated:trueattachnet10.mec-nets.ovn.kubernetes.io/cidr:192.168.100.0/24attachnet10.mec-nets.ovn.kubernetes.io/

93、gateway:192.168.100.1attachnet10.mec-nets.ovn.kubernetes.io/ip_address:192.168.100.200attachnet10.mec-nets.ovn.kubernetes.io/logical_router:vpc-bj1-sgattachnet10.mec-nets.ovn.kubernetes.io/logical_switch:subnet1-bj1attachnet10.mec-nets.ovn.kubernetes.io/mac_address:9e:13:e7:31:56:1dattachnet10.mec-n

94、ets.ovn.kubernetes.io/Pod_nic_type:veth-pairattachnet10.mec-nets.ovn.kubernetes.io/routed:trueKcf.io/networks:interface:net1,name:attachnet1,namespace:mecnets,interface:,name:attachnet10,namespace:mec-nets卸載后NicPort的狀態將改回phase0.1。卸載NicPort的示例如下：curl-v-XPATCH-H Accept:application/json-H Content-Type:

95、application/merge-patch+json https:/ecsvip.lab.ecs.io:6443/apis/ 26-data metadata:labels:vmi-target:vmi-target:,spec:vmi:test式：使 kubectl綁定和解綁NicPort可以使用Kubectl edit nicport 命令。綁定時，修改specvmi-target字段，添加虛擬機名稱，為NicPort增加label，保存后即可。解綁時，修改specvmi-target字段，刪除虛擬機名稱，刪除NicPort的label，保存后即可。檢查點和式相同。刪除刪除NicPor

96、tNicPort刪除前需要先從虛擬機卸載。卸載法更新NicPort。式：使 API掛載NicPort的示例如下：curl-v-XDELETE-H Accept:application/json-H Content-Type:application/json https:/ecsvip.lab.ecs.io:6443/apis/ kubectl通過創建NicPort時使用的yaml文件刪除，使用Kubectl delete-f nicport1.yaml命令即可。2.4.5Macvtap 對接的實現本節描述的的 macvtap 網卡直通方案比社區原生 bridge 方案，網絡吞吐性能可以提升約

97、50%。Kubevirt+kube-OVN bridge方案網絡連接如下圖所示：圖11：Kubevirt+kube-OVN bridge方案網絡連接1、Libvirt運行在virt-launcher Pod computer容器中；272、kube-OVN CNI創建veth pair對，一個veth設備掛接到OVS網橋上，另一個veth設備綁定到virt-launcher網絡命名空間中；3、在computer容器中會創建linux網橋 k6t-net0，VM的tap設備掛接到網橋上，同時也將veth掛接到linux 網橋上，從而打通了VM到OVS網橋的數據通路。從架構圖上可以清晰的看出，VM

98、的流量到容器網絡的鏈路較長，中間需要通過多次內核協議棧，性能有很大的不必要的損耗。為優化網絡性能，可以使用macvtap網卡直通方案，即通過VM使用macvtap網卡，直接縮短VM到容器網絡的數據鏈路，實現架構如下圖所示：1、Libvirt運行在virt-launcher Pod computer容器中；2、kube-ovn CNI創建OVS internal-port，并以該internal-port創建macvtap網卡，將該macvtap綁定到virt-launcher網絡命名空間中；3、在computer容器中直接只用該macvtap網卡啟動VM，從而打通了VM到OVS網橋的數據通路。

99、圖11：macvtap網卡直通方案網絡連接_281 AnupdatedperformancecomparisonofvirtualmachinesandLinuxcontainershttps:/ OpenStack:https:/www.OpenStack.org3 Kubernetes:https:/kubernetes.io4 Kubevirt:https:/kubevirt.io5 Kata Container:https:/katacontainers.io6 Kube-OVN:https:/www.kube-ovn.io7 Harbor:https:/goharbor.io8 OpenEbs:https:/openebs.io參參 考考 文文 獻獻