節點上的拓撲管理策略控制

越來越多的系統利用 CPU 和硬體加速器的組合來支援延遲關鍵型執行和高吞吐量平行計算。這些包括電信、科學計算、機器學習、金融服務和資料分析等領域的工作負載。此類混合系統包含高效能環境。

為了發揮最佳效能，需要與 CPU 隔離、記憶體和裝置區域性相關的最佳化。然而，在 Kubernetes 中，這些最佳化是由一組不相交的組件處理的。

拓撲管理器 是 kubelet 組件，旨在協調負責這些最佳化的一組組件。

開始之前

您需要有一個 Kubernetes 叢集，而且必須將 kubectl 命令列工具設定為與您的叢集通訊。建議在至少兩個非控制平面主機的節點叢集上執行本教學課程。如果您還沒有叢集，可以使用 minikube 建立一個，或者您可以使用以下 Kubernetes playground 之一

• Killercoda
• Play with Kubernetes

拓撲管理器如何運作

在引入拓撲管理器之前，Kubernetes 中的 CPU 和裝置管理器會彼此獨立地做出資源分配決策。這可能會導致多插槽系統上出現不理想的分配，並且效能/延遲敏感型應用程式將會因為這些不理想的分配而受到影響。在此案例中，不理想的意思例如是從不同的 NUMA 節點分配 CPU 和裝置，因此會產生額外的延遲。

拓撲管理器是一個 kubelet 組件，作為事實來源，以便其他 kubelet 組件可以做出拓撲對齊的資源分配選擇。

拓撲管理器為組件（稱為 Hint Providers）提供介面，以傳送和接收拓撲資訊。拓撲管理器有一組節點層級策略，如下所述。

拓撲管理器從 Hint Providers 接收拓撲資訊，作為表示可用 NUMA 節點的位元遮罩和偏好的分配指示。拓撲管理器策略對提供的提示執行一組操作，並收斂於策略決定的提示，以提供最佳結果。如果儲存了不理想的提示，則提示的偏好欄位將設定為 false。在目前的策略中，偏好是最窄的偏好遮罩。選取的提示會儲存為拓撲管理器的一部分。根據設定的策略，可以根據選取的提示從節點接受或拒絕 Pod。然後，提示會儲存在拓撲管理器中，供 Hint Providers 在做出資源分配決策時使用。

Windows 支援

可以使用 WindowsCPUAndMemoryAffinity 功能閘道在 Windows 上啟用拓撲管理器支援，並且需要容器執行期的支援。

拓撲管理器範圍與策略

拓撲管理器目前

• 對齊所有 QoS 類別的 Pod。
• 對齊 Hint Provider 提供拓撲提示的請求資源。

如果滿足這些條件，拓撲管理器將對齊請求的資源。

為了自訂如何執行此對齊，拓撲管理器提供兩個不同的選項：scope 和 policy。

scope 定義了您希望執行資源對齊的精細程度，例如在 pod 或 container 層級。而 policy 定義了用於執行對齊的實際策略，例如 best-effort、restricted 和 single-numa-node。下方提供了有關目前可用的各種 scopes 和 policies 的詳細資訊。

拓撲管理器範圍

拓撲管理器可以處理幾個不同範圍內的資源對齊

• container（預設）
• pod

可以在 kubelet 啟動時選擇任一選項，方法是在kubelet 設定檔中設定 topologyManagerScope。

container 範圍

預設使用 container 範圍。您也可以在 kubelet 設定檔中明確地將 topologyManagerScope 設定為 container。

在此範圍內，拓撲管理器執行一系列循序資源對齊，亦即，針對每個容器（在 Pod 中），都會計算個別的對齊。換句話說，對於此特定範圍，沒有將容器分組到特定 NUMA 節點集合的概念。實際上，拓撲管理器執行個別容器到 NUMA 節點的任意對齊。

容器分組的概念已在以下範圍中有意地被認可和實作，例如 pod 範圍。

pod 範圍

若要選擇 pod 範圍，請在kubelet 設定檔中將 topologyManagerScope 設定為 pod。

此範圍允許將 Pod 中的所有容器分組到一組通用的 NUMA 節點。也就是說，拓撲管理器將 Pod 視為一個整體，並嘗試將整個 Pod（所有容器）配置到單一 NUMA 節點或一組通用的 NUMA 節點。以下範例說明了拓撲管理器在不同情況下產生的對齊方式

