Serverless容器實例Cube的研發實踐之路

Cube誕生背景

隨着雲原生技術的推廣及落地,容器技術在企業生產環境中的使用比重愈來愈大。Kubernetes做爲容器編排的事實標準,在企業服務中被大量採用。UCloud容器團隊在2018年推出了Kubernetes產品UK8S, 這款產品基於UCloud公有云環境實現,無縫集成了UCloud IaaS層計算、網絡及存儲的服務,使客戶可以快速獲取到生產可用的Kubernetes集羣,並擁有靈活控制集羣的能力。docker

但在UK8S產品推廣及接入客戶過程當中,容器團隊也陸續收到一些用戶反饋的問題:後端

  • 維護Kubernetes集羣增長了額外的負擔;用戶除了管應用還須要後端資源,並未能實現以應用爲中心的業務管理。
  • Kubernetes體系較爲複雜,學習曲線比較陡峭,須要客戶團隊有必定技術儲備;對於已經使用了容器但還沒有嘗試Kubernetes的客戶也是如此,一方面須要瞭解Kubernetes的技術體系,另外一方面須要修改應用架構適配Kubernetes。
  • 但願能有一款即開即用的容器產品,經過容器直接拉起應用,不須要等待虛擬機就緒再部署應用,縮短應用就緒等待時間。

爲解決上述用戶問題,容器團隊開發了一款新的serverless容器產品Cube,目前正處在公測階段。除了下降用戶使用容器的門檻,該產品還具備如下特性:緩存

1.免運維:沒有維護資源負擔,不須要關心運行位置,以應用爲中心,以容器鏡像爲應用打包標準。安全

2.按需付費:按照應用實際使用資源付費。網絡

3.自動擴縮容:基於海量資源,提供API,可按需拉起和關閉應用,自動調度資源。架構

4.高可用:產品自己高可用,同時提供應用自愈能力。框架

技術選型

在實現Cube產品特性的過程當中,容器團隊須要解決幾個技術問題:1. 容器運行時的選型公有云產品必然要考慮多租戶隔離問題。不一樣於UK8S產品以雲主機爲基礎構建的隔離性,Cube產品則直接在宿主物理機上運行容器。標準docker實現的容器並不能實現同臺宿主機上不一樣用戶不一樣容器之間的強隔離,所以Cube產品須要一款同時具有虛擬機強隔離性和容器快速啓動特色的容器運行時方案。less

容器團隊注意到AWS開源了輕量級虛擬機firecracker,具備資源佔用少、啓動速度快、易於維護等諸多優勢,並已用於實際生產環境,很是符合Cube業務場景,所以最終採用了以firecracker輕量級虛擬機爲基礎的容器運行時方案。從下面兩張圖能夠看出,經過對雲計算場景特別的精簡和優化, firecracker相對於目前主流的虛擬化組件qemu在啓動速度和內存消耗方面有明顯的優點。運維

VMM啓動時間和內存佔用對比,圖片引用來源性能

2. 容器管理服務

支持虛擬機容器運行時的容器管理服務也有多種開源方案,例如containerd/cri-o,kata-container和firecracker-containerd等。通過比較,容器團隊選擇了cri-o + firecracker-containerd的組合。這兩者在功能上可以知足單機容器管理的需求,並且和其餘選型相比,代碼架構更加清晰,調用鏈路簡單明瞭,便於後續根據產品需求定製和改造。

3. 容器調度服務

Kubernetes已經成爲了容器調度的事實標準,具有豐富的功能和良好的可擴展性。所以容器團隊採用Kubernetes做爲基本調度框架,並根據產品需求作相關改造,最終基本的服務架構以下所示:

優化改進

雖然採用開源方案能夠加快開發進度,但爲知足產品需求仍需解決一些問題,主要包括如下幾個方面:

1. 容器鏡像在標準的容器鏡像實現中,鏡像是經過分層結構存儲在宿主上的。當建立容器時,容器運行時會在鏡像層之上建立一個可寫層,並掛載在宿主上供容器實例使用。但Cube容器並非直接在宿主上運行的,也不須要在宿主上掛載容器根目錄。所以容器團隊修改了cri-o中鏡像層的相關實現,直接將容器可寫層以塊設備的方式掛載到輕量級虛擬機中而非宿主上,減低了宿主對Cube容器的干擾。

