如何進行kubernetes scheduler backend調度的實現

本篇文章為大家展示了如何進行kubernetes scheduler backend調度的實現，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

背景

  隨著k8s快來越火熱，以及自動部署，自動伸縮等優點，我們今天來探討一下，基于k8s的backend的調度怎么來實現

組件圖

組件說明

整個數據流就是消費者-生產者模型

• 特別說明
  對于podsWatchSnapshotSource的實現，我們是基于k8s watch機制實現的，但是存在一個問題:
  假如某一時刻，podsWatchSnapshotSource發生了故障導致了該組件發生了重啟，那么問題來了，重啟這段時間就會丟失event，
  這里我們采用k8s的resourceVersion機制，如果我們定時存儲resourceVersion，且在重啟的時候讀取，就能做到斷點續傳的作用
  注意一點的是：該resourceVersion在 Kubernetes 服務器的保留是有限制的。使用etcd2的舊集群最多可保留1000次更改。
  默認情況下，使用etcd3的較新集群會在最近5分鐘內保留更改，如果超過了該resourceVersion超過了服務器的resourceVersion的值
  則會報錯

數據流程圖

流程說明

• backend通過被調用reviveOffer獲取能獲取到的backend資源.

• 獲取到資源后，通過kubernetesClient向k8s提交任務

• 減少對應向k8s 提交任務的資源量

• 更新backend內部的對應job狀態為Running狀態，如果該存在job狀態為Runnnig狀態，則更新對應的job狀態為updated狀態

• podsWatchSnapshotSource 監控剛才提交的任務，獲取任務更新的狀態，存儲到podSnapshotStore中，以便后續任務的處理

• podsPollingSnapshotSource 定時拉取應用提交的所有任務，存儲到podSnapshotStore中，以便進行final任務的清理

• podSnapshotStore 對任務狀態更新為內部狀態，并對訂閱此podSnapshotStore的snapshot進行函數回調

• taskPodsLifecycleManager 訂閱了上述的snapshot，對該snapshot進行處理：
  1.如果任務狀態為podFailed或者PodSucceeded時，更新backend job的內豬狀態,如果存在對應的Running的job，調用k8s api刪除該pod，以及刪除該pod所占用的資源（cpus，mem等），如果存在對應updated的job狀態，則把updated的狀態更新為Running狀態，防止外界任務的更新，導致任務的資源量更新不一致
2.調用kubernetesTaskSchedulerBackend的statusUpdate方法進行任務的更新進行處理

UML類繼承圖

和spark on k8s的區別

因為公司有自己的調度平臺，所以主要從調度的粒度來進行對比：
spark on k8s調度的是executor級別的，是粗粒度調度
k8s backend 調度的是job級別，每個job一個pod container,屬于細粒度的精準調度

上述內容就是如何進行kubernetes scheduler backend調度的實現，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。