基于Kubernetes的RISC-V異構集群云任務調度系統①

蔣筱斌, 熊軼翔, 張 珩, 侯朋朋, 武延軍, 趙 琛

1(中國科學院 軟件研究所, 北京 100190)

2(中國科學院大學, 北京 100049)

1 引言

大數據時代主體表現為數據的整體體量、發展速度和種類都呈現井噴式增長, 隨著計算任務所需要處理的數據規模急劇增加, 計算模式從單機多處理器的并行計算發展到多機的分布式計算, 網格計算和云計算. 如今, 云計算以其最少的資源支持最大的用戶體量和提供彈性化服務的優勢成為最為熱門的技術之一[1].云計算是基于TCP/IP通信協議的將多種計算機技術高度集成的產物, 提供對高性能處理器單元、大容量的分布式內存、高速網絡等硬件資源的統一化服務抽象和虛擬系統架構平臺[2]. 云計算的核心是虛擬化技術, 將硬件資源抽象成一個巨大的資源池, 對資源進行統一的管理和調度、按需分配, 實現動態的、可彈性伸縮性的、安全的云服務.

作為一種輕量級的虛擬化技術, Docker具有高速、輕量、擴展性強、快速交付等特點[3]. 與傳統虛擬化技術不同, 傳統虛擬化技術需要虛擬出硬件并在硬件上運行一套完整的操作系統; 而Docker類似于一個應用進程直接運行在宿主機的內核系統上, Docker容器本身沒有硬件虛擬和內核系統, 通過Linux Cgroups機制確定允許容器消耗的資源(如CPU、內存和網絡)限制[4,5]. Docker容器通過Docker Image鏡像進行創建, 容器中包含了應用程序及其所需的整個工具鏈,并通過類似于Linux Namespace機制進行空間隔離, 以保證多個應用程序之間隔離運行, 因此多個容器可以復用宿主機的硬件和內核系統, 極大的簡化了容器的創建、維護和遷移.

容器通過容器編排工具部署到集群的節點上, 目前較為流行的容器編排工具有Docker Swarm、Mesos、Kubernetes等. 考慮到Kubernetes是目前應用最為廣泛的開源容器編排工具之一, 本文選擇以Kubernetes[6]為基礎開展RISC-V開源指令集架構的適配和云任務調度器優化研究工作. Kubernetes是一個可移植的、可擴展的開源平臺, 用于管理容器化的工作負載和服務.Kubernetes工作過程由Master節點內部的kubecontroller-manager組件對集群中Node (節點)、Pod、Namespace (命名空間)等對象資源進行統計和管理, 并將待調度的Pod交由kube-scheduler進行調度, 最終實現Pod與工作節點之間的綁定. 本文主要聚焦Kubernetes的任務調度器開展性能優化和功能擴展方案研究.

RISC-V是2010年美國加州大學伯克利分校研發并推出的RISC (精簡指令集)第5代架構. 因為其開源性、簡潔性、模塊性和可擴展性, 吸引了無數產業界和工業界的研究人員的關注. 近幾年里國內外涌現了許多突破性的成果, 如阿里巴巴平頭哥研發的基于RISC-V的高性能處理器“玄鐵-910”[7], 中國科學院計算技術研究所在RISC-V中國峰會上發布的開源高性能RISC-V 處理器核“香山”[8], 佐治亞理工大學在ACM微體系結構國際會議上開源基于RISC-V的GPU實現Vortex GPU[9]等. 隨著云計算、邊緣計算等領域的不斷發展, 帶動了大量碎片化的IoT芯片需求, 這些微體系結構且具有特定功能的IoT芯片與RISC-V開源性、簡潔性、模塊性和可擴展性的特點完美契合.隨著RISC-V指令集架構的芯片設備日益增多, 亟需將RISC-V架構計算節點加入基于容器的云服務環境,充分地融合這類RISC-V架構設備算力, 以提供合理高效的資源分配和計算任務協作, 這類需求已成為目前分布式容器編排平臺的一大技術難點和挑戰. 與ARM/X86架構不同, RISC-V指令集并不是用一套統一的架構來滿足各種不同的需求, 它采用模塊化的方式進行組織, 用以提供根據用戶計算需求的可擴展性指令集; 其中, 每一個模塊都使用一個英文來表示, 共包括4個基礎指令集和6個已獲批的擴展指令集. 除此之外, RISC-V還有多個正在不斷完善的擴展指令集.如最為廣泛應用的V (向量)擴展[10], 比傳統的單指令多數據(SIMD)指令更具優勢, 解決了SIMD指令集冗余和上層軟件適配的問題. H (Hypervisor)擴展[11]支持監控程序, 提高了在單機上虛擬化部署多個操作系統的效率, 為搭載RISC-V芯片的虛擬化優化提供了可能.

