作者 | 騰訊星辰算力團隊

1.背景

1.1 問題源起

近年來，隨著騰訊內(nèi)部自研上云項目的不斷發(fā)展，越來越多的業(yè)務(wù)開始使用云原生方式托管自己的工作負載，容器平臺的規(guī)模因此不斷增大。以 Kubernetes 為底座的云原生技術(shù)極大推動了云原生領(lǐng)域的發(fā)展，已然成為各大容器平臺事實上的技術(shù)標準。在云原生場景下，為了最大化實現(xiàn)資源共享，單臺宿主機往往會運行多個不同用戶的計算任務(wù)。如果在宿主機內(nèi)沒有進行精細化的資源隔離，在業(yè)務(wù)負載高峰時間段，多個容器往往會對資源產(chǎn)生激烈的競爭，可能導(dǎo)致程序性能的急劇下降，主要體現(xiàn)為：

• 資源調(diào)度時頻繁的上下文切換時間
• 頻繁的進程切換導(dǎo)致的 CPU 高速緩存失效

因此，在云原生場景下需要針對容器資源分配加以精細化的限制，確保在 CPU 利用率較高時，各容器之間不會產(chǎn)生激烈競爭從而引起性能下降。

1.2 調(diào)度場景

騰訊星辰算力平臺承載了全公司的 CPU 和 GPU 算力服務(wù)，擁有著海量多類型的計算資源。當前，平臺承載的多數(shù)重點服務(wù)偏離線場景，在業(yè)務(wù)日益增長的算力需求下，提供源源不斷的低成本資源，持續(xù)提升可用性、服務(wù)質(zhì)量、調(diào)度能力，覆蓋更多的業(yè)務(wù)場景。然而，Kubernetes 原生的調(diào)度與資源綁定功能已經(jīng)無法滿足復(fù)雜的算力場景，亟需對資源進行更加精細化的調(diào)度，主要體現(xiàn)為：

(1)Kubernetes 原生調(diào)度器無法感知節(jié)點資源拓撲信息導(dǎo)致 Pod 生產(chǎn)失敗

kube-scheduler 在調(diào)度過程中并不感知節(jié)點的資源拓撲，當 kube-scheduler 將 Pod 調(diào)度到某個節(jié)點后，kubelet 如果發(fā)現(xiàn)節(jié)點的資源拓撲親和性要求無法滿足時，會拒絕生產(chǎn)該 Pod，當通過外部控制環(huán)(如 deployment)來部署 Pod 時，則會導(dǎo)致 Pod 被反復(fù)創(chuàng)建-->調(diào)度-->生產(chǎn)失敗的死循環(huán)。

(2)基于離線虛擬機的混部方案導(dǎo)致的節(jié)點實際可用 CPU 核心數(shù)變化

面對運行在線業(yè)務(wù)的云主機平均利用率較低的現(xiàn)實，為充分利用空閑資源，可將離線虛擬機和在線虛擬機混合部署，解決公司離線計算需求，提升自研上云資源平均利用率。在保證離線不干擾在線業(yè)務(wù)的情況下，騰訊星辰算力基于自研內(nèi)核調(diào)度器 VMF 的支持，可以將一臺機器上的閑時資源充分利用起來，生產(chǎn)低優(yōu)先級的離線虛擬機。由于 VMF 的不公平調(diào)度策略，離線虛擬機的實際可用核心數(shù)受到在線虛擬機的影響，隨著在線業(yè)務(wù)的繁忙程度不斷變化。因此，kubelet 通過 cadvisor 在離線宿主機內(nèi)部采集到的 CPU 核心數(shù)并不準確，導(dǎo)致了調(diào)度信息出現(xiàn)偏差。

cvm-architecture

(3)資源的高效利用需要更加精細化的調(diào)度粒度

kube-scheduler 的職責是為 Pod 選擇一個合適的 Node 完成一次調(diào)度。然而，想對資源進行更高效的利用，原生調(diào)度器的功能還遠遠不夠。在調(diào)度時，我們希望調(diào)度器能夠進行更細粒度的調(diào)度，比如能夠感知到 CPU 核心、GPU 拓撲、網(wǎng)絡(luò)拓撲等等，使得資源利用方式更加合理。