• 所有容器可以且已配置到單一 NUMA 節點；
• 所有容器可以且已配置到共用的一組 NUMA 節點。

整個 Pod 所需的特定資源總量是根據有效請求/限制公式計算的，因此，此總值等於以下的最大值

• 所有應用程式容器請求的總和，
• 初始化容器請求的最大值，

針對某個資源。

搭配 single-numa-node 拓撲管理器策略使用 pod 範圍，對於延遲敏感型工作負載或執行 IPC 的高吞吐量應用程式特別有價值。透過結合這兩個選項，您可以將 Pod 中的所有容器放置在單一 NUMA 節點上；因此，可以消除該 Pod 的 NUMA 間通訊開銷。

在 single-numa-node 策略的情況下，只有在可能的配置中存在合適的 NUMA 節點集合時，才會接受 Pod。重新考慮以上範例

• 僅包含單一 NUMA 節點的集合 - 這會導致 Pod 被允許，
• 而包含更多 NUMA 節點的集合 - 這會導致 Pod 被拒絕（因為需要兩個或更多 NUMA 節點才能滿足配置，而不是一個 NUMA 節點）。

總而言之，拓撲管理器首先計算一組 NUMA 節點，然後根據拓撲管理器策略對其進行測試，這會導致 Pod 被拒絕或允許。

拓撲管理器策略

拓撲管理器支援四種配置策略。您可以透過 kubelet 旗標 --topology-manager-policy 設定策略。有四種支援的策略

• none（預設）
• best-effort
• restricted
• single-numa-node

none 策略

這是預設策略，不會執行任何拓撲對齊。

best-effort 策略

對於 Pod 中的每個容器，使用 best-effort 拓撲管理策略的 kubelet 會呼叫每個提示提供者 (Hint Provider) 以探索其資源可用性。使用此資訊，拓撲管理器會儲存該容器的首選 NUMA 節點親和性 (affinity)。如果親和性不是首選，拓撲管理器將儲存此資訊，並仍然允許 Pod 加入節點。

然後，提示提供者可以在制定資源配置決策時使用此資訊。

restricted 策略

對於 Pod 中的每個容器，使用 restricted 拓撲管理策略的 kubelet 會呼叫每個提示提供者以探索其資源可用性。使用此資訊，拓撲管理器會儲存該容器的首選 NUMA 節點親和性。如果親和性不是首選，拓撲管理器將拒絕此 Pod 加入節點。這將導致 Pod 進入 Terminated 狀態，並出現 Pod 准入失敗。

一旦 Pod 處於 Terminated 狀態，Kubernetes 排程器不會嘗試重新排程 Pod。建議使用 ReplicaSet 或 Deployment 來觸發 Pod 的重新部署。也可以實作外部控制迴圈，以觸發具有 Topology Affinity 錯誤的 Pod 的重新部署。

如果 Pod 被允許加入，提示提供者可以在制定資源配置決策時使用此資訊。

single-numa-node 策略

對於 Pod 中的每個容器，使用 single-numa-node 拓撲管理策略的 kubelet 會呼叫每個提示提供者以探索其資源可用性。使用此資訊，拓撲管理器會判斷是否可能實現單一 NUMA 節點親和性。如果可能，拓撲管理器將儲存此資訊，而提示提供者然後可以在制定資源配置決策時使用此資訊。但是，如果不可能，則拓撲管理器將拒絕 Pod 加入節點。這將導致 Pod 處於 Terminated 狀態，並出現 Pod 准入失敗。

一旦 Pod 處於 Terminated 狀態，Kubernetes 排程器不會嘗試重新排程 Pod。建議使用具有副本數的 Deployment 來觸發 Pod 的重新部署。也可以實作外部控制迴圈，以觸發具有 Topology Affinity 錯誤的 Pod 的重新部署。

拓撲管理器策略選項

對拓撲管理器策略選項的支援需要啟用 TopologyManagerPolicyOptions 功能閘道（預設為啟用）。

您可以根據選項的成熟度級別，使用以下功能閘道來切換選項群組的開啟和關閉

• TopologyManagerPolicyBetaOptions 預設啟用。啟用以顯示 Beta 級別選項。
• TopologyManagerPolicyAlphaOptions 預設停用。啟用以顯示 Alpha 級別選項。

您仍然需要使用 TopologyManagerPolicyOptions kubelet 選項來啟用每個選項。

prefer-closest-numa-nodes