目前的容器編排工具都不具備調度RISC-V指令集架構需求的任務, 尤其是RISC-V提供了用戶自定義的擴展指令集的加入, 更是增加了調度的難度. 以最新版本Kubernetes為例, 將容器部署到具有異構節點的集群中將會導致容器鏡像的拉取失敗或是應用程序的運行失敗. 標簽式的調度方案可以解決粗粒度的架構選擇, 但是無法實現RISC-V多種擴展指令集ISA匹配. 以V (Vector)擴展指令集為例, 與當前ARM/X86架構不同, RISC-V的V擴展指令提供了向量化計算,能夠為向量計算和標量計算提供單指令多數據(SIMD)運算單元, 且不限于特定的向量長度, 能夠為矩陣運算、機器學習、多媒體分析等提供指令集加速. 然而,當前的Kubernetes無法根據計算任務的特征來匹配具有該指令集特征的計算單元, 即無法做到節點內的指令集感知來調度至具備V擴展指令集的RISC-V計算節點, 因此將會導致Kubernates中集群的RISC-V計算資源浪費.

為解決上述問題, 本文提出了一種基于Kubernetes異構ISA指令集感知的集群調度系統, 它主要由指令集感知(ISAMatch)模型來處理任務在異構ISA指令集架構節點中的調度. 具體地, 本文所設計的Kubernetes集群調度系統通過對集群內的計算節點的所有指令集提供探測核實, 并根據指令集親和性和任務優先級來自動識別任務所需指令集架構和節點架構的親和程度,進而找到集群中匹配程度最高的節點. 本文整體系統設計基于開源項目Volcano調度器進行實現, ISAMatch模型與Volcano調度器的其余插件完全兼容, 可由集群管理員動態選擇是否開啟ISAMatch模型. 在ISAMatch模型的支持下, Volcano調度器可以很準確的將任務部署到對應架構的節點上, 并提高了調度性能和集群資源利用率.

本文的主要貢獻總結如下:

(1) 調研Kubernetes的多種同構和異構資源調度策略和多種ISA指令集架構特點.

(2) 提出ISAMatch模型, 它能夠準確的找到匹配任務ISA的節點列表并選擇最佳匹配節點.

(3) 基于Volcano調度器實現了一個具有ISA感知能力的分布式異構云平臺調度系統.

(4) 通過詳細實驗驗證, 本文對所實現的云計算調度平臺可以顯著地避免任務在異構節點中的部署失敗,相對比默認調度器正確率62% (調度RISC-V基礎指令集任務)、41% (調度RISC-V擴展指令集任務)、67% (調度RISC-V擴展指令集任務且有“RISC-V”節點匹配標簽), 在不考慮資源限制的條件下, ISAMatch模型可以達到100%的任務調度正確率, 以此達到提高了集群資源利用率的效果.

2 相關工作及挑戰

2.1 同構資源調度機制研究現狀

同構資源的資源調度策略更注重資源調度的結果評估, 如資源利用率和集群負載均衡等. 目前, 云計算在同構資源調度領域的研究都集中在兩個方向上.