另外,爲了解決新鏡像拉取緩慢致使的容器實例啓動慢的問題,容器團隊提出了鏡像遠程掛載的解決方案。將容器鏡像以塊設備的形式存儲在緩存集羣,當須要在此鏡像上生成容器實例時,先將容器鏡像經過遠程掛載的形式掛載到宿主上,而後容器運行時會在宿主上建立一層可寫層生成容器實例。同時後臺會將遠程鏡像同步到宿主本地,進一步加速讀取,下降集羣風險。上述方法可以使宿主上首次獲取鏡像的時間縮短至3s如下,並有進一步優化空間。目前這一功能以鏡像緩存的產品形式提供給用戶使用,並正在逐步整合到普通鏡像拉取過程當中。

2. 使用公有云資源

網絡方面,Cube容器的網絡模型和雲主機的基本相同。在將相關網絡功能以cni插件的形式實現以後,Cube容器就能夠很好的接入到公有云vpc網絡中。

存儲方面,Cube容器目前支持了兩種類型的存儲:能夠多點讀寫的網絡文件系統nfs和僅單點讀寫的雲硬盤udisk。在文件存儲功能上,Cube產品實現了在輕量級虛擬機中自動掛載nfs的功能,用戶只需在配置文件中指定好掛載點和掛載參數,就能直接在容器中使用網絡文件系統,並能夠同時支持vpc網絡內用戶自建的nfs和UCloud公有云產品ufs。在塊設備功能上,容器團隊擴展了firecracker塊設備的實現。經過添加對vhost-user協議的支持,Cube輕量級虛擬機能夠直接對接到spdk服務,從而實現了對高性能的rssd型雲硬盤掛載和使用。

3. 容器運行環境

爲了減小額外資源消耗,容器團隊在容器管理服務和容器運行時上作了大量優化工做。

容器團隊修改了cri-o管理容器組的架構,採用了單pod對應單shim的模型。經過一個shim管理一個pod內所有容器,能夠顯著的下降shim資源消耗,簡化容器管理。對於輕量級虛擬機,容器團隊也對kernel/rootfs/init進程等作了充分地精簡優化,只保留了最基本的功能,以加快啓動速度,減少安全攻擊面,下降資源消耗。另外,容器團隊還在輕量級虛擬機中內置了infra container的實現,Cube做爲pod運行時能夠沒必要掛載額外的infra容器。

4. k8s改造

Kubernetes做爲一個通用的容器調度框架,可以知足大部分容器管理的需求。但針對Cube特定的使用場景,容器團隊仍需對k8s組件作一些改造。在控制面,容器團隊採用了自定義的調度器,能夠更好的知足多租戶場景下任務優先級,調度速度,資源管理的需求。在宿主節點上,鑑於Cube容器運行時的特色,容器團隊精簡了一些不須要kubelet實現的功能,例如在宿主上掛載configmap/volume目錄,運行cni插件,收集特定目錄日誌等,加強了容器與宿主之間的隔離安全性。

Cube將來展望

在完成了上述開發改造後,Cube產品成功上線,並取得良好效果。後續Cube產品會繼續沿着幫助用戶提高效率、下降開銷、簡化維護、節約成本的思路持續迭代更新。在容器性能方面,容器團隊會繼續優化輕量級虛擬機IO路徑,減小虛擬化及管理組件的性能損耗,確保用戶容器實例穩定高效運行。在服務管理方面,Cube產品層面會推出多種的容器管理控制器,並實現Cube實例直接接入Kubernetes集羣的能力,爲用戶提供多層次的資源調度方式,方便用戶按實際須要管理維護。

若是您對UCloud Cube產品感興趣,歡迎掃碼加入Cube測試交流羣!

https://u.wechat.com/ELATXrQmIDI2cCgzioMgl88 (二維碼自動識別)

相關文章
相關標籤/搜索