2.預(yù)備知識

2.1 cgroups 之 cpuset 子系統(tǒng)

cgroups 是 Linux 內(nèi)核提供的一種可以限制單個進程或者多個進程所使用資源的機制，可以對 CPU、內(nèi)存等資源實現(xiàn)精細化的控制。Linux 下的容器技術(shù)主要通過 cgroups 來實現(xiàn)資源控制。

在 cgroups 中，cpuset 子系統(tǒng)可以為 cgroups 中的進程分配獨立的 CPU 和內(nèi)存節(jié)點。通過將 CPU 核心編號寫入 cpuset 子系統(tǒng)中的 cpuset.cpus文件中或?qū)?nèi)存 NUMA 編號寫入 cpuset.mems文件中，可以限制一個或一組進程只使用特定的 CPU 或者內(nèi)存。

幸運的是，在容器的資源限制中，我們不需要手動操作 cpuset 子系統(tǒng)。通過連接容器運行時(CRI)提供的接口，可以直接更新容器的資源限制。

// ContainerManager contains methods to manipulate containers managed by a
// container runtime. The methods are thread-safe.
type ContainerManager interface {
    // ......
    // UpdateContainerResources updates the cgroup resources for the container.
 UpdateContainerResources(containerID string, resources *runtimeapi.LinuxContainerResources) error
    // ......
}

2.2 NUMA 架構(gòu)

非統(tǒng)一內(nèi)存訪問架構(gòu)(英語：Non-uniform memory access，簡稱 NUMA)是一種為多處理器的電腦設(shè)計的內(nèi)存架構(gòu)，內(nèi)存訪問時間取決于內(nèi)存相對于處理器的位置。在 NUMA 下，處理器訪問它自己的本地內(nèi)存的速度比非本地內(nèi)存(內(nèi)存位于另一個處理器，或者是處理器之間共享的內(nèi)存)快一些。現(xiàn)代多核服務(wù)器大多采用 NUMA 架構(gòu)來提高硬件的可伸縮性。

numa-architecture

從圖中可以看出，每個 NUMA Node 有獨立的 CPU 核心、L3 cache 和內(nèi)存，NUMA Node 之間相互連接。相同 NUMA Node 上的 CPU 可以共享 L3 cache，同時訪問本 NUMA Node 上的內(nèi)存速度更快，跨 NUMA Node 訪問內(nèi)存會更慢。因此，我們應(yīng)當為 CPU 密集型應(yīng)用分配同一個 NUMA Node 的 CPU 核心，確保程序的局部性能得到充分滿足。

2.3 Kubernetes 調(diào)度框架

Kubernetes 自 v1.19 開始正式穩(wěn)定支持調(diào)度框架，調(diào)度框架是面向 Kubernetes 調(diào)度器的一種插件架構(gòu)，它為現(xiàn)有的調(diào)度器添加了一組新的“插件”API，插件會被編譯到調(diào)度器之中。這為我們自定義調(diào)度器帶來了福音。我們可以無需修改 kube-scheduler 的源代碼，通過實現(xiàn)不同的調(diào)度插件，將插件代碼與 kube-scheduler 編譯為同一個可執(zhí)行文件中，從而開發(fā)出自定義的擴展調(diào)度器。這樣的靈活性擴展方便我們開發(fā)與配置各類調(diào)度器插件，同時無需修改 kube-scheduler 的源代碼的方式使得擴展調(diào)度器可以快速更改依賴，更新到最新的社區(qū)版本。

scheduling-framework-extensions

調(diào)度器的主要擴展點如上圖所示。我們擴展的調(diào)度器主要關(guān)心以下幾個步驟：

(1)PreFilter 和 Filter

這兩個插件用于過濾出不能運行該 Pod 的節(jié)點，如果任何 Filter 插件將節(jié)點標記為不可行，該節(jié)點都不會進入候選集合，繼續(xù)后面的調(diào)度流程。