(1)根據各種調度算法及算法改進對資源進行合理調度; 同時, 還要對云平臺的實時狀態進行評估, 判斷部分任務是否需要重新調度. 例如, Ge等人[12]將系統工作負載、任務隊列和預測的執行時間作為輸入,調度器運用遺傳算法生成最優調度方案; Zuo等人[13]提出了一種改進的蟻群算法解決最優調度問題, 使用任務完成時間和預算作為約束函數來評估成本以防止蟻群算法陷入局部最優解困境, 最終對調度方案提供反饋.

(2)根據服務器負載的周期性, 通常采用機器學習算法, 對集群收集到的時序和歷史負載信息進行分析,尋找合適的調度方案. 何龍等人[14]通過記錄各個Pod對資源的使用情況, 在后續的調度過程中, 通過歷史數據對調度的打分策略提供指導; Berral等人[15]采用機器學習算法, 對過往系統運行狀態進行分析, 通過模型預測得出的功耗、CPU負載和SLA時間調整調度決策.

2.2 異構資源調度機制研究現狀

隨著數據中心的計算節點技術架構和用戶服務需求的不斷變革, 為用戶特定任務提供特定計算單元的異構資源系統已逐漸成為當前的主流計算模式, 例如GPU (graphic processing unit)服務器用于深度學習訓練、NPU (neural processing unit)節點用于神經網絡推測以及DPU (data processing unit)用于數據資源的存儲和計算服務. 面向這類融合XPU算力資源的資源調度策略更注重異構資源本身的算力特殊性. 近年的系統領域和計算機體系結構領域的研究成果大量集中在GPU、FPGA等異構計算單元的芯片設備上.

AntMan[16]是阿里巴巴提出的一款具有動態縮放機制的集群異構資源調度器, 旨在解決在生產環境中GPU集群資源利用率低下的問題. AntMan從動態顯存管理和動態計算管理兩個維度進行設計. 動態內存管理為了適應深度學習作業中不斷變化的內存需求,將部分顯存內容轉移到CPU內存中計算, 以實現高優先級任務的優先計算. 動態計算管理采用穿插運行模式, 高優先級任務運行時, GpuOpManager組件實時監控任務在GPU上運行的時間和空閑間隙, 低優先級任務穿插間隙執行.

GaiaGPU[17]是騰訊公司設計的一款細粒度異構資源調度系統. 一改傳統異構設備的完整調度(1 GPU),將異構設備進一步細粒度化的切分調度(0.x GPU). 在細粒度調度的基礎上, 充分考慮多異構設備通信延遲,構建GPU集群拓撲結構, 針對申請小于1 GPU、申請等于1 GPU和申請大于1 GPU三種狀態分別討論, 實現GPU資源的最大利用率和通信的最小延遲.

KubeHICE[18]是Yang等人提出的一款基于ARM/X86的異構ISA指令集架構的邊緣計算資源調度平臺. KubeHICE通過請求的YAML文件中鏡像的名稱以及鏡像詳細信息包括鏡像編號、架構等是否帶有架構相關信息來選擇合適的ISA指令集設備. 在ISA指令集架構感知的基礎上, KubeHICE還討論不同ISA指令集架構芯片的算力, 根據單核算力重新定義資源數量以實現集群計算資源的負載均衡. 然而, KubeHICE策略未考慮到同名異構的鏡像調度, 同時, 指令集只針對了通用指令集, 未充分考慮到多種擴展指令集.

除了對具體異構設備資源調度的研究, 還有在異構環境下單任務切分的資源調度研究. Boran等人[19]通過將任務進行細粒度分割, 針對任務在不同階段的運行特性, 對任務遷移至不同的異構設備中運行, 實現任務的最佳運行效率.

2.3 RISC-V概述

RISC-V作為RISC (精簡指令集)第5代架構, 于2012年由Berkeley團隊[20]提出, 旨在解決當前ISA指令集架構的過于龐雜、商業化閉源、靈活性缺失等一系列技術問題. 與ARM/X86等主流指令集架構相比,RISC-V指令集架構作為新興指令集架構具有精簡化、模塊化、開源化[21]3大突出特點.