自 Kubernetes 1.32 起，prefer-closest-numa-nodes 選項為 GA (正式發布)。在 Kubernetes 1.32 中，如果 TopologyManagerPolicyOptions 功能閘道已啟用，則此策略選項預設為可見。

拓撲管理器預設情況下不知道 NUMA 距離，並且在制定 Pod 准入決策時不會將其納入考量。此限制在多插槽以及單插槽多 NUMA 系統中都會浮現，如果拓撲管理器決定將資源對齊在非相鄰的 NUMA 節點上，則可能會導致延遲關鍵型執行和高吞吐量應用程式的效能顯著下降。

如果您指定 prefer-closest-numa-nodes 策略選項，則 best-effort 和 restricted 策略在制定准入決策時，會優先選擇彼此距離較短的 NUMA 節點集合。

您可以透過將 prefer-closest-numa-nodes=true 新增至拓撲管理器策略選項來啟用此選項。

預設情況下（不使用此選項），拓撲管理器會將資源對齊在單一 NUMA 節點上，或者，在需要多個 NUMA 節點的情況下，使用最少數量的 NUMA 節點。

max-allowable-numa-nodes (beta)

自 Kubernetes 1.31 起，max-allowable-numa-nodes 選項為 beta (測試版)。在 Kubernetes 1.32 中，如果 TopologyManagerPolicyOptions 和 TopologyManagerPolicyBetaOptions 功能閘道已啟用，則此策略選項預設為可見。

允許 Pod 加入的時間與實體機器上的 NUMA 節點數量有關。預設情況下，在偵測到超過 8 個 NUMA 節點的任何 (Kubernetes) 節點上，Kubernetes 不會執行已啟用拓撲管理器的 kubelet。

您可以透過將 max-allowable-numa-nodes=true 新增至拓撲管理器策略選項來啟用此選項。

設定 max-allowable-numa-nodes 的值本身並不會影響 Pod 准入的延遲，但是將 Pod 繫結到具有許多 NUMA 的 (Kubernetes) 節點確實會產生影響。未來，Kubernetes 的潛在改進可能會提高 Pod 准入效能以及隨著 NUMA 節點數量增加而發生的較高延遲。

Pod 與拓撲管理器策略的互動

考慮以下 Pod 清單中的容器

spec:
  containers:
  - name: nginx
    image: nginx

此 Pod 在 BestEffort QoS 類別中執行，因為未指定任何資源 requests 或 limits。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

此 Pod 在 Burstable QoS 類別中執行，因為請求小於限制。

如果選定的策略不是 none 以外的任何策略，則拓撲管理器將考量這些 Pod 規格。拓撲管理器將諮詢提示提供者以取得拓撲提示。在 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"

此具有整數 CPU 請求的 Pod 在 Guaranteed QoS 類別中執行，因為 requests 等於 limits。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "300m"
        example.com/device: "1"

此具有共享 CPU 請求的 Pod 在 Guaranteed QoS 類別中執行，因為 requests 等於 limits。

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 在 BestEffort QoS 類別中執行，因為沒有 CPU 和記憶體請求。

拓撲管理器將考量上述 Pod。拓撲管理器將諮詢提示提供者，即 CPU 和裝置管理器，以取得 Pod 的拓撲提示。

在具有整數 CPU 請求的 Guaranteed Pod 的情況下，static CPU 管理器策略將傳回與獨佔 CPU 相關的拓撲提示，而裝置管理器將傳回請求裝置的提示。

在具有共享 CPU 請求的 Guaranteed Pod 的情況下，static CPU 管理器策略將傳回預設拓撲提示，因為沒有獨佔 CPU 請求，而裝置管理器將傳回請求裝置的提示。

在上述兩種 Guaranteed Pod 的情況下，none CPU 管理器策略將傳回預設拓撲提示。

在 BestEffort Pod 的情況下，static CPU 管理器策略將傳回預設拓撲提示，因為沒有 CPU 請求，而裝置管理器將傳回每個請求裝置的提示。

使用此資訊，拓撲管理器會計算 Pod 的最佳提示並儲存此資訊，提示提供者在制定資源分配時將使用該資訊。

已知限制

1. 拓撲管理器允許的最大 NUMA 節點數為 8。如果 NUMA 節點超過 8 個，則在嘗試列舉可能的 NUMA 親和性並產生其提示時，會發生狀態爆炸。請參閱max-allowable-numa-nodes (beta) 以取得更多選項。

2. 排程器不感知拓撲，因此 Pod 可能被排程到某個節點上，然後由於拓撲管理器而在該節點上失敗。