XSKY將100個(gè)Pod掛載卷的時(shí)間縮短10倍

01CSI發(fā)展和現(xiàn)狀

XSKY早在2018年底就實(shí)現(xiàn)了容器存儲(chǔ)接口(CSI) driver，而CSI也在2018年底發(fā)布的Kubernetes(K8s) v1.13版本中正式GA，現(xiàn)在已經(jīng)成為了容器和存儲(chǔ)的標(biāo)準(zhǔn)接口。

作為國內(nèi)率先擁抱CSI的存儲(chǔ)廠商，XSKY開始CSI driver是使用塊(iSCSI)對(duì)接的，后來又支持文件(NFS)對(duì)接，經(jīng)過一年多的驗(yàn)證，目前已經(jīng)十分穩(wěn)定并為各大客戶提供了穩(wěn)定的容器化場(chǎng)景支持。

Kubernetes CSI后來推出了越來越多的新特性，XSKY緊隨社區(qū)步伐，不斷更新迭代，先后支持了各種實(shí)用的新特性，包括擴(kuò)容，裸卷，快照等。但是，僅僅是"多"還不夠，正所謂“天下武功，唯快不破”，我們?cè)?quot;快"上也花了一點(diǎn)功夫。

圖一：圖片來源網(wǎng)絡(luò)

眾所周知，容器相比虛擬機(jī)要更加輕量，在K8s集群中，運(yùn)行著眾多的Pod，由于容器是應(yīng)用級(jí)的隔離環(huán)境，相比虛擬機(jī)而言，一個(gè)K8s集群里面Pod的數(shù)量從幾十個(gè)到幾萬個(gè)的場(chǎng)景都會(huì)存在，因此，在大規(guī)模調(diào)度的時(shí)候?qū)Τ志镁淼墓芾砜梢哉f是很關(guān)鍵的操作。

但是在使用過程中，如果發(fā)生大規(guī)模的調(diào)度時(shí)候難免有些不理想的情況，舉個(gè)例子，在最初正式支持CSI的K8s 1.13版本，一個(gè)常見的問題是掛載的時(shí)候經(jīng)?？吹絇od調(diào)度完成后出現(xiàn)Attach timeout的警告，這就是一個(gè)最常見的掛載超時(shí)場(chǎng)景。

02原因分析

首先明確問題之前我們回顧下之前分享過的文章有提到K8s和存儲(chǔ)是如何交互的。

圖二

早前的文章《詳解支持 kubernetes CSI的持久化容器存儲(chǔ)》有具體介紹一個(gè)PV的產(chǎn)生和掛載的具體流程， 這里不妨再溫習(xí)一次，為簡化模型，我們把整個(gè)流程分成兩部分。

從用戶提交一個(gè)pvc.yaml文件開始，上圖1，2，3，4步驟我們稱之為provisioning過程，它的作用是從API server開始創(chuàng)建一個(gè)卷的流程。從PV掛載到實(shí)際使用的容器或者說業(yè)務(wù)Pod的過程稱之為Publish Volume。相對(duì)應(yīng)的是上圖5，6，7，8。

不難看出，一個(gè)存儲(chǔ)卷的使用過程是經(jīng)過多階段的處理，調(diào)用方式也是包括且不限RESTful接口，RPC調(diào)用，以及其他各進(jìn)程間狀態(tài)同步，因此整套流程下來需要考慮的問題比較多。

其中provision過程即創(chuàng)建PV的過程實(shí)測(cè)還是比較快的，100個(gè)卷的創(chuàng)建僅需幾十秒，所以暫時(shí)也不需要優(yōu)化。

而對(duì)于掛載卷的流程可以看到external attacher和kubelet這兩個(gè)組件都會(huì)調(diào)用XSKY CSI driver來對(duì)卷進(jìn)行掛載處理。由于這兩步都是通過gRPC實(shí)現(xiàn)遠(yuǎn)程調(diào)用，在比較早的K8s版本中，它們是硬編碼，超時(shí)時(shí)間為15秒，此外對(duì)于未完成的或失敗請(qǐng)求有指數(shù)退避算法重試。

也就是說，在一次重試后暫時(shí)掛載不上它會(huì)在30秒后再重試，再失敗就60秒，如果請(qǐng)求數(shù)比較少的情況沒有太大問題，但如果是在大批量容器同時(shí)調(diào)度的過程中這種場(chǎng)景就出現(xiàn)較多重試的情況，因?yàn)閽燧d請(qǐng)求下發(fā)到存儲(chǔ)集群后并不能馬上就處理完成，而K8s對(duì)這些請(qǐng)求只等待15秒，所以有相當(dāng)一部分的請(qǐng)求并未正確處理，再加上指數(shù)退避重試機(jī)制，如果存儲(chǔ)底層有較多卷請(qǐng)求堆積未處理完成，那K8s的重試間隔將越拉越長，甚至拉到10幾分鐘之后。

