基于Kubernetes的醫療領域機器學習節點部署優化

文 | 廣州醫科大學附屬第五醫院信息科，廣東高校生物靶向診治與康復重點實驗室 李斌 高振宇

隨著大數據應用的普及以及深度學習的快速發展，深度神經網絡模型依靠海量數據的學習和極深的網絡深度，在很多領域取得了不亞于人類的結果。而在醫療行業中，模型計算的準確率是其能否應用到臨床的一個非常重要的指標。當前很多深度神經網絡模型為了提高計算精確度，其模型的大小正在變得越來越大，從幾十GB到上百GB不等。這些大模型相對小模型具有更高的準確度，但是在部署，特別是在分布式的環境下，常常遇到難以升級迭代的問題。

一、問題分析

容器技術目前已經相當成熟，相比傳統虛擬化技術構建的虛擬機，容器的性能和部署便捷性要遠遠優于虛擬機。特別是在需要異構計算的人工智能領域中，為了能更好利用GPU的性能來進行模型訓練和推理，采用容器方案可以更好地適配訓練和推理中對性能和擴展性的需求。Kubernetes目前已經成為了私有云容器集群編排管理的事實標準，通過Kubernetes可以非常便捷管理容器的整個生命周期。但是目前Kubernetes對于深度學習的場景支持還是不充分的，Kubernetes的架構對于stateless容器和使用共享存儲的state-ful場景有比較好的支持，但是對于深度學習節點，因其所依賴的數據十分龐大，而且對性能的苛刻要求，所以共享存儲的性能是不能滿足實際生產環境要求的。另一方面，Kubernetes對于容器使用本地持久化存儲的支持有限，它難以管理容器的依賴數據的生命周期。在實際生產環境中，醫學方面的模型往往是非常大的，例如一個多模態的從DR圖片生成檢查報告的模型的大小往往在十幾GB，其訓練過程中所需要的數據會達到數TB。由于Kubernetes的特殊機制，Pod的描述信息一旦發生變化就必須重建。所以這種深度神經網絡模型容器哪怕只是更新了一個簡單的配置也會引發容器銷毀，新建的容器需要耗費大量的時間把依賴數據通過網絡拉取到本地，最后造成新啟動的容器往往遲遲不能提供服務，時間成本較高。

二、現有方法

為了降低時間成本，盡快讓銷毀重建的容器重新提供服務，常見的解決方案是添加更多的硬件資源或者采用并行拉取的方式來提升網絡拉取數據速度，這需要投入更多的設備用于提高整個網絡的數據鏈路傳輸性能。另一種方案是限定Pod（Kubernetes 中創建和管理的、最小的可部署的計算單元）的調度范圍，使Pod只能調度到指定的一批Kubernetes工作節點上，提高Pod調度回原來節點或者相似節點的概率，以減少拉取數據的工作，這種方法利用了Kubernetes的自身的調度策略，需要人工篩選特定機器后再去進行綁定。但是即使利用該方式也難以保證Pod可以調度到理想的節點上。

（一）建立多個數據服務集群

一個容器的模型或其依賴的數據量如果很大，一般會選擇將其存儲在一個方便遠程拉取的集群中，常見的方式是將容器依賴的數據上傳到HDFS(Hadoop Distributed File System)集群上，由HDFS集群充當數據服務集群，Pod啟動后其sidecar容器從數據服務集群將所依賴的數據拉取下來。但是在多IDC機房環境中，單一數據服務集群的網絡速率往往在跨IDC的數據傳輸中變得很慢。建立多數據服務集群可以有效解決這個問題，不同的IDC的數據服務集群利用IDC之間的網絡同步數據，Pod的sidecar從所屬IDC的數據服務集群拉取數據，避免出現跨IDC交互。該方案的缺點是需要投入大量的服務器和網絡改造成本在每個IDC機房建立同質化的數據服務集群。

（二）限定容器部署

Kubernetes的默認scheduler可以支持通過設定tag親和性來調度Pod到特定節點上，該方法通過人工在特定的Kubernetes工作節點打上特定的tag，隨后創建Pod的時候指定Pod只能調度到打了特定的tag的Kubernetes工作節點，以此來進行Pod和機器的綁定。這些打上了tag的工作節點要提前建立好本地持久化存儲，并下載好依賴的數據。這種方式需要大量人工介入，難以擴容和縮容符合親和性的機器。除此之外，這種方式不能很好的管理依賴數據在本地存儲的生命周期，可能會出現節點存儲剩余空間不足導致容器被驅逐的情況。

三、優化

目前Kubernetes默認調度機制沒有考慮拉取容器依賴所產生的影響，默認的調度策略會優先將Pod調度到計算資源較充足的節點。而計算資源較充足的節點往往是新加入集群的節點，新節點是沒有在本地緩存任何依賴數據的，它需要從遠端通過網絡拉取大量依賴數據。雖然Pod的原節點已經有了大部分依賴數據，但是由于調度策略的影響，重建的Pod往往不能被調度回原節點。所以為了能解決Pod中的業務容器長期等待依賴數據問題，本文提出通過改造Kubernetes的調度器來將依賴數據缺失部分、本地存儲、網絡實時狀況等因素納入定制化的調度器考慮范圍中，當出現Pod需要調度時候，如圖1流程，定制化調度器會實時計算出所有符合部署的節點的得分情況，優先調度Pod到能快速完成數據依賴加載的節點上。此外，Pod啟動后的sidecar容器可以支持使用P2P的方式來從別的節點拉取依賴數據，進一步降低業務容器數據加載時間。

圖1 定制調度策略調度Pod流程

（一）定制調度策略