(1) RISC-V遵循“大道至簡”的設計哲學[22]. 主流指令集架構在不斷發展中為了可以向后兼容, 在原有的指令集中添加新的指令, 使得指令集文檔過于冗余.據統計, X86指令集文檔約5 000多頁, 而同樣基于RISC架構的ARM指令集文檔也擁有2 700多頁. RISC-V摒棄了向后兼容的歷史包袱, 采用“基本指令集+擴展指令集”的模式, 基礎的基本指令集僅40余條, RISC-V指令集手冊也只有200多頁[21].

(2) RISC-V采用模塊化的指令集設計模式, 采用“基本指令集+擴展指令集”的設計思想, 不僅精簡了指令集數量, 還可以自由定制所需的指令集. RISC-V架構的處理器設計人員可以根據需要選擇是否需要添加這些擴展指令, 尤其適用于具有特定功能的物聯網芯片, 降低了芯片的開發周期和成本.

(3) RISC-V遵守開放開源原則, 與ARM和X86收取高額的專利費相比, 允許芯片開發人員根據自身需求自由修改開源代碼, 并可直接用于商業活動, 降低了RISC-V的開發成本和門檻.

2.4 挑戰

圖1展示了Kubernetes在異構ISA指令集架構環境下的任務創建時調度過程, 開發者將帶有應用程序和開發環境的鏡像打包上傳至鏡像倉庫中, 通過編寫YAML文件生成Pod等待集群調度, controller整合Pod信息通過調度算法與具體工作節點進行綁定, 由綁定節點的kubelet從鏡像倉庫中拉取對應架構的鏡像生成執行Pod, 通常鏡像倉庫針對某一基礎鏡像都有多種架構選擇, kubelet會選擇與節點自身架構相同的架構進行拉取. 然而, 在調度過程中, 現有的調度器無法判斷應用程序所需ISA指令集架構, 因此存在鏡像拉取失敗或者運行環境錯誤的調度失敗的可能性.

圖1 基于Kubernetes異構ISA指令集架構調度

圖2統計了在3種異構ISA指令集架構(RISC-V、ARM、X86)環境下部署100個RISC-V任務時的調度正確頻率, 實驗平臺見表1所示, 在調度RISC-V基礎指令集任務時, 由于3個RISC-V節點都可以對其進行正常部署, 調度正確率為62%; 而在調度沒有添加任何ISA相關標簽的RISC-V擴展指令集任務時, 任務不僅需要RISC-V指令集架構環境, 還需要RISC-V節點具有特定擴展指令集架構, 調度正確率只有41%;即使添加了“RISC-V”的ISA標簽, 由于特定擴展指令集架構的影響, 調度正確率也只有67%.

圖2 RISC-V任務在默認調度器下的調度正確率

表1 實驗集群設備參數

因此, 面對異構ISA指令集架構的云平臺, 當同時部署ARM、X86、RISC-V架構節點, 現有Kubernetes調度方案都無法正常調度. 尤其是面對具有多種RISC-V擴展指令集, 當前的Kubernetes云服務調度平臺需要滿足如下的3點需求:

需求① (指令可編譯性): 在現有場景下, 支持對應擴展的計算任務的交叉編譯模式.

需求② (執行正確性): 合理分配滿足指令集架構的節點.

需求③ (架構兼容性): 適配多種指令集, 滿足指令集在云平臺節點上的架構兼容性.

為了解決創建時多種架構節點的分配問題, 本文設計了指令集感知與匹配(ISAMatch)模型來對節點ISA指令集進行匹配. 依次通過架構過濾、指令集過濾和節點打分找出最佳匹配節點.

3 基于Kubernetes的ISA架構匹配策略的設計與實現

ISAMatch模型是一種針對異構ISA指令集架構節點環境下的集群調度方案. 如圖3左側所示, controller-manager作為集群內部的管理中心, 負責管理集群的節點、作業和資源等信息, 并整合用戶申請的YAML信息交由調度器進行調度; scheduler 獲取待調度Pod信息后由ISAMatch模型讀取Pod和候選Node節點列表的ISA指令集架構數據, 并選擇合適的Node節點進行綁定, 根據綁定信息將Pod交由對應節點kubelet,從鏡像庫中拉取與宿主機架構匹配的鏡像.

