Kubernetes 資源拓撲感知調度優(yōu)化

作者：騰訊技術工程 2022-06-27 10:25:55

云計算

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

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：域名注冊、虛擬空間、營銷軟件、網站建設、吳忠網站維護、網站推廣。

作者 | 騰訊星辰算力團隊

1.背景

1.1 問題源起

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

• 資源調度時頻繁的上下文切換時間
• 頻繁的進程切換導致的 CPU 高速緩存失效

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

1.2 調度場景

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

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

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

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

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

cvm-architecture

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

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

2.預備知識

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

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

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

幸運的是，在容器的資源限制中，我們不需要手動操作 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 架構

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

numa-architecture

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

2.3 Kubernetes 調度框架

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

scheduling-framework-extensions

調度器的主要擴展點如上圖所示。我們擴展的調度器主要關心以下幾個步驟：

(1)PreFilter 和 Filter

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

(2)PreScore、Score 和 NormalizeScore

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

(3)Reserve 和 Unreserve

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

(4)Bind

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

3.國內外技術研究現狀

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

3.1 Kubernetes 社區(qū)

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

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

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

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

3.2 Volcano 社區(qū)

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

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

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

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

3.3 小結

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

4.問題分析

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

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

cvm

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

cvm-2

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

4.2 精細化調度需要更強的靈活性

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

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

因此，拓撲感知調度需要更強的靈活性，適應各種核心分配與拓撲感知場景。

4.3 調度方案需要更強的擴展性

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

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

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

5.解決方案

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

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

5.1 總體架構

solution

各模塊職責如下：

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

調度整體流程如下：

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

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

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

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

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

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

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

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

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

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

5.2 API 設計

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

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

// 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 內加上了一個 Attributes 來描述 Zone 上的自定義屬性。如 4.1 節(jié)中所示，我們將采集到的離線虛擬機實際算力寫入到 Attributes 字段中，來描述每個 NUMA Node 實際可用算力。

5.3 調度器設計

plugin擴展調度器在原生調度器基礎上擴展了新的插件，大體如下所示：

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

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

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

5.4 master 設計

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

5.5 worker 設計

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

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

5.5.1 資源采集

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

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

5.5.2 拓撲調度結果執(zhí)行

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

(1)獲取 Pod 信息

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

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

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

(3)記錄 CPU 綁定信息

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

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

根據 cassini_cpu_manager_state 文件，調用容器運行時接口，完成最終的容器核心綁定工作。

6.優(yōu)化結果

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

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

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

7.總結與展望

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

未來，精細化調度將會覆蓋更多的場景，包括在 GPU 虛擬化技術下對 GPU 整卡、碎卡的調度，支持高性能網絡架構的調度，電力資源的調度，支持超售場景，配合內核調度共同完成等等。

分享標題：Kubernetes資源拓撲感知調度優(yōu)化
文章地址：http://m.fisionsoft.com.cn/article/djpgsic.html