K8S Scheduler與機器學習的相關性

Published in

Gemini Open Cloud 雙子星雲端

9 min readJun 9, 2021

目前機器學習最主流的運行環境大都是在雲原生（Cloud Native）上，而Kubernetes 是雲原生叢集管理的主流，所以 Kubernetes Scheduler 如何派送附帶GPU的機器學習容器對機器學習效率就會有一定程度的影響。本週我們先來看一下K8S Scheduler 的設計原理，它在GPU場景下的侷限，而我們可以用什麼方法去客製化K8S Scheduler 的行為。未來我們將會介紹如何利用K8S Scheduler 去優化機器學習的流程。

K8S 叢集管理架構

圖一是一張經典的k8S叢集管理架構圖。K8S是一個分散式管理系統，K8S Master node是Kubernetes的指揮中心，負責管理所有 Worker Nodes。

Master Node

Master Node 最少有一個。若在高可用架構下，則有多台Master nodes。

Master Node上的主要元件包括：

controller-manager : 負責監控環境資源使用狀況，並經API server對Worker Node處理叢集資源，讓叢集保持最佳狀態。
scheduler : 負責將新建立的Pod分派到適合的Node中。派送是根據Worker Node的規則與硬體限制條件等資訊來進行。
etcd : 負責Kubernetes備份，在異常狀況時可快速還原至正常狀態。
API server : 負責與Worker Node溝通，並認證請求者的身分與授權。

Worker Node

Worker Node是使用者容器真正在運作的地方。使用者可透過kubectl指令，經由Master Node上的API server跟Worker Node溝通。所以，每個Worker Node上還是有以下三個控制元件：

kubelet : 負責管理所有Node中的Pod狀態，以及與API server溝通。
kube-proxy : 負責管理及更新Kubernetes網路路由。Kube-proxy也提供目前該Node上所有Pod的最新狀態給其他Worker Node。
Container Runtime Library : 負責容器運行的程式。

請注意，Master Node上的管理元件通常都不是直接呼叫Worker Node，而是經由API server去呼叫Worker Node上的kubelet元件，來建立POD並且把容器部署起來。換言之，API server是管理控制層（control plane）所有Master Node與Worker Node溝通的元件。

K8S scheduler 在 K8S 叢集管理的角色

接下來，讓我們再來聚焦在K8S scheduler。

如上所述，K8S scheduler 是負責將使用者指派的工作派送到 worker nodes 上。在這過程中，K8S scheduler 會監控所有被這個叢集Master node 管控的worker nodes，然後根據使用者訂立的規則（policy）去選擇最理想的worker node。然後再經由API server通知Worker Node上的kubelet再把POD跟 docker 部署起來。如圖二：

Kube scheduler 根據兩大政策去選擇一個最適合容器工作的worker node。這兩大政策分別為過濾（Filtering）跟評分（ Scoring）。簡單介紹如下：

過濾 Filtering

Filtering 是利用使用者定義的predicates去把不合適的worker node 過濾掉。通常有五種predicates：

通用性的（如PodFitsResources，PodFitsNodeSelector 等）
磁盤捲相關的 (如 NoDiskConflict，MaxCSIVolumeCount 等）
跟 Compute node 主機相關的（PodToleratesNodeTaint)
跟 Pod 相關的（MatchInterNodeAffinity）
跟 Host 目前運行狀況相關的（CheckNodeCondition，CheckNodeMemoryPressure 等）

評分 Scoring

若K8S scheduler經過Filtering之後，仍有多個worker node候選人（candidates）的時候，就會根據使用者定義的priority來算這些candidates的分數，派送到得分最高的worker node上。
Priorities 有包括 SelectorSpreadPriority, InterPodAffinityPriority, LeastRequestedPriority, NodeAffinityPriority, BalancedResourceAllocate 等。
每個合格的worker node在每個Scoring Priority可得1到10分。這個評分再乘上一個權重（weight），然後把所有priority 的得分加起來，就是這個worker node 的分數。

關於Filtering和Scoring的詳情，可參閱 Reference #1～#3。

這裡要和大家分享的一個觀察點，就是我們可以看到：

目前Kubernetes scheduler 預設的派送規則，主要就是跟worker node 的主機、記憶體、磁碟、網路、與目前被使用的狀況來決定。針對機器學習大量使用的 GPU 加速器，並沒有太大的比重或關係，這點將會是未來可改善的空間。

K8S客製化物件資源定義 (Custom Resource Definition)

從上面Kubernetes叢集管理的描述，大家可以看到Kubernetes 的系統架構是非常模組化的。在控制層（Control Plane）上，有預設的 controller-manager, kube-scheduler, etcd, API Server元件，各司其職。但是隨著我們對Kubernetes的研究愈來愈深，以及在特別的使用情境（例如需要用到GPU的容器），就會覺得有需要去客製化這些control plane上的元件。

如果使用者想要客製化K8S control plane的行為，也有一個很模組化的做法，就是客製化物件資源定義（Custom Resource Definition, CRD）。

顧名思義，CRD就是在K8S定義一組新的物件（object）資源的類型（Custom Resource）。我說CRD很模組化的意思，是因為CRD也是利用K8S的API Server，去擴展Kubernetes API 的方法。

CRD 是 K8S 在 v1.7 版本新增的 API 資源。當使用者自定義且建立一個新的CRD資源時，Kubernetes 的API server 就會為你所指定的CRD版本生出一個 RESTful 的資源路徑。利用這些使用者客製化的API資源，Kubernetes API Server 就會幫你處理使用者自定義資源的 API 請求、生命週期，跟狀態儲存等。

CRD 的範疇（scope）可以定為 namespace 或整個集群，取決于 CRD specification 的 scope 設置。

CRD 有一項強大的功能，就是使用者可以定義一個客製化的 custom controller。Custom controller 的好處，就是它的API 定義，通常是聲明式的（Declarative API）。聲明式的API 就像一個 state machine，就是說使用者只需要定義對應資源生命週期中各種狀態的預期最終狀況，Controller 就會根據資源物件目前的狀態，去自動控制這些custom resource，大幅減低資源管理的複雜性。

但請您記得，CRD只是Kubernetes提供給我們去客製Kubernetes Scheduler行為的其中一個方法，但CRD它並不是唯一的方法。CRD的好處是它比較簡單且模組化，你可以用任何程式語言，去撰寫客製化的API，也不需要去修改Kubernetes本身的元件。

我們的觀點

Kubernetes 架構具有很強大的功能，它也是雲原生環境中進行機器學習最受歡迎的叢集管理工具之一。但隨著GPU加速器在機器學習領域的廣泛運用，我們已經看到，在 CPU 上運行的容器，並沒有充份利用到GPU的能量。然而 Kubernetes scheduler目前的設計就是根據伺服器本身的運行狀況，來派送機器學習容器去工作，而沒有考量到GPU加速器的使用狀況。因此，假若能夠客製化 Kubernetes scheduler ，把GPU的特性納入考量，您的機器學習效率將可大幅提升。

在下一篇文章，我將深入介紹這項為機器學習流程與GPU加速器而客製設計Kubernetes scheduler的技術。

如果你想深入了解 Kubernetes在特定情況的客製化，請聯絡我們！