(2)PreScore、Score 和 NormalizeScore

這三個插件用于對通過過濾階段的節(jié)點進行排序，調(diào)度器將為每個節(jié)點調(diào)用每個評分插件，最終評分最高的節(jié)點將會作為最終調(diào)度結(jié)果被選中。

(3)Reserve 和 Unreserve

這個插件用于在 Pod 真正被綁定到節(jié)點之前，對資源做一些預(yù)留工作，保證調(diào)度的一致性。如果綁定失敗則通過 Unreserve 來釋放預(yù)留的資源。

(4)Bind

這個插件用于將 Pod 綁定到節(jié)點上。默認的綁定插件只是為節(jié)點指定 spec.nodeName 來完成調(diào)度，如果我們需要擴展調(diào)度器，加上其他的調(diào)度結(jié)果信息，就需要禁用默認 Bind 插件，替換為自定義的 Bind 插件。

3.國內(nèi)外技術(shù)研究現(xiàn)狀

目前 Kubernetes 社區(qū)、Volcano 開源社區(qū)均有關(guān)于拓撲感知相關(guān)的解決方案，各方案有部分相同之處，但各自都有局限性，無法滿足星辰算力的復(fù)雜場景。

3.1 Kubernetes 社區(qū)

Kubernetes 社區(qū) scheduling 興趣小組針對拓撲感知調(diào)度也有過一套解決方案，這個方案主要是由 RedHat 來主導(dǎo)，通過scheduler-plugins和node-feature-discovery配合實現(xiàn)了考慮節(jié)點拓撲的調(diào)度方法。社區(qū)的方法僅僅考慮節(jié)點是否能夠在滿足 kubelet 配置要求的情況下，完成調(diào)度節(jié)點篩選和打分，并不會執(zhí)行綁核，綁核操作仍然交給 kubelet 來完成，相關(guān)提案在這里。具體實現(xiàn)方案如下：

• 節(jié)點上的 nfd-topology-updater 通過 gRPC 上報節(jié)點拓撲到 nfd-master 中(周期 60s)。
• nfd-master 更新節(jié)點拓撲與分配情況到 CR 中(NodeResourceTopology)。
• 擴展 kube-scheduler，進行調(diào)度時考慮 NodeTopology。
• 節(jié)點 kubelet 完成綁核工作。

該方案存在較多的問題，不能解決生產(chǎn)實踐中的需求：

• 具體核心分配依賴 kubelet 完成，因此調(diào)度器只會考慮資源拓撲信息，并不會選擇拓撲，調(diào)度器沒有資源預(yù)留。這導(dǎo)致了節(jié)點調(diào)度與拓撲調(diào)度不在同一個環(huán)節(jié)，會引起數(shù)據(jù)不一致問題。
• 由于具體核心分配依賴 kubelet 完成，所以已調(diào)度 Pod 的拓撲信息需要依靠 nfd-worker 每隔 60s 匯報一次，導(dǎo)致拓撲發(fā)現(xiàn)過慢因此使得數(shù)據(jù)不一致問題更加嚴重，參見這里。
• 沒有區(qū)分需要拓撲親和的 pod 和普通的 pod，容易造成開啟拓撲功能的節(jié)點高優(yōu)資源浪費。

3.2 Volcano 社區(qū)

Volcano 是在 Kubernetes 上運行高性能工作負載的容器批量計算引擎，隸屬于 CNCF 孵化項目。在 v1.4.0-Beta 版本中進行了增強，發(fā)布了有關(guān) NUMA 感知的特性。與 Kubernetes 社區(qū) scheduling 興趣小組的實現(xiàn)方式類似，真正的綁核并未單獨實現(xiàn)，直接采用的是 kubelet 自帶的功能。具體實現(xiàn)方案如下：

• resource-exporter 是部署在每個節(jié)點上的 DaemonSet，負責節(jié)點的拓撲信息采集，并將節(jié)點信息寫入 CR中(Numatopology)。
• Volcano 根據(jù)節(jié)點的 Numatopology，在調(diào)度 Pod 時進行 NUMA 調(diào)度感知。
• 節(jié)點 kubelet 完成綁核工作。