掛載卷的操作我們簡化為三步動(dòng)作，即向存儲(chǔ)集群發(fā)起添加卷到訪問路徑，在K8s Node節(jié)點(diǎn)上掃描設(shè)備，以及格式化和掛載，對(duì)于并發(fā)的請(qǐng)求而言，有很多是在阻塞著，如果同時(shí)調(diào)度Pod發(fā)起掛載操作的話，就有可能出現(xiàn)K8s的重試間隔越拉越長。對(duì)于用戶而言就是過了很久還沒有把所有Pod啟動(dòng)成功。

圖三

上圖展示了并發(fā)掛載的過程，由于阻塞式掛載導(dǎo)致PublishVolume請(qǐng)求被越拖越長，因此一部分的掛載操作很容易就到達(dá)15秒的超時(shí)上限，然后等待下一次重試。

03優(yōu)化

回顧“圖二”的掛載流程，我們把整套流程自上而下進(jìn)行分層分析，分別是K8s平臺(tái)層， CSI driver中間層，xmsd控制層以及XDC存儲(chǔ)管理層。針對(duì)每個(gè)層面都做了一些優(yōu)化和調(diào)整。

1、K8s頂層優(yōu)化

圖四

K8s Pod掛載卷時(shí)候主要是external attacher和kubelet兩個(gè)組件來調(diào)用CSI driver，因此可以從這兩者著手：external attacher是一個(gè)sidecar容器，負(fù)責(zé)監(jiān)聽K8s集群中的volumeattachment對(duì)象，每當(dāng)controller manager生成一個(gè)volumeattachment對(duì)象時(shí)就代表K8s內(nèi)要進(jìn)行一次卷掛載操作，external attacher監(jiān)聽到此對(duì)象的產(chǎn)生時(shí)候就開始向XSKY 的CSI driver發(fā)起一個(gè)RPC請(qǐng)求，完成第一階段處理。

默認(rèn)這個(gè)external attacher只有10個(gè)協(xié)程去處理這樣的監(jiān)聽事件，這對(duì)于普通場(chǎng)景使用尚且可以，但是對(duì)于大規(guī)模的集群就未必是最佳值?？紤]到用戶場(chǎng)景的不同，我們向社區(qū)提交了一個(gè)PR將工作協(xié)程數(shù)改成可配置，這樣既不會(huì)有API breaking change，又能根據(jù)用戶所在集群動(dòng)態(tài)配置，比如在這種存在大批量并發(fā)的K8s集群默認(rèn)使用的是100個(gè)worker，以達(dá)到最佳監(jiān)聽效果。

Kubelet是一個(gè)核心組件，它也是直接參與了持久卷掛載的操作，在完成第一階段的請(qǐng)求后，由kubelet向CSI driver發(fā)起另一個(gè)RPC請(qǐng)求。

前面提到由于kubelet每次請(qǐng)求設(shè)置的超時(shí)時(shí)間只有15秒，顯然對(duì)于很多存儲(chǔ)商而言15秒其實(shí)還是不夠的，開源社區(qū)也有其他成員討論過這一點(diǎn)。經(jīng)過大家實(shí)踐后得出的結(jié)論是，建議最佳值為2分鐘。

雖然這是一個(gè)小改動(dòng)，但是對(duì)于存儲(chǔ)端而言極大提升了一次掛載成功的概率，一定程度上減少了很多無意義的重試，不至于把重試間隔拉到10分鐘以上，對(duì)于用戶體驗(yàn)的提升也是比較明確的。因此，建議有條件的優(yōu)先使用更新版本的Kubernetes。

2、CSI driver優(yōu)化

為方便理解，前面描述Kubernetes掛載卷的操作，我們簡化為一個(gè)PublishVolume動(dòng)作，其中包含3步耗時(shí)操作，包括AddVolume，ScanDevice和Format。

其中AddVolume是直接調(diào)用XMS的接口實(shí)現(xiàn)，我們后面會(huì)介紹這部分優(yōu)化?，F(xiàn)在我們關(guān)注在ScanDevice。

ScanDevice的優(yōu)化：向訪問路徑添加卷操作完成之后，CSI driver開始在K8s 的node節(jié)點(diǎn)上掃描iSCSI設(shè)備，這里掃描設(shè)備的操作就基于iscsiadm來完成的，當(dāng)有大量Pod在掛載卷的準(zhǔn)備過程，可以發(fā)現(xiàn)存在大量的iscsiadm命令在執(zhí)行，這對(duì)于同一個(gè)節(jié)點(diǎn)而言很多都是重復(fù)的請(qǐng)求，比如說Pod A添加完卷操作后調(diào)用 iscsiadm 來發(fā)現(xiàn)和登陸，同時(shí)Pod B添加完成后也調(diào)用 iscsiadm來登陸和刷新，假如同一個(gè)Node上有100個(gè)Pod，那甚至?xí)霈F(xiàn)數(shù)百個(gè) iscsiadm進(jìn)程，這對(duì)于target端而言反而是增大負(fù)載，刷新進(jìn)程的數(shù)量多并不會(huì)使發(fā)現(xiàn)設(shè)備的過程加快。

