最近在上海蔘加 Kubecon，通過交流和 session 使我對資源共享和混部有了些新的想法。先零散的記錄下來，後續再整理成可行的方案和方法論。

現狀

目前我們大資料平臺的資源管理和排程都是基於 Kubernetes 的。我們將大資料任務分為 Routine Job 和 Batch Job 兩種型別（而實際上我們的混部方案要比這複雜，還包括 HDFS 和線上業務，在此先不表）。Routine Job 執行在獨佔資源池上，通過 namespace 劃分，維度可能是小組、部門或專案。我們需要優先保證此類 Job 的可用資源，它需要較高的 SLA 和 較小的 RT。一般來說，我們會根據實際物理資源去劃分獨佔資源池。這類 Job 對資源的消耗比較固定。第二種任務是 Batch Job，它具有較低的 Priority，可以容忍較低的 SLA 和 較高的 RT。Batch Job 對資源的需求是動態和較難估計的。

由於我們自己 IDC 的資源有限，我們希望可以用更少的機器執行更多的 Job（從某個角度上來說，也是為了提升 machine utilization），resource sharing 是一個好的選擇。當然還有另一種選擇是將動態資源池 offload 到雲上，這樣可以用最簡單的方案實現資源的即拿即用。但由於國內網路環境和資料安全的考慮，該方案只被用於沙箱環境。

關鍵技術

若想實現 resource sharing，我們至少需考慮兩個問題（實際遠不止這麼多）：

• 獨佔資源如何回收再分配
• 獨佔資源如何保障可用性

資源回收和再分配

針對第一個問題，我的想法是實現一種資源回收機制（當然借鑑了其它成熟的排程系統），它可以定期根據 Job 的實際資源使用率估算出資源消耗，回收這部分 gap 的資源分配給 Batch Job 使用。我們姑且將此過程稱之為 Resource Reclamation，估算資源消耗的過程稱為 Resource Consumption Prediction。計算資源消耗的演算法最簡單的方法是以現有資源消耗加一個 margin。

Exclusive Resource + Resource Reservation = Physical Machine Resource。在 Kubernetes 中，我們可以通過 Namespace Quota 定義總的 Exclusive Resource Pool，併為 Kubelet 設定 System Reservation。至於 Resource Consumption Prediction 可以通過諸如 cadvisor 或其他外部 Monitor 等手段採集計算。我們可以使用諸如 Kubernetes Operator 或者 client-go Informer 實現一個 Kubernetes Resource Reclamation Controller 定期執行以上過程。資源回收還有一個難點是回收的資源如何再分配給 Batch Job 使用。我目前估計只能修改 Kubernetes apiserver 和 scheduler，定期更新 NodeInfo 的 allocatableResource（具體實現方式還需我深入閱讀相關原始碼後再做定奪）。

資源搶佔

在多數時間段裡，獨佔資源的實際使用是低於分配的，所以混部是提高資源使用率的有效手段。但是一旦遇到 workload spike 就需要將 Batch Job 佔有的 overcommitting resource 還回去。這時可以利用諸如 Kubernetes Eviction & Preemption 等手段將 Batch Job Task 殺掉。因為一般在生產中，Routine Job 的 resource request 是等於 limit 的，這就意味著它具有最高級別的 Guaranteed QoS。而 Batch Job 我們只會設定它的一個 limit 上限，也就是 Burstable QoS。在資源緊張時，Kubernetes 會優先殺掉 Burstable Pod，將之還回 scheduler queue，以待重新排程。實際也只有諸如 exceeded memory 這種情況出現時，會驅逐 Burstable Pod。cpu 的話一般會 throttle 一下，這並不會對相應的 Job 造成很大幹擾。

暫時的最後

實際上混部是一個比較複雜的、一整套的解決方案，它可能包括：評估模型（Evaluation methodology）、資源回收、資源監控、資源預估、資源再分配、資源排程、資源隔離和資源驅逐搶佔等技術。而且中間摻雜著大量經驗資料，這些均需通過以往叢集的 utilization 和 workload 資料，結合實際業務需求進行分析 -》 制定解決方案 -》實施 -》再分析，這個迴圈。

由於時間緊張，以上只是我倉促間形成的一些小的想法，完全不保證可行性和正確性。過幾天，我會再從理論層面整理和驗證下。如果通過，我會實現一個 demo，供檢驗。

《未完待續》

作者：徐蓓 原文：https://xiaoxubeii.github.io/articles/approach-to-resource-sharing/?from=timeline