圖3右側是ISAMatch模型的整體工作流程,ISAMatch模型可以分為兩個階段, 兩個階段以是否需要交叉編譯作為分隔.

圖3 基于Kubernetes的ISA架構匹配策略架構和流程圖

第1步(交叉編譯), 判斷當前任務是否具有交叉編譯需求.

第2步(ISA指令集), 判斷當前任務是否有具體ISA指令集架構需求.

第3步(架構過濾), 粗粒度的過濾不匹配的頂層指令集架構節點.

第4步(指令集過濾), 細粒度的過濾RISC-V特有的擴展指令集架構.

第5步(節點打分), 綜合指令集親和性、同種指令集架構節點數量、資源利用率對節點打分, 選取得分最高的節點作為候選綁定節點.

任務進入集群后首先判斷其是否具有交叉編譯需求, 如果有則直接跳過第2步, 根據其交叉編譯所需要的ISA指令集依次執行架構過濾、指令集過濾和節點打分操作. 當任務不具有交叉編譯需求或通過交叉編譯判斷未能找到合適的調度節點, 則繼續執行第2步判斷其是否有具體ISA指令集需求, 如果有, 則ISAMatch會根據任務所需ISA指令集依次執行架構過濾、指令集過濾和節點打分操作, 最終選出合適Node節點. 如果同時不具備交叉編譯和ISA指令集需求時, 任務將交由Kubernetes默認調度器進行調度.

綜合上述流程, 本小節將對交叉編譯和ISAMatch模型進行詳細描述.

3.1 交叉編譯

截至目前, RISC-V擴展指令集中有12個指令集已獲批, 12個指令集處于草案狀態, 另有5個指令集已凍結. 因此, 應對多種還未完成的擴展指令集, 市場上尚未有對應指令集擴展的芯片, 應對復雜指令集需求的Pod請求, 云端集群也不可能完備地集成具有所有指令集模塊組合芯片的節點.

為了解決需求① (指令可編譯性), 本文設計了采用交叉編譯的模式來解決復雜指令集請求, 以滿足上述復雜指令集動態組合的條件. 本系統主要分兩種編譯模式: 1) 混合編譯模式QEMU; 2) 節點指令集架構屬性的同構編譯ARCH, 如圖4所示, 節點ARCH標簽代表節點具有的指令集架構屬性; 任務ARCH標簽代表任務所請求的指令集架構屬性; 節點QEMU代表節點具有的交叉編譯指令集架構屬性; 任務QEMU標簽代表任務所請求的指令集架構屬性. 本系統通過對用于匹配交叉編譯模式下的架構屬性進行標記, 標記為混合編譯模式QEMU (以圖4為例, 節點具有RV64IMFDV的交叉編譯屬性, 即具有該指令集架構需求的任務可以在該節點上交叉編譯運行). 如圖3右側流程圖, 在架構過濾階段判斷Pod是否具有QEMU標簽請求. 當一個具有QEMU標簽請求的Pod進入調度器時, 調度器會根據節點QEMU標簽進行粗粒度架構過濾, 進入指令集過濾階段后根據QEMU標簽的擴展指令集部分進一步細粒度的過濾不匹配架構節點, 最后由節點打分模型分別對指令集親和性、節點數目、節點資源利用率進行評估選出合適綁定節點. 若QUME標簽的ISAMatch模型沒有找到候選節點, 即所有候選節點QEMU標簽中沒有匹配的節點, 那么會進行常規的通過ARCH標簽的調度.

圖4 Pod和Node標簽設置

3.2 ISAMatch模型

