騰訊云：ImageApparate(幻影)鏡像加速服務(wù)讓鏡像分發(fā)效率提升5-10倍

背景

在業(yè)務(wù)普遍已經(jīng)完成容器化的大環(huán)境下，不同的業(yè)務(wù)場景對于容器啟動需求也是不同的，在離線計算和一些需要快速增加計算資源（伸縮組）的在線服務(wù)場景下，往往對于容器的啟動速度有較高的要求。

在容器啟動的整個周期中鏡像拉取的時間往往占據(jù)70%甚至更多。據(jù)統(tǒng)計，某離線計算業(yè)務(wù)因容器鏡像較大，每次擴容上千Pod耗時高達40分鐘。鏡像分發(fā)成為容器快速彈性伸縮的主要障礙。

ImageApparate(幻影)

為了解決這個問題，騰訊云容器服務(wù)TKE團隊開發(fā)了下一代鏡像分發(fā)方案ImageApparate(幻影),將大規(guī)模大鏡像分發(fā)的速度提升5-10倍。

應(yīng)對既有Docker下載鏡像模式帶來的問題，社區(qū)新方案的討論主要在鏡像數(shù)據(jù)的延遲加載(Lazy-Pull)和新鏡像格式的設(shè)計不再以層為最小單位，而是chuck或者鏡像內(nèi)文件本身。

不過，目前看OCI V2離我們依然還很遠，當前我們通過何種方式來應(yīng)對這類場景呢？

回到問題本身，當前OCI V1和容器運行時交互邏輯需要先下載完整鏡像才能運行容器，但是容器啟動和運行時到底會使用鏡像內(nèi)的多少內(nèi)容，這篇論文FAST'16[1]統(tǒng)計了DockerHub中一些常見的官方鏡像在其使用啟動后需要讀取的數(shù)據(jù)量，得出的結(jié)論是僅有平均6.4%的內(nèi)容需要讀取。也就是說鏡像中的大部分內(nèi)容可能在容器的整個生命周期內(nèi)根本不需要，那么如果我們只加載6%的數(shù)據(jù)就可以大幅減少鏡像拉取時間，從而加速容器啟動速度，這也就為后續(xù)的優(yōu)化提供了理論前提。

因此減少容器啟動時間的重點就在容器的rootfs即容器鏡像的獲取上。

基于此前提，在兼容OCI V1的框架下，TCR推出了ImageApparate(幻影)容器鏡像加速服務(wù)。首先直接放結(jié)論，在200節(jié)點且鏡像內(nèi)容占鏡像總大小的5%到10%。如上所述，相比于傳統(tǒng)的下載全部鏡像的方式，ImageApparate在容器全部啟動時間上都有5-10倍的提升。而且本測試主要并不只是關(guān)注容器創(chuàng)建時間，而是繼續(xù)測試了從容器啟動到業(yè)務(wù)進程可以提供服務(wù)后的總體時間：

·順序讀取500MB大文件測試了包括從容器啟動后到順序讀取500MB文件完成后的時間

·隨機讀取1000小文件測試了包括從容器啟動后到隨即讀取1000個4k-16k完成后的時間

·執(zhí)行python程序測試了包括從容器啟動后加載Python解釋器執(zhí)行一段簡單的python代碼完成后的時間

·執(zhí)行g(shù)cc編譯測試了包括從容器啟動后執(zhí)行g(shù)cc編譯一段簡單C代碼并運行完成后的時間

ImageApparate方案設(shè)計

傳統(tǒng)模式的問題

自Docker發(fā)布以來云計算領(lǐng)域發(fā)生了巨大的變革，傳統(tǒng)虛擬機逐步被容器替代。Docker秉持Build,Ship And Run的理念出色的完成了容器運行時和容器鏡像的設(shè)計，引領(lǐng)整個容器行業(yè)。但是隨著時間的推移容器的Ship And Run在面對廣泛的用戶需求場景中也逐漸暴露出一些問題。

傳統(tǒng)容器啟動和鏡像下載方式為：

1.訪問鏡像倉庫服務(wù)獲取權(quán)限認證以及獲取鏡像存儲地址

2.通過網(wǎng)絡(luò)訪問鏡像存儲地址下載全部鏡像層并解壓

3.根據(jù)鏡像的層信息使用聯(lián)合文件系統(tǒng)掛載全部層作為rootfs，在此文件系統(tǒng)上創(chuàng)建并啟動容器

