1.方案背景

1.1.業務背景

隨著容器技術的迅猛發展與廣泛應用，一種新的云計算服務模式應運而生-函數即服務（FaaS, Function as a Service）。FaaS作為一種無服務器（Serverless）計算方式，極大地簡化了開發人員的工作，使他們能夠專注于應用的構建與運行，而不再需要承擔服務器管理的負擔。

然而，FaaS模式也并非沒有缺陷，其中最為人詬病的便是“冷啟動”問題。所謂冷啟動，是指當請求被調度到某個函數實例時，如果該實例在上次執行完代碼后已經被回收，系統需要先創建一個新的實例并初始化環境，才能繼續執行代碼。

相比之下，熱啟動則是指函數實例未被回收的情況下，直接復用現有實例以響應請求，這顯然效率更高。因此，冷啟動過程常常導致較高的延遲，進而影響應用的性能。

1.2.問題與挑戰

1.2.1 傳統方案

根據《Slacker: Fast Distribution with Lazy Docker Containers》一文的分析，鏡像拉取過程占據了容器啟動時間的76%，然而實際啟動時只有6.4%的數據會被讀取。這一現象揭示了傳統容器鏡像格式和拉取方式在使用overlay文件系統（OverlayFS）時存在的問題：

過多的時間花費在拉取鏡像上。

拉取了過多無關的數據。

這兩個問題的根源在于容器鏡像是由一組tgz文件組成，而這些文件作為鏡像層（image layer）存在以下兩個顯著缺點：

提取單個文件時，需要掃描整個layer。

同一層多個文件的提取不支持并行處理。

因此，使用OverlayFS的容器在啟動前必須完成所有tgz文件的拉取和解壓，這無疑增加了啟動時間。

針對這些問題，社區已經提出了一些改進措施，具有代表性的兩個解決方案是Stargz和DADI。

1.2.2 已有的改進方案

Stargz 是一種容器鏡像加速技術，它采用了 Google的CRFS（Container Registry Filesystem）來重新組織容器鏡像，以便實現更快的容器啟動和更高效的文件檢索。CRFS是一個只讀的用戶態文件系統，它使用了新的文件格式，使得鏡像層內的文件可以被隨機訪問（seekable）。

stargz架構圖

使用Stargz啟動容器時，無需拉取所有層到本地，而是遠程掛載每一層到本地目錄組成rootfs，從而實現容器的快速啟動。容器啟動之后的數據訪問則是利用FUSE(用戶態文件系統)按需獲取。

DADI(Data Accelerator for Disaggregated Infrastructure)是阿里云針對容器加速的解決方案，DADI 的核心組件是 Overlaybd，這是一種基于塊設備的鏡像格式，提供了在block-based layer之上的一個合并視圖，然后通過TCMU在Host上產生一個SCSI設備作為rootfs。TCMU（Target Core Module In Userspace），是scsi target的用戶態實現，用于生成一個容器 rootfs 的 SCSI 設備。

DADI架構圖

使用DADI啟動一個容器時，其也不用拉取所有層到本地，只是基于所有層塊設備創建一個scsi device表示rootfs，實現容器的快速啟動。容器啟動之后的數據訪問則是由tcmu按需獲取，并且加入了本地緩存和ZFile加速數據的讀取。

1.2.3 問題總結

綜上所述，以上方案在實際應用中仍然存在以下問題：

傳統OverlayFS容器的冷啟動時間較長，這可能會對性能敏感的應用造成影響，導致較差的用戶體驗。

改進方案中的用戶態文件系統需要占用一定的主機資源，這可能會對系統的整體性能產生影響。

2.方案介紹

2.1.整體架構

為了解決上述問題，我們構建了基于DPU的容器冷啟動解決方案，以k8s為底座，以存儲為核心，利用DPU的卸載和加速能力，使容器的冷啟動更快，占用更少的host資源。整體架構如下所示：

1-4）：containerd會調用yusur-snapshotter準備rootfs每一層的內容快照，image-mgmt根據label參數連接存儲，創建spdk bdev。

5-9）：到最后一層時，需要創建NVMe subsystem/ctrl/ns，關聯spdk bdev，此時在host側給相應PCI綁定NVMe驅動，即可看到對應的NVMe disk。

10）：yusur-snapshotter查到disk之后，按照不同的鏡像格式生成容器啟動的rootfs。

采用本方案啟動容器時，首先DPU會通過NVMe/RDMA的方式連接遠端存儲，實現高效的數據傳輸，然后通過NVMe PCIE的方式直通給host，最后host基于這個直通的disk生成rootfs并啟動容器。由于云盤原生支持按需讀取的特性，本方案在容器啟動過程中無需拉取鏡像，從而顯著加快容器的啟動過程。