該方案存在的問題基本與 Kubernetes 社區(qū) scheduling 興趣小組的實現(xiàn)方式類似，具體核心分配依賴 kubelet

完成。雖然調(diào)度器盡力保持與 kubelet 一致，但因為無法做資源預(yù)留，仍然會出現(xiàn)不一致的問題，在高并發(fā)場景下尤其明顯。

3.3 小結(jié)

基于國內(nèi)外研究現(xiàn)狀的結(jié)果進行分析，開源社區(qū)在節(jié)點資源綁定方面還是希望交給 kubelet，調(diào)度器盡量保證與 kubelet 的一致，可以理解這比較符合社區(qū)的方向。因此，目前各個方案的典型實現(xiàn)都不完美，無法滿足騰訊星辰算力的要求，在復(fù)雜的生產(chǎn)環(huán)境中我們需要一套更加穩(wěn)健、擴展性更好的方案。因此，我們決定從各個方案的架構(gòu)優(yōu)點出發(fā)，探索出一套更加強大的、貼合騰訊星辰算力實際場景的資源精細化調(diào)度增強方案。

4.問題分析

4.1 離線虛擬機節(jié)點實際可用 CPU 核心數(shù)變化

從 1.2 節(jié)中我們可以知道，騰訊星辰算力使用了基于離線虛擬機的混部方案，節(jié)點實際的 CPU 可用核心數(shù)會收到在線業(yè)務(wù)的峰值影響從而變化。因此，kubelet 通過 cadvisor 在離線宿主機內(nèi)部采集到的 CPU 核心數(shù)并不準確，這個數(shù)值是一個固定值。因此，針對離線資源我們需要調(diào)度器通過其他的方式來獲取節(jié)點的實際算力。

cvm

目前調(diào)度和綁核都不能到離線虛擬機的實際算力，導(dǎo)致任務(wù)綁定到在線干擾比較嚴重的 NUMA node，資源競爭非常嚴重使得任務(wù)的性能下降。

cvm-2

幸運的是，我們在物理機上可以采集到離線虛擬機每個 NUMA node 上實際可用的 CPU 資源比例，通過折損公式計算出離線虛擬機的實際算力。接下來就只需要讓調(diào)度器在調(diào)度時能夠感知到 CPU 拓撲以及實際算力，從而進行分配。

4.2 精細化調(diào)度需要更強的靈活性

通過 kubelet 自帶的 cpumanager 進行綁核總是會對該節(jié)點上的所有 Pod 均生效。只要 Pod 滿足 Guaranteed 的 QoS 條件，且 CPU 請求值為整數(shù)，都會進行綁核。然而，有些 Pod 并不是高負載類型卻獨占 CPU，這種方式的方式很容易造成開啟拓撲功能的節(jié)點高優(yōu)資源浪費。

同時，對于不同資源類型的節(jié)點，其拓撲感知的要求也是不一樣的。例如，星辰算力的資源池中也含有較多碎片虛擬機，這部分節(jié)點不是混部方式生產(chǎn)出來的，相比而言資源穩(wěn)定，但是規(guī)格很小(如 8 核 CVM，每個 NUMA Node 有 4 核)。由于大多數(shù)任務(wù)規(guī)格都會超過 4 核，這類資源就在使用過程中就可以跨 NUMA Node 進行分配，否則很難匹配。

因此，拓撲感知調(diào)度需要更強的靈活性，適應(yīng)各種核心分配與拓撲感知場景。

4.3 調(diào)度方案需要更強的擴展性

調(diào)度器在抽象拓撲資源時，需要考慮擴展性。對于今后可能會需要調(diào)度的擴展資源，如各類異構(gòu)資源的調(diào)度，也能夠在這套方案中輕松使用，而不僅僅是 cgroups 子系統(tǒng)中含有的資源。

4.4 避免超線程帶來的 CPU 競爭問題