容器鏡像的設(shè)計從Docker發(fā)布至今一直沿用下來，并已經(jīng)成為事實標準也就是我們現(xiàn)在使用的OCI V1，使用分層的設(shè)計大大減少空間占用，利用各類聯(lián)合文件系統(tǒng)(Aufs、Overlayfs)將每層聯(lián)合掛載起來形成一個完整的RootFS只讀根文件系統(tǒng)，容器運行時的寫入操作會在聯(lián)合文件系統(tǒng)的最上層的讀寫層，非常精巧的設(shè)計。

但是，開發(fā)者和用戶對于速度追求是永無止境的，隨著業(yè)務(wù)上云的廣泛普及，為了充分發(fā)揮云上資源的彈性能力，用戶往往需要新擴出來的計算節(jié)點可以用最快的速度使用容器化的計算能力（容器啟動服務(wù)可以接受流量），而此時這個全新節(jié)點就需要下載容器鏡像全部的層，大大拖慢容器啟動速度，在這個場景下容器鏡像的分層設(shè)計沒有得到充分的利用，完全失效了。

針對OCI V1容器鏡像格式的一些問題社區(qū)也開始有集中的討論，當前tar包作為OCI V1的鏡像層分發(fā)格式主要有以下問題：

1.不同層之間的內(nèi)容冗余

2.沒有基于文件的尋址訪問能力，需要全部解包后才能訪問

3.沒有并發(fā)解包能力

4.使用whiteout處理文件刪除在不同存儲類型中轉(zhuǎn)換導(dǎo)致解壓效率低下

TCR-Apparate OCI制品

我們設(shè)計的目標是面向生產(chǎn)級別，在節(jié)點上同時支持鏡像加速模式和普通模式，為了和正常OCI V1鏡像存儲解耦，我們開發(fā)了鏡像附加存儲IAS(ImageAttachStorage)結(jié)合鏡像Manifest中的外部層類型(Foreign Layer)，可以在契合OCI V1語義下完成加速鏡像的制作、上傳和下載，繼承原有鏡像權(quán)限的同時，加速后的鏡像Manifest索引以O(shè)CI制品形式存儲在鏡像倉庫本身的存儲中。

在鏡像格式方面為了支持按需加載和克服tar格式之前的一些缺點，ImageApparate使用了只讀文件系統(tǒng)代替了tar格式。只讀文件系統(tǒng)解決了鏡像層內(nèi)文件尋址能力同時又具備成為Rootfs可靠的性能。ImageApparate仍然使用分層的設(shè)計在Manifest外部層中直接指定附件存儲地址，附加存儲層IAS在下載鏡像時就可以按需掛載。

用戶開啟鏡像加速功能并設(shè)置相關(guān)規(guī)則后，push鏡像后ImageApparate會在后臺運行如下流程：

1.用戶以任意符合OCI V1接口標準的客戶端(包括Docker)Push鏡像到TCR倉庫

2.TCR的鏡像服務(wù)會將用戶數(shù)據(jù)寫入到鏡像倉庫本身的后端存儲中，一般為COS對象存儲。

3.TCR的鏡像服務(wù)會檢查鏡像加速規(guī)則，如果符合規(guī)則會給Apparate-client組件發(fā)出Webhook通知，請求轉(zhuǎn)換鏡像格式。

4.Apparate-client組件收到通知后會把COS數(shù)據(jù)寫入到IAS中，使用特定算法把此鏡像的每個Layer逐個轉(zhuǎn)換為支持ImageApparate掛載的Layer格式。

因此，對于TCR用戶來說只需要定義規(guī)則標記哪些鏡像需要加速，而CI/CD的使用方式上沒有任何變化，原來的開發(fā)模式順理成章地繼承下來。

鏡像附加存儲IAS(ImageAttachStorage)

顧名思義，狹義的鏡像附加存儲IAS是除了本身的鏡像后端存儲之外的數(shù)據(jù)存儲地址，IAS既可以和鏡像倉庫的使用相同的對象存儲，也可以使用NFS或者Lustre。Apparate中的鏡像附加存儲除了存儲地址外，還包含一套插件化的接口（兼容Posix）和鏡像層IAS中的布局（Layout）。IAS中每個目錄代表一個Layer，這里依然會使用基于內(nèi)容尋址(Content Addressable)復(fù)用內(nèi)容相同層，只讀文件系統(tǒng)文件包含了這個原始層中的全部內(nèi)容，隨時可以通過加載元數(shù)據(jù)索引獲取整個目錄樹。目前Apparate使用了騰訊云CFS[2]高性能版作為IAS的一種實現(xiàn)，高吞吐低延遲CFS目前和鏡像下載場景非常契合。

