本篇內(nèi)容主要講解“ImageApparate鏡像有什么用”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“ImageApparate鏡像有什么用”吧!

創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)土默特左旗,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):18980820575

背景

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

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

ImageApparate(幻影)

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

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

不過(guò)，目前看OCI V2離我們依然還很遠(yuǎn)，當(dāng)前我們通過(guò)何種方式來(lái)應(yīng)對(duì)這類場(chǎng)景呢？

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

因此減少容器啟動(dòng)時(shí)間的重點(diǎn)就在容器的 rootfs 即容器鏡像的獲取上。

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

• 順序讀取 500MB 大文件測(cè)試了包括從容器啟動(dòng)后到順序讀取 500MB 文件完成后的時(shí)間

• 隨機(jī)讀取 1000 小文件測(cè)試了包括從容器啟動(dòng)后到隨即讀取 1000個(gè) 4k-16k 完成后的時(shí)間

• 執(zhí)行 python 程序測(cè)試了包括從容器啟動(dòng)后加載 Python 解釋器執(zhí)行一段簡(jiǎn)單的 python 代碼完成后的時(shí)間

• 執(zhí)行 gcc 編譯測(cè)試了包括從容器啟動(dòng)后執(zhí)行 gcc 編譯一段簡(jiǎn)單 C 代碼并運(yùn)行完成后的時(shí)間

ImageApparate 方案設(shè)計(jì)

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

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

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

1. 訪問(wèn)鏡像倉(cāng)庫(kù)服務(wù)獲取權(quán)限認(rèn)證以及獲取鏡像存儲(chǔ)地址

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

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

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

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

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

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

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

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

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

TCR-Apparate OCI制品

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

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

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

1. 用戶以任意符合OCI V1接口標(biāo)準(zhǔn)的客戶端(包括 Docker)Push 鏡像到 TCR 倉(cāng)庫(kù)

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

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

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

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

鏡像附加存儲(chǔ) IAS(ImageAttachStorage)

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

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

運(yùn)行時(shí)實(shí)現(xiàn)

當(dāng)前 ImageApparate 在節(jié)點(diǎn)上使用的IAS附加存儲(chǔ)插件被稱之為 Apparate-snapshotter，是通過(guò) containerd 的 proxy-snapshotter 能力實(shí)現(xiàn)的。

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

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

只讀鏡像格式

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

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

ImageApparate在TCR中使用方式

創(chuàng)建加速組件

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

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

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

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

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

到此，相信大家對(duì)“ImageApparate鏡像有什么用”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

網(wǎng)站名稱：ImageApparate鏡像有什么用
文章鏈接：http://www.rwnh.cn/article14/ghdpde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、App開發(fā)、域名注冊(cè)、手機(jī)網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)