Kubelet從入門到放棄：拓撲管理(上)

<Kubelet從入門到放棄>系列將對Kubelet組件由基礎知識到源碼進行深刻梳理。上一篇zouyee帶各位看了CPU 管理的相關內容，其中說起拓撲管理，本文將對此進行詳細剖析,拓撲管理在Kubernetes 1.18時提高爲Beta。 TopologyManager功能可實現CPU、內存和外圍設備（例如SR-IOV VF和GPU）的NUMA對齊，從而使集羣知足低延遲需求。node

1、背景介紹nginx

注：下文TopologyManager簡稱爲拓撲管理器git

1.1 需求說明github

隨着單服務器節點內的處理器數量、硬件加速器及其餘外圍設備日益增多，愈來愈多的系統利用 CPU 和硬件加速器的組合來支持對延遲要求較高的任務和高吞吐量的並行計算。 這類負載包括電信、科學計算、機器學習、金融服務和數據分析等。如何優化延遲敏感型的高性能並行計算應用的性能成了一個重大的挑戰。

在引入拓撲管理器以前，CPU、內存和設備管理器在資源分配決策上彼此獨立。 這可能致使在多處理系統上出現與指望不符的資源分配，因爲這些與指望不一致的分配，對性能或延遲敏感的應用將受到影響，例如， CPU 和設備是從不一樣的 NUMA 節點分配的，所以會致使額外的延遲。爲了得到最佳性能，須要進行與 CPU 隔離、內存和設備局部性等有關的優化。 

拓撲管理器是Kubelet中ContainerManager組件的一部分，充當存儲分配資源信息的角色，以便ContainerManager組件能夠作出與拓撲結構相適應的資源分配決策，以便在資源分配的時候實現拓撲結構上的對齊。注意拓撲管理不是單獨起做用的，它和CPU manager、memory manager、Device manager共同爲Pod分配資源，優化資源訪問。
複製代碼

1.2 NUMA算法

在CPU管理中，咱們已經介紹了NUMA技術（再回顧一遍）。服務器

NUMAmarkdown

NUMA，之內存訪問的不一致性爲代價，減輕對總線和memory的帶寬需求。這種結構對進程調度算法的要求較高，儘可能減小跨Node的內存訪問次數，以提高系統性能。Core之間會共享總線、內存等資源。若是Core的數量較少，則沒什麼問題，但隨着Core的增多，對總線以及內存帶寬的需求就會顯著增大，最終總線和內存會成爲系統性能的瓶頸。網絡

以下圖所示，一個NUMA Node包括一個或者多個Socket，以及與之相連的local memory。一個多核的Socket有多個Core。若是CPU支持HT，OS還會把這個Core當作 2個Logical Processor。機器學習

Socket是一個物理上的概念，指的是主板上的cpu插槽
Node是一個邏輯上的概念，上圖中沒有說起。因爲SMP體系中各個CPU訪問內存只能經過單一的通道，致使內存訪問成爲瓶頸，cpu再多也無用。後來引入了NUMA，經過劃分node，每一個node有本地RAM，這樣node內訪問RAM速度會很是快。但跨Node的RAM訪問代價會相對高一點,咱們用Node之間的距離（Distance，抽象的概念）來定義各個Node之間互訪資源的開銷。
Core就是一個物理cpu,一個獨立的硬件執行單元，好比寄存器，計算單元等
Thread就是超線程（HyperThreading）的概念，是一個邏輯cpu，共享core上的執行單元

2、功能介紹ide

2.1 相關配置

在Kubernetes 1.18版本以前若須要啓用拓撲管理器，須要在Kublet的特性門控處啓用該特性。從Kubernetes 1.18 版本開始，這一特性默認啓動。--feature-gates="...,TopologyManager=<true|false>"

爲了知足定製對齊方式需求，拓撲管理器提供了兩種不一樣的方式：scope 和 policy。

scope 定義了資源對齊的粒度（當前提供pod與 container 兩種級別）。
policy 定義了對齊時實際使用的策略（當前提供best-effort、none、restricted、single-numa-node 等）。

注意：爲了將 Pod 中的 CPU 與其餘請求資源對齊，須要啓用CPU 管理而且配置適當的 CPU 管理策略。

a. 做用域

正如上文所述，拓撲管理器提供如下兩種不一樣的資源對齊粒度：

container （默認）
pod