為了解決需求② (執行正確性)和③ (架構兼容性)的云平臺任務調度技術挑戰, 本文創新地定義了RISC-V指令集親和性, 用以描述任務請求指令集模塊和節點指令集模塊匹配程度的量化指標. 與ARM/X86指令集向后兼容不同, RISC-V具有模塊化和可擴展的指令集架構, 除了4組基本指令集外, 還具有多個擴展指令集, 這也使得RISC-V架構的處理器設計人員可以根據自身需求選擇是否添加這些擴展指令. 以指令集架構RV64IMFDV為例, 其表示該架構支持RV64I的基礎指令集與M、F、D、V四種擴展指令集, 那么類似于RV64I、RV64IM、RV64IMFD等12種架構組合需求的Pod都能在該架構的處理器節點上運行. 指令集親和性值最大的節點即表示Pod指令集架構需求層面匹配最優的Node節點.

定義(指令集親和性): 用于描述任務請求指令集模塊和節點指令集模塊的相似程度:

instructionAffinity=Pod模塊數/Node模塊數

其中, 模塊數是除去RV和處理器位數后的字母模塊的數目即IMFDV, Pod指令集模塊表示Pod請求的指令集架構, Node指令集模塊表示Node具有的指令集架構. 當兩者數目越接近, 則指令集親和性越高, 指令集匹配程度越高.

在具有多種混合架構的Kubernetes集群中, 指令集架構匹配是Pod正常運行的硬性指標. 由于Kubernetes的節點選擇(nodeSelector)約束和親和性約束都屬于完全約束, 且不支持模糊匹配, 所以本文設計的ISAMatch模型采用Kubernetes的標簽屬性, 旨在識別具有共同特征或屬性的資源對象. ISAMatch模型具有兩類標簽屬性: ARCH標簽和QEMU標簽. 當Pod進入調度器時, 如圖3右側流程圖所示ISAMatch模型會首先判斷待調度Pod是否具有QEMU即是否具有交叉編譯需求, 如若沒有QEMU標簽則繼續判斷是否具有ARCH標簽即是否具有特定指令集架構需求, 如若沒有QEMU標簽和ARCH標簽則轉入Kubernetes默認調度器進行調度. QEMU標簽過濾和ARCH標簽過濾的實現過程相似, 均采用架構過濾、指令集過濾和節點打分依次執行.

對所有候選Node節點執行架構過濾, 粗粒度的選出同族ISA指令集架構節點, 而對于具有特有擴展指令集架構的RISC-V節點, 還需要執行指令集過濾, 對同族ISA指令集架構節點進一步對擴展指令集的模塊名稱進行過濾, 必須具備Pod請求模塊是Node支持模塊子集的特點:

instructionPod?instructionNode

選出的候選節點為細粒度的同族ISA指令集節點. 候選節點進一步進行節點打分. 節點打分會選出具體綁定的節點, 打分機制將綜合考慮指令集親和性、同種指令集架構節點的數量和節點資源利用率. 其優先級為:

指令集親和性＞同種指令集架構節點數量

＞節點資源利用率

具體示例如圖5所示, 在14個異構ISA指令集架構節點的集群中任務申請為RV64IMF. 架構過濾會根據任務YAML文件中的ARCH標簽字段過濾粗粒度指令集架構為9個RISC-V節點. 指令集過濾根據細粒度的擴展指令集架構進一步過濾節點為7個支持IMF模塊的RISC-V節點. 節點打分策略依據優先級順序首先計算候選節點的指令集親和性, 親和性結果會選出一組或多組指令集親和性相等的指令集架構節點. 由于指令集親和性存在一定幾率選出多組指令集親和性相等的節點族, 因此, 本文設計了統計滿足條件的同種指令集架構節點數量作為打分標準, 選擇擁有節點數量更多的指令集架構節點將會為集群剩下更多的其余指令集架構節點, 以方便之后對于其余指令集架構需求任務的調度. 當具體選定了某一細粒度擴展指令集架構時, 從候選節點中選擇資源利用率最小的節點進行綁定, 以提高在滿足調度申請條件的前提下的資源負載均衡程度和任務計算效率.

圖5 ISAMatch模型工作流程圖

4 實現與優化

本文通過基于Volcano調度器實現了支持多種ISA指令集架構任務的調度需求. 在不破壞Volcano源代碼結構的前提下, 以插件的形式設計并實現ISAMatch模型.

