本篇文章為大家展示了如何進行kubernetes scheduler backend調(diào)度的實現(xiàn),內(nèi)容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
北林ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景,ssl證書未來市場廣闊!成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道,可以享受市場價格4-6折優(yōu)惠!如果有意向歡迎電話聯(lián)系或者加微信:18982081108(備注:SSL證書合作)期待與您的合作!
隨著k8s快來越火熱,以及自動部署,自動伸縮等優(yōu)點,我們今天來探討一下,基于k8s的backend的調(diào)度怎么來實現(xiàn)
整個數(shù)據(jù)流就是消費者-生產(chǎn)者模型
組件 | 解釋 |
---|---|
kubernetesClient | 跟k8s進行交互,如:任務(wù)的提交,殺任務(wù) |
podsPollingSnapshotSource | 從k8s中拉取pod的任務(wù)狀態(tài),存儲到podSnapshotStore |
podsWatchSnapshotSource | 監(jiān)控任務(wù)的watcher,以獲取任務(wù)狀態(tài),存儲到podSnapshotStore |
podSnapshotStore | pod狀態(tài)的存儲 |
podState | pod內(nèi)部狀態(tài)轉(zhuǎn)換 |
podsSnapshot | pod 的狀態(tài)鏡像 |
taskPodsLifecycleManager | 從podSnapshotStore消費pod的狀態(tài),以便根據(jù)任務(wù)的狀態(tài)進行后續(xù)操作 |
特別說明
對于podsWatchSnapshotSource的實現(xiàn),我們是基于k8s watch機制實現(xiàn)的,但是存在一個問題:
假如某一時刻,podsWatchSnapshotSource發(fā)生了故障導致了該組件發(fā)生了重啟,那么問題來了,重啟這段時間就會丟失event,
這里我們采用k8s的resourceVersion機制,如果我們定時存儲resourceVersion,且在重啟的時候讀取,就能做到斷點續(xù)傳的作用
注意一點的是:該resourceVersion在 Kubernetes 服務(wù)器的保留是有限制的。使用etcd2的舊集群最多可保留1000次更改。
默認情況下,使用etcd3的較新集群會在最近5分鐘內(nèi)保留更改,如果超過了該resourceVersion超過了服務(wù)器的resourceVersion的值
則會報錯
backend通過被調(diào)用reviveOffer獲取能獲取到的backend資源.
獲取到資源后,通過kubernetesClient向k8s提交任務(wù)
減少對應(yīng)向k8s 提交任務(wù)的資源量
更新backend內(nèi)部的對應(yīng)job狀態(tài)為Running狀態(tài),如果該存在job狀態(tài)為Runnnig狀態(tài),則更新對應(yīng)的job狀態(tài)為updated狀態(tài)
podsWatchSnapshotSource 監(jiān)控剛才提交的任務(wù),獲取任務(wù)更新的狀態(tài),存儲到podSnapshotStore中,以便后續(xù)任務(wù)的處理
podsPollingSnapshotSource 定時拉取應(yīng)用提交的所有任務(wù),存儲到podSnapshotStore中,以便進行final任務(wù)的清理
podSnapshotStore 對任務(wù)狀態(tài)更新為內(nèi)部狀態(tài),并對訂閱此podSnapshotStore的snapshot進行函數(shù)回調(diào)
taskPodsLifecycleManager 訂閱了上述的snapshot,對該snapshot進行處理:1.如果任務(wù)狀態(tài)為podFailed或者PodSucceeded時,更新backend job的內(nèi)豬狀態(tài),如果存在對應(yīng)的Running的job,調(diào)用k8s api刪除該pod,以及刪除該pod所占用的資源(cpus,mem等),如果存在對應(yīng)updated的job狀態(tài),則把updated的狀態(tài)更新為Running狀態(tài),防止外界任務(wù)的更新,導致任務(wù)的資源量更新不一致
2.調(diào)用kubernetesTaskSchedulerBackend的statusUpdate方法進行任務(wù)的更新進行處理
因為公司有自己的調(diào)度平臺,所以主要從調(diào)度的粒度來進行對比:
spark on k8s調(diào)度的是executor級別的,是粗粒度調(diào)度
k8s backend 調(diào)度的是job級別,每個job一個pod container,屬于細粒度的精準調(diào)度
上述內(nèi)容就是如何進行kubernetes scheduler backend調(diào)度的實現(xiàn),你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。