在 CPU 核心競爭較為激烈時，超線程可能會帶來更差的性能。更加理想的分配方式是將一個邏輯核分配給高負載應(yīng)用，另一個邏輯核分配給不繁忙的應(yīng)用，或者是將兩個峰谷時刻相反的應(yīng)用分配到同一個物理核心上。同時，我們避免將同一個應(yīng)用分配到同一個物理核心的兩個邏輯核心上，這樣很可能造成 CPU 競爭問題。

5.解決方案

為了充分解決上述問題，并考慮到未來的擴展性，我們設(shè)計了一套精細化調(diào)度的方案，命名為 cassini。整套解決方案包含三個組件和一個 CRD，共同配合完成資源精細化調(diào)度的工作。

注：cassini這個名稱來源于知名的土星探測器卡西尼-惠更斯號，對土星進行了精準無誤的探測，借此名來象征更加精準的拓撲發(fā)現(xiàn)與調(diào)度。

5.1 總體架構(gòu)

solution

各模塊職責如下：

• cassini-master：從外部系統(tǒng)負責收集節(jié)點特性(如節(jié)點的 offline_capacity，節(jié)點電力情況)，作為 controller 采用
  Deployment 方式運行。
• scheduler-plugins：新增調(diào)度插件的擴展調(diào)度器替換原生調(diào)度器，在節(jié)點綁定的同時還會分配拓撲調(diào)度結(jié)果，作為靜態(tài) Pod 在每個 master 節(jié)點上運行。

調(diào)度整體流程如下：

(1)cassini-worker啟動，收集節(jié)點上的拓撲資源信息。

(2)創(chuàng)建或更新 NodeResourceTopology(NRT)類型的 CR 資源，用于記錄節(jié)點拓撲信息。

(3)讀取 kubelet 的 cpu_manager_state 文件，將已有容器的 kubelet 綁核結(jié)果 patch 到 Pod annotations 中。

(4)cassini-master 根據(jù)外部系統(tǒng)獲取到的信息來更新對應(yīng)節(jié)點的 NRT 對象。

(5)擴展調(diào)度器 scheduler-plugins 執(zhí)行 Pod 調(diào)度，根據(jù) NRT 對象感知到節(jié)點的拓撲信息，調(diào)度 Pod 時將拓撲調(diào)度結(jié)構(gòu)寫到 Pod annotations 中。

(6)節(jié)點 kubelet 監(jiān)聽并準備啟動 Pod。

(7)節(jié)點 kubelet 調(diào)用容器運行時接口啟動容器。

(8)cassini-worker 周期性地訪問 kubelet 的 10250 端口來 List 節(jié)點上的 Pod 并從 Pod annotations 中獲取調(diào)度器的拓撲調(diào)度結(jié)果。

(9)cassini-worker 調(diào)用容器運行時接口來更改容器的綁核結(jié)果。

整體可以看出，cassini-worker 在節(jié)點上收集更詳細的資源拓撲信息，cassini-master 從外部系統(tǒng)集中獲取節(jié)點資源的附加信息。scheduler-plugins 擴展了原生調(diào)度器，以這些附加信息作為決策依據(jù)來進行更加精細化的調(diào)度，并將結(jié)果寫到 Pod annotations 中。最終，cassini-worker 又承擔了執(zhí)行者的職責，負責落實調(diào)度器的資源拓撲調(diào)度結(jié)果。

5.2 API 設(shè)計

NodeResourceTopology(NRT)是用于抽象化描述節(jié)點資源拓撲信息的 Kubernetes CRD，這里主要參考了 Kubernetes

社區(qū) scheduling 興趣小組的設(shè)計。每一個 Zone 用于描述一個抽象的拓撲區(qū)域，ZoneType 來描述其類型，ResourceInfo 來描述 Zone 內(nèi)的資源總量。