4.1 標簽自動機

由于ISAMatch模型依賴于Pod和Node的ARCH標簽和QEMU標簽, 其中Pod所具有的標簽是由用戶在提交YAML文件時主動設置, 代表用戶提交任務所需要的指令集架構, 而集群中節點所支持的標簽需要集群管理員手動添加, 需要在集群部署完成后為所有節點添加節點支持的ISA指令集架構和節點支持的ISA指令集交叉編譯架構. 在規模較大的Kubernetes集群場景下, 這種由集群管理員手動添加標簽的方式非常麻煩, 因此, 本文設計實現了自動標簽設置腳本.

自動標簽設置腳本運行在集群Master節點上, 通過kubectl命令工具從ETCD中獲取所有節點信息, 并由正則表達式過濾出節點IP. 同時, 在將節點部署進集群后, 節點會自動生成kubernetes.io/arch標簽用于識別節點指令集架構, 腳本從節點詳細信息中讀取節點IP和粗粒度節點指令集架構. 而對于RISC-V指令集架構節點, 標簽顯示為kubernetes.io/arch=riscv64, 因而無法細粒度的識別RISC-V的具體擴展指令集架構, 因此需要從節點gcc-v中的--with-arch標簽獲取更詳細的ISA信息(如圖6).

圖6 gcc中的ISA信息

最后腳本模擬手動通過kubectl命令“kubectl label node $node ARCH=$ISA”添加ARCH標簽方式.

交叉編譯環境被默認安裝在/opt/RISCV/bin/路徑下, 同樣的, 由/opt/RISCV/bin/riscv64-unknown-linuxgnu-gcc-v獲取詳細擴展指令集架構, 最后通過kubectl命令工具由腳本模擬添加QEMU標簽.

4.2 架構和指令集過濾以及節點打分流程優化

架構過濾和指令集過濾偽代碼如算法1所示.

算法 1. 架構過濾和指令集過濾1. candidateNodes={}2. IF Contains(PodARCH, “RV”) THEN 3. FOR node in nodeList do 4. IF node→nodeARCH[:2]==“RV”&&ContainIns(node→nodeARCH[4:], PodARCH[4:]) THEN 5. candidateNode=append(candidateNodes, node)6. END IF 7. END FOR 8. END IF 9. ELSE

10. FOR node in nodeList do 11. IF Contains(node→nodeARCH, PodARCH) THEN 12. candidateNodes=append(candidateNodes, node)13. END IF 14. END FOR 15. END ELSE 16. return candidateNodes

架構過濾是對系統指令集架構進行的粗粒度過濾,是對Pod和Node節點設置的ARCH標簽或QEMU標簽進行的模糊匹配, 過濾不符合Pod任務申請的架構的Node節點.

指令集過濾是針對RISC-V特有的擴展指令集的細粒度過濾, 由于擴展指令集兼容性的情況, 通過containIns函數判斷Pod任務申請的指令集架構是否為Node支持的指令集架構的子集.

如圖7, 打分機制綜合考慮指令集親和性、同種指令集架構節點數量和節點資源利用率. 分別計算各個節點與請求Pod之間的指令集親和性、同種ISA指令集架構數量和各個節點資源利用率, 并組合形成NodeISAInfo結構體. 針對NodeISAInfo依次對指令集親和性、同種指令集架構節點數量和節點資源利用率進行排序,依據優先級公式選擇指令集親和性最大的一組或多組ISA指令集架構節點, 在多組ISA指令集架構節點中比較同種指令集架構節點數量, 選擇多者, 最后在單組中選取資源利用率最低的節點作為候選的綁定節點.

圖7 打分機制函數流圖

5 評估實驗和結果分析

本文以Linux平臺最為常見的3種架構作為研究對象(ARM、X86、RISC-V)進行分析, 主要進行:

(1) 評估在異構RISC-V指令集架構的集群環境下, 部署不同架構(含X86、ARM和RISC-V指令集架構芯片)需求任務的調度正確性;

(2) 統計在調度中與傳統調度器相比的性能延遲.