在 kubelet 啓動時，可使用 --topology-manager-scope 標誌來配置其中任一粒度。

1）容器做用域

默認使用的是 container 做用域，拓撲管理依次進行一系列的資源對齊，即對每個容器（包含在一個 Pod 裏）單獨計算對齊。拓撲管理會把單個容器任意地對齊到 NUMA 節點上。

2）Pod做用域

在啓動 kubelet時，配置 --topology-manager-scope=pod ，便可對齊粒度爲 pod 。

該做用域容許把一個 Pod 裏的全部容器做爲一個分組，分配到一個共同的 NUMA 節點，即拓撲管理會把一個 Pod 當成一個總體，而且試圖把整個 Pod（全部容器）分配到一個單個的 NUMA 節點或者一個共同的 NUMA 節點集。下例說明了拓撲管理器在不一樣的場景下使用的對齊方式：

全部容器能夠被分配到一個單一的 NUMA 節點；
全部容器能夠被分配到一個共享的 NUMA 節點集合。整個 Pod 請求的某種資源總量經過 request/limit公式計算，所以，對某一種資源而言，該總量等於如下數值中的最大值：
全部應用容器請求之和
Init容器請求的最大值對於延遲敏感或者 IPC 高吞吐量工做負載，在配置Pod 做用域及 single-numa-node 拓撲管理策略時，能夠把一個 Pod 裏的全部容器都放到單一 NUMA 節點，使得該 Pod 消除了 NUMA 之間的通訊開銷。在 single-numa-node 策略下，只有當可能的分配方案中存在合適的 NUMA 節點集時，Kubelet纔會准入該Pod。以下述的示例：
節點集只包含單個 NUMA 節點時，Pod 就會被准入
節點集包含多個 NUMA 節點時，Pod 會被拒絕簡而言之，拓撲管理器首先計算出 NUMA 節點集，而後使用拓撲管理策略來測試該集合，從而決定拒絕或者接受 Pod。

b. 策略

拓撲管理支持四種分配策略，在 Kubelet 啓動時，能夠經過 Kubelet命令行 --topology-manager-policy 設置。當前支持的策略有四種：

none (默認)
best-effort
restricted
single-numa-node

1）none

這是默認策略，不執行任何拓撲對齊。

2）best-effort

對於 Guaranteed 類Pod 中的每一個容器，配置 best-effort 拓撲管理策略的 kubelet 將調用每一個Hint Provider以肯定資源可用性。使用此信息，拓撲管理器存儲該容器的首選親和性NUMA 節點。若是親和性不是首選，則拓撲管理器將存儲該親和性，而且不管如何都將 Pod 接納到該節點。

以後Hint Provider在進行資源分配決策時使用該信息。

3）restricted 策略

對於 Guaranteed 類 Pod 中的每一個容器，配置了 restricted 拓撲管理策略的 Kubelet 調用每一個Hint Provider以肯定其資源可用性。使用此信息，拓撲管理器存儲該容器的首選親和性 NUMA 節點。若是親和性不是首選，則拓撲管理器將從節點中拒絕此 Pod 。這將致使 Pod 處於 Terminated 狀態。Pod調度失敗，Kubernetes 調度器不會嘗試從新調度該 Pod，建議使用 ReplicaSet 或者 Deployment部署 Pod。

若是 Pod 被容許運行在某節點，則 Hint Provider 能夠在作出資源分配決策時使用此信息。

4）single-numa-node 策略

對於 Guaranteed 類 Pod 中的每一個容器，配置了 single-numa-nodde 拓撲管理策略的 Kubelet 調用每一個Hint Provider以肯定其資源可用性。使用此信息，拓撲管理器肯定單一 NUMA 節點親和性是否可能。若是是這樣，則拓撲管理器將存儲此信息，而後Hint Provider能夠在作出資源分配決定時使用此信息。若是不知足，則拓撲管理器將拒絕該Pod ，這將致使 Pod 處於 Terminated 狀態。

一旦 Pod 處於 Terminated 狀態，Kubernetes 調度器將不會嘗試從新調度該 Pod。建議使用 ReplicaSet 或者 Deployment 來從新部署 Pod。

2.2 Pod配置

注意：關於Pod三種QoS介紹，後續會詳細說明。

由於沒有指定資源 requests 或 limits，該 Pod 以 BestEffort QoS 運行。

spec:
  containers:
  - name: nginx
    image: nginx
