阿里雲容器與存儲團隊展開合做,利用DADI加速器支持鏡像按需讀取和P2P分發,實現3.01秒啓動10000個容器,完美杜絕容器冷啓動的數分鐘漫長等待,以及鏡像倉庫大規模並行分發場景下的網絡擁堵。算法
年關將至,各類年貨節、秒殺商品、倒計時直播即將紛至沓來。這些業務的共同點都是流量瞬間暴增,必須在馬上籌備大量的服務器,並在極短期內擴容容器承接線上流量,避免系統崩潰。除了須要集羣節點的快速擴容,也對應用部署速度提出更高要求。緩存
部署啓動快常被認爲是容器的核心優點之一:本地鏡像實例化成容器的時間很短,即「熱啓動」;而在本地無鏡像狀況下的「冷啓動」,須要先從鏡像倉庫下載鏡像並解壓縮後才能拉起容器,受網絡和磁盤性能影響較大,耗時數分鐘;大規模批量冷啓動甚至可能致使Registry因網絡擁堵而沒法響應。服務器
針對冷啓動的痛點,阿里雲推出一個全新存儲引擎DADI加速器,將容器冷啓動耗時縮短至數秒。方案沉澱自阿里集團內部大規模應用的數據訪問加速經驗,曾在雙十一大促中爲大規模容器集羣擴容提供了秒級拉起能力。網絡
本次測試場景是在 1000 臺4核8G的節點組成的Kubernetes集羣中進行,阿里雲容器服務Kubernetes (ACK) 能在極短期內擴容出 1000 臺節點worker並加入到Kubernetes 集羣中。ACK 的此能力在應對大促,秒殺,短時流量洪峯時具備亮眼的表現。less
同時針對本次測試場景,利用Kubernetes 強大的擴展性和自定義控制器,加快在大規模集羣中建立應用和刪除應用的速度,保障了測試在極短期內方便快捷的進行。性能
阿里雲容器團隊聯合存儲團隊研發的DADI加速器在本次測試中啓動10000個容器僅需3.01秒,10秒內啓動了近60000個容器。測試
同時針對1萬個容器的冷熱啓動進行對比,即在本地有無鏡像緩存對啓動時間的影響,熱啓動耗時2.91秒,其中p999耗時2.56秒優化
DADI冷啓動因爲數據按需從P2P網絡中獲取,減輕了磁盤壓力避免發生IO擁堵,所以長尾容器較少。阿里雲
此外,還進行了限時摸高測試。在10秒的限制時間內利用1000臺宿主機啓動了59997個容器,在10.06秒時第6萬容器啓動完畢:spa
注:上述圖示數據,均在阿里雲容器團隊的容器服務ACK中進行。爲方便得到每一個容器的啓動時間,採用C/S模式:worker中每一個容器拉起後向測試的httpServer上報本身狀態,以httpServer記錄的請求時間做爲容器啓動耗時。
通常而言,完整的容器應用鏡像每每有數百M甚至上G的大小。在社區的容器Registry的實現中,鏡像會以分層方式存儲,每一層都是一個tgz包。當容器啓動時, 容器引擎會從容器Registry拉取全部的層,在本地實現解壓後,經過層次化文件系統構建完整的容器rootfs。而容器啓動過程當中所須要的數據可能只佔鏡像文件中極小一部分比例。本次測試所用鏡像完整大小爲894M,容器啓動所需數據僅15M,佔比約1.6%。如何能避免下載完整鏡像到本地而直接獲取到這1.6%啓動數據是加速容器啓動的關鍵。
爲什麼DADI加速器能爲大規模容器集羣擴容提供秒級拉起的能力?其核心在於「按需讀取」容器運行時所需數據,避免傳統容器 「下載鏡像 -> 解壓鏡像 -> 啓動容器」的啓動步驟,容器啓動耗時從分鐘縮短至數秒。這其中包括如下三點優化工做:
利用DADI方案啓動容器時,僅從鏡像Registry下載幾KB的鏡像元數據,並建立虛擬設備Overlay Block Device掛載到容器工做目錄上, Docker引擎會認爲鏡像已經加載完畢。在容器啓動時所需的鏡像數據則從本地緩存或者P2P 網絡的上游節點按需下載。P2P網絡能夠充分緩解對Registry的訪問壓力。
隨着Kubernetes 被愈來愈普遍地接受,阿里雲ACK支撐了各行各業的企業級客戶。這次ACK和DADI的深度整合,實現秒級啓動萬個容器,從容應對大規模應用擴容和發佈,相關技術在將來也將成爲Serverless容器的啓動加速利器。
本文做者:木環
本文爲阿里雲內容,未經容許不得轉載。