5.1 實驗平臺及數據

實驗平臺: 在5臺部署有Kubernetes集群的虛擬環境上進行驗證實驗. 其中包括一臺X86的虛擬主機、一臺ARM64的虛擬主機和3臺RISC-V的虛擬主機. 具體參數見表1.

實驗數據: 實驗數據由隨機函數生成了90個服務型任務和10個計算型任務, 100個任務所申請的CPU和Memory資源如圖8所示.

圖8 100個任務的資源分布情況

5.2 ISAMatch模型正確性測試

本文通過部署100個RISC-V任務對集群進行ISA架構匹配的測試. 分別測試驗證: 1)部署100個RISC-V基礎指令集任務, 即只需要在RISC-V節點上就能正常運行; 2)部署100個未帶有指令集架構相關標簽的RISC-V擴展指令集任務; 3)部署100個帶有“RISC-V”標簽的RISC-V擴展指令集任務.

實驗表明(如圖9), RISC-V基礎指令集任務只需要部署到RISC-V節點上就能正常運行, 調度正確率為62%; 而未帶有指令集架構相關標簽的RISC-V擴展指令集任務需要精確到具體的擴展指令, 如RV64IMFD只能運行在節點3和節點5上, 調度正確率為41%; 帶有“RISC-V”標簽的RISC-V擴展指令集任務雖然排除了ARM和X86兩種架構, 但部分調度未能精確找到匹配的擴展指令架構的節點, 調度正確率為67%. 而在ISAMatch模型下, 調度正確率達到100%,ISAMatch模型可以準確的將Pod調度到合適的節點,并能夠更細粒度的通過指令集親和性找到最佳匹配節點, 如圖10所示, RV64IMFD可以成功運行在節點3和節點5上, 而根據指令集親和性, ISAMatch模型會選取更為匹配的節點3作為最佳匹配節點, 而只有當節點3無法滿足調度需求時才會選用節點5進行調度.

圖9 RISC-V任務在默認調度器下的調度正確率

圖10 指令集親和性下RISC-V擴展指令集任務調度選擇

5.3 調度延遲分析

進一步, 為了驗證具有ISAMatch模型調度器和傳統調度器的調度延遲, 實驗測試了調度1-100個Pod.其中, 調度單個Pod所需的調度延遲是統計待調度Pod在Volcano調度器中從調度起始函數OpenSession開始到綁定具體節點后的CloseSession結束所用的時間. 從圖11可以得出當部署40個以內的Pod數時, 傳統調度器和具有ISAMatch模型的調度器調度所用延遲在誤差范圍內接近, 大約在1 ms左右. 而當部署40個以上Pod時, 具有ISAMatch模型的調度器所消耗的調度延遲略大于傳統調度器, 并隨著Pod數量的增加, 兩者之間的差值也逐步增大, 在部署100個Pod時, 具有ISAMatch模型的調度器比傳統調度器多耗時約6 ms.這是由于隨著Pod數目的增加, 每一輪Session對單個Pod進行調度時都需要額外對其ISA指令集架構進行匹配, 經測量, 對單個Pod進行ISA指令集架構匹配的平均耗時為60.57 μs. 部署100個Pod有無ISAMatch模型耗時的差值與Pod個數不構成線性關系(如圖12),且與平均耗時不成倍數關系, 其原因是隨著Pod數目增大后無法在同一個Session中完成調度, 需要開啟多個Session進行調度, 因此會有額外的調度損耗.

圖11 ISAMatch模型調度延遲

圖12 有無ISAMatch模型延遲差與單任務延遲線性對比

6 結語

針對目前Kubernetes集群無法支持異構ISA指令集架構任務調度的問題, 提出了一種具有ISA指令集感知能力的異構資源調度方案. 應對多種RISC-V擴展指令集架構需求任務, 提出了指令集親和性標準, 并在此基礎上通過架構過濾、指令集過濾和節點打分3個維度的綜合評價, 在保證調度性能的前提下, 提高集群調度正確性和資源利用率, 使集群有能力應對更多復雜場景.