定制化調度器策略包含2個部分，分別是Agent和custom-scheduler（cu-sch）。Agent以Daemonset的方式部署在每個Kubernetes工作節點上。custom-scheduler作為定制化調度器用于接收Agent上報數據和處理Pod的調度等事務。

Agent負責實時獲取當前節點中如表1中所列的節點緩存數據、鏡像列表、網絡環境等信息并上報給Kubernetes的定制化調度器cu-sch。cu-sch收集到節點上報的信息后可以計算出Pod從調度完成到可以正常服務所需消耗的時間，這個時間將作為重要參考因素用于計算各個節點部署該Pod的優先級分數。通過該流程，cu-sch可以大概率把容器優先放置在已經存在鏡像和依賴數據的節點上，以避免重復從遠端拉取數據，或是調度Pod到網絡條件好的節點上，以最大程度節省拉取數據的時間。此外，Agent還負責管理節點上已經拉取的依賴數據的生命周期，會采用LRU方式將長期不使用的數據清理掉。

表1 Agent所需采集上報信息

存儲依賴數據的磁盤剩余空間 RemainDataRoom 操作系統提供的接口拉取鏡像的傳輸速率 PullImageRate拉取遠端測試鏡像計算拉取效率拉取依賴數據的傳輸速率 PullRelyDataRate拉取遠端測試數據計算拉取效率存儲鏡像數據的磁盤剩余空間 RemainImageRoom 操作系統提供的接口

Kubernetes 的custom-scheduler是Kubernetes控制平面的核心組件之一。其主要功能是將Pod分配給節點，同時平衡各節點的資源利用率。custom-scheduler具有Kubernetes所有的默認調度策略，而且該調度器會將鏡像，依賴的存儲等信息考慮進去，進行過濾和打分。如圖2所示，Agent輪詢檢測節點上已經緩存的依賴數據，鏡像數據。由于每個節點配置和所處網絡環境是不一致的，Agent會從數據服務集群中定時拉取測試文件，用于檢測節點和數據服務集群之間的網絡情況，用于后續customscheduler準確計算每個節點的得分。

圖2 定制調度架構示意圖

Custom-scheduler具備訪問鏡像服務和依賴數據存儲服務的能力，可以取得特定相關鏡像和容器依賴的數據的metadata信息，metadata信息中包含鏡像名字，版本，數字摘要，鏡像層信息，容器依賴的數據名字，唯一標示號，大小，信息摘要等信息。隨后和Agent已經提交的信息進行比對，可以知道缺少的鏡像層和缺少的依賴數據。例如調度Pod時候，該Pod需要鏡像M，其依賴的數據為集合{a,b,c}。鏡像M實際上是由三層構成，為{X,Y,Z}。從Agent提交的數據中得知某節點已經存在了Y和Z層鏡像以及依賴數據{a,b}，計算出Pod部署到該節點只需要拉取{X,c}，最后通過該節點Agent提供的PullImageRate和PullRelyDataRate可以計算出拉取依賴數據的預計時間。這個計算過程會對所有符合的節點進行計算以篩選出可以最快部署好Pod并提供服務的節點。

（二）P2P-sidecar

P2P-sidecar以sidecar的方式和業務容器一起部署和運行。P2P-sidecar基于BitTorrent協議實現，可以通過P2P的方式從多個不同的節點拉取所需的依賴數據和模型，同時其也支持S3協議和HDFS協議用于從數據服務集群拉取數據。P2P的引入在不增加數據服務集群的情況下可以很好地提升依賴數據拉取的效率，并且很好地緩解數據服務集群壓力，減少網絡擁塞情況。如圖3所示，P2P-sidecar可以與同個IDC內的節點通信，分塊獲取所需要的數據。

四、實驗

實驗過程中使用了20臺物理服務器，每個物理服務器都配置了萬兆雙網卡，每個物理服務器上虛擬5個虛擬機。實驗針對custom-scheduler方案和P2P-sidecar進行了100Pod-150Pod規模的Deployment部署、Deployment擴容、Deployment升級、Deployment縮容再擴容等常見場景測試。實驗中用于測試的虛擬模型大小為4GB，8GB，16GB，32GB這4種類型，Deployment會隨機選擇模型的組合用于測試。實驗中設定Deployment的滾動升級中保證其80%的實例Pod是正常運行的。

整個測試進行了三次重復實驗，實驗結果如圖4，其結果表明定制化的調度策略可以極大優化Pod變更后重新部署的耗時，另外，引入的P2P-sidecar可加速依賴數據和模型的下載，進一步降低時間成本。

實驗的結果表明，Kubernetes的Deployment部署的Pod在使用了文本提出的定制化調度策略后，其在變更過程中可以大概率調度到已經有依賴數據的節點上，Kubelet可以快速拉起容器并恢復服務。對比原生Kubernetes的方式，因為減少了重復數據拉取過程，使得整個變更時間降低到原有的5%。另外，P2P-sidecar的引入可以優化節點第一次拉取依賴數據的時間，將初次部署的整體時間降低了25%。

五、結語

圖4 Kubernetes Deployment多場景耗時測試

Kubernetes托管的容器在實際生產環境中會經常因為各種變更而導致重建，重建過程的耗時常常會影響業務的迭代效率。本文針對目前Kubernetes托管的醫學領域機器學習容器的數據依賴過重導致變更時間成本較高的問題進行分析并提出了使用定制化調度的方式以及P2P-sidecar來進行優化，該方法降低了變更期間容器不能提供服務的時間。從實驗結果可以看到該方法對于容器升級這類場景有較大的效率提升，可以很好滿足容器頻繁變更的需求。