複製代碼

由於 requests少於 limits，該 Pod 以 Burstable QoS 運行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
複製代碼

針對上述 Pod，若是選擇的策略是 none 之外的任何其餘策略，拓撲管理器都會評估這些 Pod 的資源使用。拓撲管理器會調用Hint Provider，得到拓撲結果。若策略爲 static，則 CPU 管理器策略返回默認的拓撲結果，由於這些 Pod 並無顯式地請求 CPU 資源。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
複製代碼

上述 Pod由於其 requests 值等於 limits 值，所以以 Guaranteed QoS 運行。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        example.com/deviceA: "1"
        example.com/deviceB: "1"
      requests:
        example.com/deviceA: "1"
        example.com/deviceB: "1"
複製代碼

上述Pod由於未指定 CPU 和內存請求，因此 Pod 以 BestEffort QoS 類運行。

總結以下：

對於 Guaranteed 類的Pod, 若是CPU 請求數爲整數，CPU 管理器策略爲static 時，將返回與 CPU 請求有關的hint，而設備管理器將返回有關所請求設備的hint。對於 Guaranteed 類的 CPU 請求可共享的 Pod（非整數CPU），CPU 管理器策略爲static 時，將返回默認的拓撲hint，由於沒有排他性的 CPU 請求，而設備管理器則針對所請求的設備返回有關hint。在上述兩種 Guaranteed Pod 的狀況中，CPU 管理器策略爲none時，返回默認的拓撲hint。
對於 BestEffort Pod，因爲沒有 CPU 請求，CPU 管理器策略爲static時，將發送默認hint，而設備管理器將爲每一個請求的設備發送hint。

基於此信息，拓撲管理器將爲 Pod 計算最佳hint並存儲該信息，爲 Hint Provider在進行資源分配時使用。

2.3 示範說明

例如，在圖1中，包含2個NUMA節點，2個Socket（每一個Socket具備4個CPU，2個GPU和2個NIC），CPU 0-三、GPU 0和NIC 0在Socket 0中，其屬於NUMA 0節點，CPU 4-七、GPU 1和NIC 1在Socket 1中，其屬於NUMA 1節點。

只有相應外設實現Device Plugin接口，且Kubelet啓用Device Manager時，Pod纔可以從設備插件提供的可用資源中請求設備資源（例如intel.com/sriov、nvidia.com/gpu等）。例如已經完成Device Plugin接口的Nvidia GPU設備插件和Intel SRIOV網絡設備插件。

假設Kubelet對於CPUManager啓用了static策略，而且gpu-vendor.com和nic-vendor.com的設備插件已實現Device Plugin接口，則下面的Pod配置可使用拓撲管理器以運行其選定的策略：

spec:
   containers:
   - name: numa-aligned-container
     image: alpine
     resources:
         limits:
             cpu: 2
             memory: 200Mi
             gpu-vendor.com/gpu: 1
             nic-vendor.com/nic: 1
複製代碼

按照圖1資源狀況，資源對齊結果以下所示：

{cpu: {0, 1}, gpu: 0, nic: 0}
{cpu: {0, 2}, gpu: 0, nic: 0}
{cpu: {0, 3}, gpu: 0, nic: 0}
{cpu: {1, 2}, gpu: 0, nic: 0}
{cpu: {1, 3}, gpu: 0, nic: 0}
{cpu: {2, 3}, gpu: 0, nic: 0}

{cpu: {4, 5}, gpu: 1, nic: 1}
{cpu: {4, 6}, gpu: 1, nic: 1}
{cpu: {4, 7}, gpu: 1, nic: 1}
{cpu: {5, 6}, gpu: 1, nic: 1}
{cpu: {5, 7}, gpu: 1, nic: 1}
{cpu: {6, 7}, gpu: 1, nic: 1}
複製代碼

注意：（再次申明）若是某個Pod被拓撲管理器拒絕，它的狀態將爲Terminated，並帶有一個Pod准入錯誤和「TopologyAffinityError的緣由說明。一旦Pod處於該狀態，Kubernetes調度程序將不會嘗試從新調度。

mp.weixin.qq.com/s/L02BjTt4Z…

後續相關內容，請查看公衆號：DCOS

1.kubernetes.io/blog/2020/0…
2.kubernetes.io/docs/tasks/…
3.kubernetes.io/docs/tasks/…
4.github.com/kubernetes/…