2.2.方案描述

當使用本方案啟動容器時，首先需要進行鏡像轉換，鏡像轉換的主要作用是將原始鏡像按照 Lvol（邏輯卷）的方式落地到存儲中，并將鏡像元數據推送至鏡像倉庫，供容器啟動時使用。

同時本方案在鏡像轉換時支持兩種鏡像格式yusur-overlayfs和yusur-overlaybd。yusur-overlayfs和原生的鏡像格式一樣，按照overlay的方式生成rootfs，主要用于兼容overlay的場景；yusur-overlaybd以塊設備的方式作為rootfs，原生支持可寫層和理論上性能較overlayfs好。

2.2.1.鏡像轉換

鏡像轉換主要責任是基于SPDK snapshot機制把原生鏡像按需轉換成以上兩種格式的鏡像，鏡像數據存到存儲，元數據存到鏡像倉庫。鏡像轉換有兩種工作模式：普通模式和DPU模式。在DPU模式下，能利用DPU的加速能力，可以顯著加快鏡像轉換的速度。

普通模式的架構如下圖所示，其組件主要包含image-ctrl，attacher service，opi-spdk-bridge和原生spdk。

紅色線條表示數據走向，job拉取原鏡像層數據，按不同鏡像格式寫到nbd設備中。各個組件的作用如下：

Image-ctrl，鏡像控制器：接收鏡像轉換yaml，創建轉換job。job負責創建塊存儲，調用attach service創建和克隆lvol，完成鏡像層數據寫入lvol和推送轉換后鏡像元數據至倉庫。

Attacher service：對opi-bridge操作的抽象，對上提供opi-bridge的能力

Opi-spdk-bridge：對接原生SPDK的opi-bridge，提供原生SPDK的基本操作

SPDK：原生SPDK提供快照，克隆的能力

DPU模式的架構如下圖所示，其組件主要包含image-ctrl，image-mgmt，attacher ，opi-bridge和DPU spdk。

紅色線條表示數據走向，job拉取原鏡像層數據，按不同鏡像格式寫到NVMe disk中，各個組件的作用如下：

Opi-bridge：提供不通DPU的存儲能力API

SPDK：不同DPU的SPDK 服務，提供NVMe disk的模擬功能

2.2.2.鏡像格式

使用兩種鏡像創建容器時，處理流程基本一致，差異在鏡像數據的組織方式和rootfs的組成方式，yusur-overlayfs鏡像格式如下所示。

如上圖所示，鏡像X:A完成鏡像轉換之后，生成數據A，鏡像X:B在轉換時直接使用這部分數據，鏡像X:B其他數據基于克隆的lvol寫入。共享數據可以包含一個或多個lvol，它們之間也是通過clone鏈接在一起。

yusur-overlaybd的鏡像格式如下圖所示，與yusur-overlayfs鏡像每層數據寫到lvol不同目錄的方式不同，yusur-overlaybd的鏡像數據會直接寫入lvol。

兩種鏡像格式的rootfs組成如下圖所示。

yusur-overlaybd以nbd設備作為rootfs，不用額外的可寫層；而yusur-overlayfs是以塊設備中的多個目錄作為lowerdir，然后加一個可寫層作為upperdir構成rootfs。

2.2.3.容器啟動

容器啟動流程請參考”整體架構”章節。當用轉換鏡像啟動容器時，containerd會根據鏡像元數據生成一些labels，這些labels會作為參數傳遞給yusur-snapshotter，yusur-snapshotter會根據這些labels，創建不同的存儲target。

目前支持兩種形式的存儲target，本地AIO和遠程NVMe-OF，NVMe-OF同時又支持兩種連接方式NVMe/TCP和NVMe/RDMA。在容器啟動過程中主要涉及以下組件yusur-snapshotter，image-mgmt service和attacher service，作用如下：

Yusur-snapshotter：實現containerd的snapshotter接口，負責準備容器啟動的rootfs

Image-mgmt service：和snapshotter交互，以AIO或NVMe-OF的方式創建和掛載塊設備。

3.方案測試結果

3.1.功能測試

3.1.1.鏡像轉換

創建鏡像轉換CR之后，控制器就會創建job進行鏡像轉換。以下是yusur-overlayfs和yusur-overlaybd轉換成功的截圖：

轉換成功之后，會更新CR status，blocks會包含目的鏡像對應存儲的卷，多個卷之間是以clone的方式遞進，以yusur-overlayfs為例，如下所示：