鏡像本地緩存由不同的IAS附加存儲插件自身實現(xiàn)，目前CFS實現(xiàn)使用了FScache框架作為本地緩存可以自動按頁緩存訪問過的在遠端存儲上的部分數(shù)據(jù)，根據(jù)當前磁盤通過本地緩存能力，有效提升鏡像數(shù)據(jù)重復(fù)訪問的性能和穩(wěn)定性。

運行時實現(xiàn)

當前ImageApparate在節(jié)點上使用的IAS附加存儲插件被稱之為Apparate-snapshotter，是通過containerd的proxy-snapshotter能力實現(xiàn)的。

Apparate-snapshotter主要負責解析記錄在鏡像層中的IAS信息，從而拿到另外數(shù)據(jù)存儲地址，接下來Apparate-snapshotter會去數(shù)據(jù)存儲服務(wù)中加載遠程數(shù)據(jù)，并在本地提供訪問的Posix入口。

比如在CFS場景下，會把遠端數(shù)據(jù)mount到本地，并把掛載點作為接下來本地訪問的入口。當需要使用遠端數(shù)據(jù)時便由snapshotter或內(nèi)核來提供按需加載的能力。

只讀鏡像格式

對于支持Lazy-Pull的鏡像文件系統(tǒng)來說，只讀是非常關(guān)鍵的屬性，因為只讀文件系統(tǒng)不需要考慮數(shù)據(jù)寫入和刪除造成的碎片和垃圾回收，可以提前在制作文件系統(tǒng)的時候優(yōu)化數(shù)據(jù)塊和索引的分布，這樣可以大幅提高文件系統(tǒng)的讀取性能。

當前IAS支持的只讀文件系統(tǒng)還增加了基于字母順序排序的目錄項索引(directory index)，可以大大加速目錄項的Lookup操作。

ImageApparate在TCR中使用方式

創(chuàng)建加速組件

當前ImageApparate在TCR中為alpha功能需要白名單開啟。開啟加速組件需要選擇對應(yīng)CFS的高性能版，請確認所在地域有此版本CFS。

創(chuàng)建加速規(guī)則

創(chuàng)建加速規(guī)則，只有規(guī)則中匹配的鏡像或者Tag才會自動加速。之后再向TCR推送鏡像后可以看到匹配加速規(guī)則的鏡像會生成后綴為-apparate的OCI制品。

TKE集群側(cè)開啟加速功能

在TKE集群中創(chuàng)建TCR插件時開啟鏡像加速配置，之后可以給需要加速的集群中節(jié)點打標簽kubectl label node xxx cloud.tencent.com/apparate=true，集群中Pod的鏡像可以仍然使用原鏡像名字(例如上述test/nginx:1.9)，加速插件支持自動選取已加速的鏡像來進行掛載。如果鏡像已被加速，那么觀察TKE集群中Pod的image字段可以看到已被替換為test/nginx:1.9-apparate。

后續(xù)工作

當容器鏡像是按需加載后，Layer（層）可能已經(jīng)不再是復(fù)用的最小單位了，ImageApparate后續(xù)也會探索基于文件或者塊鏡像格式以及轉(zhuǎn)換工具以獲得更高的性能和效率。在接口側(cè)鏡像附加存儲IAS也會支持更多數(shù)據(jù)源，包括和TKE P2P組件的集成，按需加載與P2P結(jié)合可以更好的應(yīng)對超大規(guī)模鏡像加載場景，大大減輕源站壓力。

參考資料

[1]FAST'16:https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter

[2]CFS:https://console.cloud.tencent.com/cfs

[3]Slacker:Fast Distribution with Lazy Docker Containers:https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter

[4]Image Manifest V 2,Schema 2:https://docs.docker.com/registry/spec/manifest-v2-2/

[5]General Filesystem Caching:https://www.kernel.org/doc/Documentation/filesystems/caching/fscache.txt

[6]EROFS:A Compression-friendly Readonly File System for Resource-scarce Devices:https://www.usenix.org/system/files/atc19-gao.pdf