// Zone represents a resource topology zone, e.g. socket, node, die or core.
type Zone struct {
 // Name represents the zone name.
 // +required
 Name string `json:"name" protobuf:"bytes,1,opt,name=name"`

 // Type represents the zone type.
 // +kubebuilder:validation:Enum=Node;Socket;Core
 // +required
 Type ZoneType `json:"type" protobuf:"bytes,2,opt,name=type"`

 // Parent represents the name of parent zone.
 // +optional
 Parent string `json:"parent,omitempty" protobuf:"bytes,3,opt,name=parent"`

 // Costs represents the cost between different zones.
 // +optional
 Costs CostList `json:"costs,omitempty" protobuf:"bytes,4,rep,name=costs"`

 // Attributes represents zone attributes if any.
 // +optional
 Attributes map[string]string `json:"attributes,omitempty" protobuf:"bytes,5,rep,name=attributes"`

 // Resources represents the resource info of the zone.
 // +optional
 Resources *ResourceInfo `json:"resources,omitempty" protobuf:"bytes,6,rep,name=resources"`
}

注意到，為了更強的擴展性，每個 Zone 內(nèi)加上了一個 Attributes 來描述 Zone 上的自定義屬性。如 4.1 節(jié)中所示，我們將采集到的離線虛擬機實際算力寫入到 Attributes 字段中，來描述每個 NUMA Node 實際可用算力。

5.3 調(diào)度器設(shè)計

plugin擴展調(diào)度器在原生調(diào)度器基礎(chǔ)上擴展了新的插件，大體如下所示：

• Filter：讀取 NRT 資源，根據(jù)每個拓撲內(nèi)的實際可用算力以及 Pod 拓撲感知要求來篩選節(jié)點并選擇拓撲。
• Score：根據(jù) Zone 個數(shù)打分來打分，Zone 越多分越低(跨 Zone 會帶來性能損失)。
• Reserve：在真正綁定前做資源預(yù)留，避免數(shù)據(jù)不一致，kube-scheduler 的 cache 中也有類似的 assume 功能。
• Bind：禁用默認的 Bind 插件，在 Bind 時加入 Zone 的選擇結(jié)果，附加在 annotations 中。

通過 TopologyMatch 插件使得調(diào)度器在調(diào)度時能夠考慮節(jié)點拓撲信息并進行拓撲分配，并通過 Bind 插件將結(jié)果附加在 annotations 中。

值得一提的是，這里還額外實現(xiàn)了關(guān)于節(jié)點電力調(diào)度等更多維度調(diào)度的調(diào)度器插件，本篇中不作展開討論，感興趣的同學(xué)可以私戳我了解。

5.4 master 設(shè)計

cassini-master 是中控組件，從外部來采集一些節(jié)點上無法采集的資源信息。我們從物理上采集到離線虛擬機的實際可用算力，由 cassini-master 負責將這類結(jié)果附加到對應(yīng)節(jié)點的 NRT 資源中。該組件將統(tǒng)一資源收集的功能進行了剝離，方便更新與擴展。

5.5 worker 設(shè)計

cassini-worker 是一個較為復(fù)雜的組件，作為 DaemonSet 在每個節(jié)點上運行。它的職責分兩部分：

(1)采集節(jié)點上的拓撲資源。(2)執(zhí)行調(diào)度器的拓撲調(diào)度結(jié)果。

5.5.1 資源采集

資源拓撲采集主要是通過從 /sys/devices下采集系統(tǒng)相關(guān)的硬件信息，并創(chuàng)建或更新到 NRT 資源中。該組件會 watch 節(jié)點 kubelet 的配置信息并上報，讓調(diào)度器感知到節(jié)點的 kubelet 的綁核策略、預(yù)留資源等信息。

由于硬件信息幾乎不變化，默認會較長時間采集一次并更新。但 watch 配置的事件是實時的，一旦 kubelet 配置后會立刻感知到，方便調(diào)度器根據(jù)節(jié)點的配置進行不同的決策。

5.5.2 拓撲調(diào)度結(jié)果執(zhí)行

拓撲調(diào)度結(jié)果執(zhí)行是通過周期性地 reconcile 來完成制定容器的拓撲分配。

(1)獲取 Pod 信息