轉換成功之后，目的鏡像會推送至鏡像倉庫，其作用是在容器啟動時，提供存儲相關的元數據，如下所示：

Annotation中包含該層所在的塊設備，鏡像格式，文件系統等信息，這些信息會作為labels傳遞給yusur-snapshotter。

3.1.2.Pod啟動

pod啟動之后，可以查看rootfs組成，如下所示：

Yusur-overlayfs:

overlayfs格式的鏡像，塊設備中包含鏡像的每一層數據，掛載后把相關層目錄，bind到對應的snapshot，構成overlay的lowerdir。

Yusur-overlaybd:

overlaybd格式的鏡像, 塊設備中包含鏡像的rootfs；沒有把塊設備直接作為容器啟動的rootfs，考慮到還需要一個可寫層，所以基于塊設備創建一個qcow2的本地文件，然后本地文件通過nbd暴露出來，作為容器啟動的rootfs和可寫層。

3.2.性能測試

性能測試包括5種方案，本方案提供了其中的兩種yusur-overlayfs/NVMe/RDMA和yusur-overlaybd/NVMe/RDMA。yusur-overlayfs/NVMe/RDMA表示鏡像格式是yusur-overlayfs，存儲target是NVMe-OF，連接方式是RDMA；yusur-overlaybd/NVMe/RDMA同yusur-overlayfs，只是鏡像格式不同。

3.2.1.Containerd下的容器啟動耗時測試

我們將測試整個容器啟動過程中的時間消耗，具體分為三個階段：鏡像拉取、容器創建和服務ready。

如上圖所示，縱坐標表示容器ready時間（單位：秒），橫坐標表示鏡像名稱。由于此場景只是去掉了k8s的影響，結論同2.2.1, 如下：

本方案的yusur-overlayfs較overlayfs有63%的性能提升，因為不用拉取所有數據到本地；

本方案的yusur-overlaybd較DADI overlaybd有34%的性能提升，是因為本方案io路徑更短。

如上圖所示，可以得出如下結論：

overlaybd鏡像拉取是最快的，因為overlaybd在這個過程中只生成TCMU的config文件；

本方案的兩種方法都較overlaybd慢，是因為本方案在鏡像拉取中需要掛載云盤。

stargz也比overlaybd慢，是因為stargz在鏡像拉取中需要掛載用戶態文件系統

如上圖所示，可以得出如下結論：

由于 OverlayFS 的數據已經在本地，因此 OverlayFS 的容器創建時間僅包括 runc 的操作以及啟動命令的時間。

本方案的兩種方法中，容器創建時間較高，因為本方案的 rootfs 基于 DPU 提供的云盤，yusur-snapshoter 需要創建 NVMe 系統（前端）并執行找盤操作。

stargz 在 CentOS 上消耗的時間較多，是因為 stargz 需要預加載（在這里需要預拉取 80M 的數據，主要時間消耗在這里）。

對于 overlaybd，由于其原理上與本方案基本相同，都是利用文件系統實現按需拉取，因此時間上基本差不多。

如上圖所示，可以得出如下結論：

容器gcc消耗時間基本沒有，是因為gcc啟動命令只是執行了gcc --version，這個在容器創建時，已經就執行完了

OverlayFS 的耗時最短，因為在鏡像拉取階段，鏡像數據已經被下載并存儲在本地

Stargz由于前一過程預拉取了部分數據，所以總體時間上略高于OverlayFS。

本方案的 yusur-overlaybd 優于 overlaybd，主要是因為它在后期數據讀取方面表現更佳。與 overlaybd 需要通過 TCMU 定位文件偏移量并使用 HTTP Range Request 向 registry 請求數據的方式不同，本方案直接通過內核 VFS，并采用 NVMe/RDMA 的方式進行數據傳輸，因而具有更低的延遲。

本方案的 yusur-overlayfs 相較于 stargz 和 overlayfs 表現稍遜，主要原因在于 overlayfs 的數據已存儲在本地，而 stargz 在容器啟動前已完成熱點數據的預提取，而本方案則缺少數據預提取這一過程。

3.2.2.鏡像轉換耗時測試

由于兩種鏡像格式相差不大，故采用 yusur-overlayfs 作為對比，測試結果如下所示：

如上圖所示，縱坐標表示不同模式下鏡像轉換時間（單位：秒），橫坐標表示鏡像名稱。可以得出如下結論：

基于DPU的鏡像轉換方案可以降低鏡像轉換的時間，但是效果不是太明顯。不明顯的原因是受制于后端存儲CEPH，導致RDMA發揮不出優勢。

3.3.資源消耗測試

