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)。
- 蜜度索驥:以跨模態(tài)檢索技術(shù)助力“企宣”向上生長
- 為什么年輕人不愛換手機(jī)了
- 柔宇科技未履行金額近億元被曝已6個(gè)月發(fā)不出工資
- 柔宇科技被曝已6個(gè)月發(fā)不出工資 公司回應(yīng)欠薪有補(bǔ)償方案
- 第六座“綠動(dòng)未來”環(huán)保公益圖書館落地貴州山區(qū)小學(xué)
- 窺見“新紀(jì)元”,2021元宇宙產(chǎn)業(yè)發(fā)展高峰論壇“廣州啟幕”
- 以人為本,景悅科技解讀智慧城市發(fā)展新理念
- 紐迪瑞科技/NDT賦能黑鯊4 Pro游戲手機(jī)打造全新一代屏幕壓感
- 清潔家電新老玩家市場(chǎng)定位清晰,攜手共進(jìn),核心技術(shù)決定未來
- 新思科技與芯耀輝在IP產(chǎn)品領(lǐng)域達(dá)成戰(zhàn)略合作伙伴關(guān)系
- 芯耀輝加速全球化部署,任命原Intel高管出任全球總裁
免責(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)鏈接。