后來經(jīng)過實(shí)踐我們改良了這種實(shí)現(xiàn)，合理復(fù)用了iscsiadm，將服務(wù)器壓力嚴(yán)格控制下來避免這種情況。

鎖的粒度控制：在第一個(gè)CSI driver版本，我們?cè)?jīng)對(duì)很多資源都做了鎖的控制。那是因?yàn)楹秃蠖舜鎯?chǔ)交互的API大多不是為容器場(chǎng)景設(shè)計(jì)的，會(huì)有很多方面的限制，包括資源競爭，狀態(tài)沖突等情況，因此需要在頂層自行控制并發(fā)，結(jié)果就是訪問路徑，客戶端組等資源的操作都加鎖，代價(jià)就是我們的并發(fā)量很多受限于此設(shè)計(jì)。我們重新進(jìn)行了優(yōu)化，現(xiàn)在可以實(shí)現(xiàn)并發(fā)的操作，將來自K8s的請(qǐng)求快速轉(zhuǎn)換到xmsd和XDC層面處理。

3、XMS接口優(yōu)化

XMS (XSKY Management Service) : 即XSKY管理服務(wù)，作為數(shù)據(jù)管理平臺(tái)來提供分布式存儲(chǔ)集群的管理功能，并提供API等方式提供存儲(chǔ)的擴(kuò)展能力。

考慮到容器使用的訪問路徑有概率被管理面誤操作，也為了更快創(chuàng)建所需要的資源，把一些XSKY的資源被抽象定義到Kubernetes集群中，因此可以在K8s集群使用一個(gè)yaml配置文件，一條kubectl create命令即可完成幾乎所有的初始化工作，極大解放了部署成本。

圖五

其中訪問路徑，VIP是通過CRD集成到Kubernetes。由于自定義控制器的工作機(jī)制，總能保障有指定數(shù)量的訪問路徑和網(wǎng)關(guān)組以及VIP的存在，而不擔(dān)心用戶誤操作影響存儲(chǔ)集群的使用。管理員所需要的操作僅僅是一條kubectl命令，然后就等待部署完成。

另外，XMS設(shè)計(jì)初衷并不是針對(duì)容器場(chǎng)景，很多操作基本是互斥，因此很多API請(qǐng)求都被拒絕，效率比較低，于是在后續(xù)的版本已經(jīng)優(yōu)化這一點(diǎn)。使得在API接口層允許并發(fā)添加和移除卷請(qǐng)求，一定程度提高了API的可用性。

Task優(yōu)化：task是XMS的內(nèi)部執(zhí)行單元，它負(fù)責(zé)將API轉(zhuǎn)換為具體的動(dòng)作，比如前面提到的添加卷的行為則對(duì)應(yīng)一個(gè)task，這個(gè)task去調(diào)底層XDC來完成mapping操作。在以前由于接口限制只能一個(gè)一個(gè)往下添加，所以task執(zhí)行的密度并不高。完成優(yōu)化后則可以實(shí)現(xiàn)大量的task同時(shí)執(zhí)行添加映射操作，任務(wù)十分密集。

4、XDC優(yōu)化

XDC (XSKY Data Client): 即XSKY數(shù)據(jù)客戶端，塊存儲(chǔ)網(wǎng)關(guān)，支持iSCSI、FC、SCSI及RBD等不同類型的訪問路徑網(wǎng)關(guān)，XDC服務(wù)提供數(shù)據(jù)QoS、流控、流量，卷管理等功能。

圖六

XDC作為底層最關(guān)鍵的映射管理單元，之前的工作模式都是比較直接，任務(wù)請(qǐng)求逐個(gè)排隊(duì)處理，效率非常低，為了應(yīng)對(duì)容器大規(guī)模場(chǎng)景，我們已經(jīng)重新設(shè)計(jì)成可支持并發(fā)的模型。

04小結(jié)

至此，已經(jīng)從K8s平臺(tái)層到CSI driver，以及內(nèi)部xmsd和XDC每個(gè)層面都進(jìn)行了各種類型的優(yōu)化。對(duì)應(yīng)100個(gè)Pod的掛載，以前需要十幾、二十分鐘到現(xiàn)在一、兩分鐘，時(shí)間縮短10倍，助力用戶建設(shè)高效的容器云平臺(tái)。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。