3.3.1.CPU消耗測試

stargz兩次測試結果：如圖所示，CPU最高使用率20.17%，平均使用率4.22%。

overlayfs兩次測試結果：如圖所示，CPU最高使用率14.77%，平均使用率2.78%。

overlaybd兩次測試結果：如圖所示，CPU最高使用率11.4%，平均使用率3.27%。

yusur-overlayfs兩次測試結果：如圖所示，CPU最高使用率7.66%，平均使用率1.95%。

yusur-overlaybd兩次測試結果：如圖所示，cpu最高使用率10.02%，平均使用率2.17%。

整體使用率較yusur-overlayfs高，從system使用率觀察可以得出是nbd這一層導致的。

匯總結果如下：

從以上所有圖片，得出如下結論：

本方案的最高CPU使用率最低;

本方案的cpu高利用率維持時間最短，只有30s左右。

3.3.2.內存消耗測試

stargz兩次測試結果：如圖所示，最高內存使用7.67G，平均內存使用6.86G。

overlayfs兩次測試結果：如圖所示，最高內存使用5.71G，平均內存使用5.16G。

overlaybd兩次測試結果：如圖所示，最高內存使用5.21G，平均內存使用4.94G。

yusur-overlayfs兩次測試結果：如圖所示，最高內存使用5.28G，平均內存使用4.87G。

yusur-overlaybd兩次測試結果：如圖所示，最高內存使用5.62G，平均內存使用5.01G。

匯總結果如下：

從以上所有圖片，得出如下結論：

本方案的消耗的內存最低；

本方案的內存高消耗維持時間最短，只有60s左右。

4.總結

4.1.測試結果總結

在 K8s 場景下，本方案的 yusur-overlayfs 相比于傳統方案 overlayfs，性能提升了 57%；而相比改進方案 DADI，yusur-overlaybd 的性能也提升了 20%

在 Containerd 場景下，本方案的 yusur-overlayfs 相比傳統方案 overlayfs，性能提升了 63%；而 yusur-overlaybd 相較于改進方案 DADI，性能也提升了 34%。

控制面和數據面下沉至 DPU，有效減少了主機資源的消耗。從測試結果來看，本方案的 CPU 和內存占用率以及持續時間均為最低。

從鏡像cypress-chrome（624.2 MiB）、centos(1.3GiB)、tensorflow-notebook(1.7 GiB)的啟動時間看，在本方案中，容器冷啟動時間隨著鏡像大小的增加，其時間優勢變得越加明顯。

從鏡像轉換的測試結果來看，鏡像越大，基于 DPU 的方案在時間上表現出越明顯的優勢，因為它能夠利用 DPU 的 RDMA 能力。類推到容器啟動過程中，所需的數據量越大，本方案的優勢也會越加顯著。

4.2.方案價值

基于DPU的容器冷啟動加速解決方案具有如下價值：

1、提升服務響應速度和用戶體驗：在FaaS中，由于函數實例是動態創建的，首次調用函數時可能會遇到冷啟動延遲，即容器從停止狀態到運行狀態所需的時間。快速冷啟動技術能夠顯著縮短這一時間，使得用戶請求能夠更快地得到響應，從而提升用戶體驗。

2、提高業務吞吐量：快速冷啟動使得FaaS平臺能夠在短時間內啟動更多的函數實例，以應對突發的流量高峰，從而提高業務的整體吞吐量。

3、提高系統可用性：在微服務架構和分布式系統中，服務的快速冷啟動可以確保在服務實例故障時，能夠迅速恢復服務，減少服務中斷時間，提高系統的整體可用性。

4、提升資源利用效率：控制面和數據面下沉至 DPU，有效減少了主機資源的消耗，這意味著在實際應用場景中，將大大節省了寶貴的CPU和內存資源，讓這些資源能夠被應用服務更高效地利用。

綜上所述，基于DPU的容器冷啟動加速解決方案對于提升服務響應速度和用戶體驗、提高業務吞吐量、提高系統可用性、提升資源利用效率等方面都具有重要的價值和意義，隨著云原生和無服務器計算的不斷發展，該方案將具有廣闊的應用前景。

本方案來自于中科馭數軟件研發團隊，團隊核心由一群在云計算、數據中心架構、高性能計算領域深耕多年的業界資深架構師和技術專家組成，不僅擁有豐富的實戰經驗，還對行業趨勢具備敏銳的洞察力，該團隊致力于探索、設計、開發、推廣可落地的高性能云計算解決方案，幫助最終客戶加速數字化轉型，提升業務效能，同時降低運營成本。

審核編輯 黃宇