為了防止每個節(jié)點的 cassini-worker都 watch kube-apiserver 造成 kube-apiserver 的壓力，cassini-worker改用周期性訪問 kubelet 的 10250 端口的方式，來 List 節(jié)點上的 Pod 并從 Pod annotations 中獲取調(diào)度器的拓撲調(diào)度結(jié)果。同時，從 status 中還可以獲取到每個容器的 ID 與狀態(tài)，為拓撲資源的分配創(chuàng)建了條件。

(2)記錄 kubelet 的 CPU 綁定信息

在 kubelet 開啟 CPU 核心綁定時，擴展調(diào)度器將會跳過所有的 TopologyMatch插件。此時 Pod annotations 中不會包含拓撲調(diào)度結(jié)果。在 kubelet 為 Pod 完成 CPU 核心綁定后，會將結(jié)果記錄在 cpu_manager_state文件中，cassini-worker 讀取該文件，并將 kubelet 的綁定結(jié)果 patch 到 Pod annotations 中，供后續(xù)調(diào)度做判斷。

(3)記錄 CPU 綁定信息

根據(jù) cpu_manager_state文件，以及從 annotations 中獲取的 Pod 的拓撲調(diào)度結(jié)果，生成自己的 cassini_cpu_manager_state 文件，該文件記錄了節(jié)點上所有 Pod 的核心綁定結(jié)果。

(4)執(zhí)行拓撲分配

根據(jù) cassini_cpu_manager_state 文件，調(diào)用容器運行時接口，完成最終的容器核心綁定工作。

6.優(yōu)化結(jié)果

根據(jù)上述精細化調(diào)度方案，我們對一些線上的任務(wù)進行了測試。此前，用戶反饋任務(wù)調(diào)度到一些節(jié)點后計算性能較差，且由于 steal_time升高被頻繁驅(qū)逐。在替換為拓撲感知調(diào)度的解決方案后，由于拓撲感知調(diào)度可以細粒度地感知到每個 NUMA 節(jié)點的離線實際算力(offline_capacity)，任務(wù)會被調(diào)度到合適的 NUMA 節(jié)點上，測試任務(wù)的訓(xùn)練速度可提升至原來的 3 倍，與業(yè)務(wù)在高優(yōu) CVM 的耗時相當，且訓(xùn)練速度較為穩(wěn)定，資源得到更合理地利用。

同時，在使用原生調(diào)度器的情況下，調(diào)度器無法感知離線虛擬機的實際算力。當任務(wù)調(diào)度到某個節(jié)點上后，該節(jié)點

steal_time會因此升高，任務(wù)無法忍受這樣的繁忙節(jié)點就會由驅(qū)逐器發(fā)起 Pod 的驅(qū)逐。在此情況下，如果采用原生調(diào)度器，將會引起反復(fù)驅(qū)逐然后反復(fù)調(diào)度的情況，導(dǎo)致 SLA 收到較大影響。經(jīng)過本文所述的解決方案后，可將 CPU 搶占的驅(qū)逐率大大下降至物理機水平。

7.總結(jié)與展望

本文從實際業(yè)務(wù)痛點出發(fā)，首先簡單介紹了騰訊星辰算力的業(yè)務(wù)場景與精細化調(diào)度相關(guān)的各類背景知識，然后充分調(diào)研國內(nèi)外研究現(xiàn)狀，發(fā)現(xiàn)目前已有的各種解決方案都存在局限性。最后通過痛點問題分析后給出了相應(yīng)的解決方案。經(jīng)過優(yōu)化后，資源得到更合理地利用，原有測試任務(wù)的訓(xùn)練速度能提升至原來的 3 倍，CPU 搶占的驅(qū)逐率大大降低至物理機水平。

未來，精細化調(diào)度將會覆蓋更多的場景，包括在 GPU 虛擬化技術(shù)下對 GPU 整卡、碎卡的調(diào)度，支持高性能網(wǎng)絡(luò)架構(gòu)的調(diào)度，電力資源的調(diào)度，支持超售場景，配合內(nèi)核調(diào)度共同完成等等。