調整節點效能

預覽

這項產品或功能適用《服務專屬條款》中「一般服務條款」一節的《正式發布前產品條款》。正式發布前的產品和功能是按照「原樣」提供，支援範圍可能有限。 詳情請參閱推出階段說明。

Performance Tuning Operator 可讓您調整 worker 節點，在 Google Distributed Cloud 最佳化工作負載效能和資源使用率。只要調整節點層級設定 (例如隔離和保留的 CPU、記憶體巨型頁面和 NUMA 放置)，即可提高效能敏感型應用程式的效率，不必增加節點、CPU 或記憶體。

您可以使用 PerformanceTuningProfile 自訂資源管理這些設定，這些資源會透過節點選取器指定 worker 節點，因此您不必個別設定每個節點。在執行升級等主要叢集作業時，系統會保留您的設定。

Performance Tuning Operator 的運作方式

Performance Tuning Operator 的運作方式，是自動調度下列與效能相關的 Kubernetes 和作業系統 (OS) 功能和工具：

• 記憶體管理工具
• CPU Manager
• Topology Manager
• TuneD

為避免衝突，使用 Performance Tuning Operator 時，建議您不要單獨使用上述 Kubernetes 和 OS 工具與功能。

必要條件和限制

以下是使用 Performance Tuning Operator 的必要條件和限制：

• 僅限 Red Hat Enterprise Linux (RHEL)：Performance Tuning Operator 僅支援執行支援 RHEL 版本的節點。

• 具有 worker 節點的使用者或混合式叢集：Performance Tuning Operator 僅支援與使用者或混合式叢集中的 worker 節點搭配使用。不支援使用 Performance Tuning Operator 調整控制層節點。Performance Tuning Operator 會使用節點選取器，決定如何套用調整設定檔。為確保調整設定檔僅套用至 worker 節點，每個設定檔自訂資源中的 nodeSelector 必須包含標準 worker 節點標籤 node-role.kubernetes.io/worker: ""。如果調整設定檔中的 nodeSelector 與控制層節點上的標籤相符，系統就不會調整該節點，並會設定錯誤條件。如要進一步瞭解錯誤狀況，請參閱「檢查狀態」。請先確認叢集運作正常，再安裝 Performance Tuning Operator 並套用調整設定檔。

• TuneD 2.22.0：如要使用 Performance Tuning Operator，必須在要調整的 worker 節點中預先安裝 TuneD 2.22.0 版。如要進一步瞭解 TuneD (包括安裝操作說明)，請參閱 Red Hat Enterprise Linux 說明文件中的「TuneD 入門指南」。Performance Tuning Operator 會使用 TuneD 搭配 cpu-partitioning 設定檔。如果沒有這個設定檔，可以使用下列指令安裝：

  dnf install -y tuned-profiles-cpu-partitioning
  

• 工作負載資源需求：如要充分發揮效能調整功能，您應充分瞭解工作負載的記憶體和 CPU 需求 (資源要求和限制)。

• 可用的節點資源：查看節點的 CPU 和記憶體資源。您可以在 /proc/cpuinfo 和 /proc/meminfo 檔案中，分別取得節點的詳細 CPU 和記憶體資訊。您也可以使用 kubectl get nodes 擷取 worker 節點可供 Pod 使用的運算和記憶體資源量 (status.allocatable)。

• 需要排空：在調整過程中，Performance Tuning Operator 會先排空節點，然後套用調整設定檔。因此，節點可能會在效能調整期間回報 NotReady 狀態。建議您使用滾動式更新策略 (spec.updateStrategy.type: rolling)，而非批次更新，盡可能減少工作負載無法使用的情況。

• 需要重新啟動：為使節點調整變更生效，Performance Tuning Operator 會在套用調整設定檔後重新啟動節點。

安裝 Performance Tuning Operator

Performance Tuning Operator 主要由兩個控制器 (Deployment 和 DaemonSet) 組成，這些控制器會互相互動，根據您的設定檔設定調整節點。根據預設，Google Distributed Cloud 不會安裝 Performance Tuning Operator。您從 Cloud Storage 下載 Performance Tuning Operator 資訊清單，並使用 kubectl apply 在叢集上建立 Performance Tuning Operator 資源。

如要為叢集啟用效能調整功能並使用預設值，請按照下列步驟操作：

1. 在管理員工作站上建立 performance-tuning 目錄。

2. 從 performance-tuning 目錄，從 Cloud Storage 發布 bucket 下載最新的 Performance Tuning Operator 套件：

   gcloud storage cp gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 . --recursive
   

   下載的檔案包含 performance-tuning-operator Deployment 和 nodeconfig-controller-manager DaemonSet 的資訊清單。此外，也包含角色式存取控管 (RBAC) 和動態許可控管等相關函式的資訊清單。

3. 以超級使用者身分，將所有 Performance Tuning Operator 資訊清單遞迴套用至使用者 (或混合) 叢集：

   kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG
   

   建立並執行 Deployment 和 DaemonSet 後，您只需編輯並套用 PerformanceTuningProfile 資訊清單。

查看工作負載的資源需求

調整節點前，您必須瞭解工作負載的運算和記憶體資源需求。如果 worker 節點有足夠的資源，可以調整節點，為保證服務品質 (QoS) 類別中的工作負載提供保證記憶體 (標準和 hugepages)。

Kubernetes 會根據您為相關聯容器指定的資源限制，為每個 Pod 指派 QoS 類別。Kubernetes 接著會使用 QoS 類別，決定如何排定 Pod 和容器，以及如何為工作負載分配資源。如要充分運用節點調整功能，工作負載必須設定 CPU 或記憶體資源要求或限制。

如要獲派保證 QoS 類別，Pod 必須符合下列規定：

• 針對 Pod 中的每個容器：
  • 指定記憶體資源要求 (spec.containers[].resources.requests.memory) 和限制 (spec.containers[].resources.limits.memory) 的值。
  • 記憶體限制值必須等於記憶體要求值。
  • 請指定 CPU 資源要求 (spec.containers[].resources.requests.cpu) 和限制 (spec.containers[].resources.limits.cpu) 的值。
  • CPU 限制值必須等於 CPU 要求值。

下列 Pod 規格摘錄顯示符合保證 QoS 類別規定的 CPU 資源設定：

spec:
  containers:
  - name: sample-app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "128Mi"
        cpu: "2"
      limits:
        memory: "128Mi"
        cpu: "2"
  ...

使用 kubectl get pods 擷取 Pod 詳細資料時，status 區段應包含指派的 QoS 類別，如以下範例所示：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-09-22T21:05:23Z"
  generateName: my-deployment-6fdd69987d-
  labels:
    app: metrics
    department: sales
    pod-template-hash: 6fdd69987d
  name: my-deployment-6fdd69987d-7kv42
  namespace: default
  ...
spec:
  containers:
  ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-09-22T21:05:23Z"
    status: "True"
    type: Initialized
  ...
  qosClass: BestEffort
  startTime: "2023-09-22T21:05:23Z"

如要進一步瞭解 QoS 類別，請參閱 Kubernetes 說明文件中的「Pod 服務品質類別」。如需設定 Pod 和容器，以便指派 QoS 類別的操作說明，請參閱「設定 Pod 的服務品質」

CPU 需求

調整節點時，您可以指定一組「保留」CPU 核心 (spec.cpu.reservedCPUs)，用於執行 kubelet 和容器執行階段等 Kubernetes 系統 daemon。這組預留 CPU 也會執行作業系統 Daemon，例如 sshd 和 udev。其餘 CPU 核心則會分配為「isolated」。隔離的 CPU 適用於受 CPU 限制的應用程式，這類應用程式需要專屬的 CPU 作業時間，不受其他應用程式干擾，也不會受到網路或其他裝置中斷。

如要在 worker 節點的隔離 CPU 上排定 Pod，請按照下列步驟操作：

• 設定 Pod，確保服務品質 (QoS)。

• CPU 需求和限制必須以整數指定。如果您在 Pod 規格中指定部分 CPU 資源，例如 cpu: 0.5 或 cpu: 250m (250 毫核心)，則無法保證排程。

記憶體需求

使用 Performance Tuning Operator 調整節點時，您可以建立巨型分頁，並將其與機器上的非統一記憶體存取 (NUMA) 節點建立關聯。根據 Pod 和節點設定，Pod 可以排定為具有 NUMA 節點親和性。

建立效能調整設定檔

安裝 Performance Tuning Operator 後，您只需與執行工作負載的叢集互動。您會直接在使用者叢集或混合式叢集上建立 PerformanceTuningProfile 自訂資源，而不是在管理員叢集上建立。每個 PerformanceTuningProfile 資源都包含一組參數，用於指定套用至節點的效能設定。

資源中的 nodeSelector 會決定要套用調整設定檔的節點。如要將設定檔套用至節點，請在節點上放置對應的鍵/值組合標籤。調整設定檔會套用至具備 nodeSelector 欄位中指定所有標籤的節點。

您可以在叢集中建立多個 PerformanceTuningProfile 資源。如果有多個設定檔與特定節點相符，系統會在 PerformanceTuningProfile 自訂資源的 status 中設定錯誤條件。如要進一步瞭解「status」部分，請參閱「查看狀態」。

將 PerformanceTuningProfile 自訂資源的命名空間設為 kube-system。

如要調整一或多個 worker 節點，請按照下列步驟操作：

1. 編輯 PerformanceTuningProfile 資訊清單。

   如要瞭解資訊清單中的各個欄位和資訊清單範例，請參閱 PerformanceTuningProfile 資源參考資料。

2. (選用) 針對要套用設定檔的 worker 節點，新增與 spec.nodeSelector 鍵/值組合相符的標籤。

   如果未在 PerformanceTuningProfile 自訂資源中指定 spec.nodeSelector 鍵/值組合，設定檔會套用至所有 worker 節點。

3. 將資訊清單套用至叢集。

   kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG
   

   更改下列內容：

   • PROFILE_MANIFEST：PerformanceTuningProfile 自訂資源的資訊清單檔案路徑。
   • KUBECONFIG：叢集 kubeconfig 檔案的路徑。

移除調整設定檔

如要將節點重設為原始未調整狀態，請按照下列步驟操作：

1. 從叢集刪除 PerformanceTuningProfile 自訂資源。

2. 更新或移除節點上的標籤，以免調整設定檔再次選取該節點。

如果節點有多個相關聯的調整設定檔，請視需要重複上述步驟。

暫停調整設定檔

如需維護叢集，可以編輯 PerformanceTuningProfile 自訂資源，暫時停止調整。建議您先暫停調整，再執行重要的叢集作業，例如叢集升級。

如果設定檔套用失敗，也可能需要暫停調整。如果調整程序失敗，控制器可能會繼續嘗試調整節點，導致節點不斷重新啟動。如果發現節點狀態在「就緒」和「未就緒」之間切換，請暫停調整，以便從損壞狀態復原。

如要暫停調整，請按照下列步驟操作：

1. 編輯 PerformanceTuningProfile 自訂資源資訊清單，將 spec.paused 設為 true。

2. 使用 kubectl apply 更新資源。

暫停效能調整時，Performance Tuning Operator 控制器會停止所有作業。暫停可避免 Performance Tuning Operator 控制器作業與任何 Google Distributed Cloud 控制器作業發生衝突。

PerformanceTuningProfile 資源參照

本節說明 PerformanceTuningProfile 自訂資源中的各個欄位。這項資源可用來為一或多個叢集節點建立調整設定檔。建立設定檔後，資源中的所有欄位皆可變更。設定檔必須位於 kube-system 命名空間。

下列 numa 範例設定檔資訊清單適用於具有 8 個 CPU 核心的節點，並指定下列資源分配：

• 4 個 CPU 核心 (0-3) 已預留給 Kubernetes 系統負載。

• 4 個 CPU 核心 (4-7) 僅供工作負載使用。

• 根據預設，節點記憶體會分割成 2 MiB 頁面，而非標準的 4 Ki 頁面。

• 系統會保留 10 個大小為 1 GiB 的記憶體分頁，供 NUMA 節點 0 使用。

• 系統會保留 5 個 2 MiB 的記憶體頁面，供 NUMA 節點 1 使用。

• Topology Manager 會使用盡力政策排定工作負載。

apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
  name: numa
  namespace: kube-system
spec:
  cpu:
    isolatedCPUs: 4-7
    reservedCPUs: 0-3
  defaultHugepagesSize: 2M
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  pages:
  - count: 10
    numaNode: 0
    size: 1G
  - count: 5
    numaNode: 1
    size: 2M
  topologyManagerPolicy: best-effort

您可以從叢集的 anthos.gke.io 群組中擷取相關的 PerformanceTuningProfile 自訂資源定義。將預先發布版功能註解新增至自行管理的叢集資源後，系統就會安裝自訂資源定義。

CPU 設定

屬性	說明
cpu.reservedCPUs	這是必要旗標，可變動。字串。這個欄位定義了一組要保留給 Kubernetes 系統 Daemon 的 CPU 核心，例如 kubelet、容器執行階段和節點問題偵測工具。這些 CPU 核心也會用於作業系統 (OS) 系統 daemon，例如 sshd 和 udev。 cpu.reservedCPUs 欄位會採用 CPU 編號清單或 CPU 編號範圍。請確認 CPU 清單與 cpu.isolatedCPUs 指定的清單不重疊。這兩個欄位中列出的 CPU 聯集必須包含節點的所有 CPU。
cpu.isolatedCPUs	選用。可變動。字串。cpu.isolatedCPUs 欄位定義了一組專門用於效能敏感應用程式的 CPU。CPU Manager 只會根據 Kubernetes 服務品質 (QoS) 類別，在非預留 CPU 上排定容器。為確保工作負載在隔離的 CPU 上執行，請為 Pod 設定保證 QoS 類別，並為 Pod 或容器指派 CPU 資源。如要保證 Pod 排程，您必須指定整數 CPU 單位，而非部分 CPU 資源 (cpu: "0.5")。 apiVersion: v1 kind: Pod ... spec: containers: ... resources: limits: cpu: "1" requests: cpu: "1" ... 盡可能增加工作負載的隔離 CPU 數量，可獲得最佳效能。這個欄位可接受 CPU 編號清單或 CPU 編號範圍。 請確認 CPU 清單與 cpu.reservedCPUs 指定的清單不重疊，且這兩個欄位中的清單聯集包含節點的所有 CPU。
cpu.balanceIsolated	選用。可變動。布林值。預設值：true。這個欄位會指定獨立 CPU 集是否符合資格，可自動平衡各 CPU 的工作負載。如果將這個欄位設為 false，工作負載就必須明確將每個執行緒指派給特定 CPU，才能將負載分配給各個 CPU。明確指派 CPU 可讓保證工作負載獲得最可預測的效能，但會增加工作負載的複雜度。
cpu.globallyEnableIRQLoadBalancing	這是必要旗標，可變動。布林值。預設值：true。這個欄位會指定是否要為隔離的 CPU 集啟用中斷要求 (IRQ) 負載平衡。

記憶體設定

屬性	說明
defaultHugePageSize	選用。可變動。列舉：1G 或 2M。 這個欄位定義核心啟動參數中的預設 hugepage 大小。Hugepages 會在開機時分配，此時記憶體尚未分散。 請注意，如果將 hugepages 預設大小設為 1G，系統會從節點中移除所有 2M 相關資料夾。如果預設 hugepage 大小為 1G，您就無法在節點中設定 2M hugepage。
pages	選用。可變動。整數。這個欄位指定了啟動時要建立的巨型頁面數量。這個欄位接受頁面陣列。指定 hugepage 前，請先檢查節點的可用記憶體。請勿要求超出所需的巨型分頁，也不要將所有記憶體保留給巨型分頁。工作負載也需要標準記憶體。

節點選取

屬性	說明
nodeSelector	這是必要旗標，可變動。這個欄位一律需要 Kubernetes worker 節點標籤 node-role.kubernetes.io/worker:""，確保只在 worker 節點上執行效能調整。這個欄位會採用選用的節點標籤做為鍵/值組合。鍵/值組合標籤用於選取具有相符標籤的特定 worker 節點。當 nodeSelector 標籤與 worker 節點上的標籤相符時，效能設定檔就會套用至該節點。如未在設定檔中指定鍵/值標籤，則會套用至叢集中的所有 worker 節點。 舉例來說，下列 nodeSelector 指定調整設定檔只會套用至具有相符 app: database 標籤的 worker 節點： ... spec: nodeSelector: app: database node-role.kubernetes.io/worker: "" ...

Kubelet 設定

屬性	說明
topologyManagerPolicy	選用。可變動。列舉：none、best-effort、restricted 或 single-numa-node。預設值：best-effort。 這個欄位會根據指派的服務品質 (QoS) 類別，指定用於為工作負載分配資源的 Kubernetes Topology Manager 政策。如要進一步瞭解如何指派 QoS 類別，請參閱「設定 Pod 的服務品質」。

設定檔作業

屬性	說明
paused	選用。可變動。布林值。將 paused 設為 true，即可暫時防止 DaemonSet 控制器調整所選節點。
updateStrategy	選用。可變動。指定將調整設定變更套用至所選節點的策略。
updateStrategy.rollingUpdateMaxUnavailalble	選用。可變動。整數。預設值：1。指定可同時調整的節點數量上限。只有在 type 設為 rolling 時，這個欄位才會生效。
updateStrategy.type	選用。可變動。列舉：batch 或 rolling。 預設值：rolling。指定如何將設定檔更新套用至所選節點。如要同時將更新套用至所有選取的節點，請將 type 設為 batch。根據預設，系統會依序將更新內容推送至個別節點。

檢查狀態

建立或更新 PerformanceTuningProfile 自訂資源後，控制器會根據資源中提供的設定調整所選節點。如要查看 PerformanceTuningProfile 的狀態，我們會在 Status 中公開下列欄位：

屬性	說明
conditions	條件代表設定檔資源目前狀態的最新可用觀測值。
conditions.lastTransitionTime	一律傳回。字串 (日期時間格式)。上次條件從某個狀態轉換為另一個狀態的時間。這個時間通常代表基礎條件變更的時間。如果無法得知該時間，則會顯示 API 欄位變更的時間。
conditions.message	選用。字串。人類可讀的訊息，指出轉換作業的詳細資料。這個欄位可能為空。
conditions.observedGeneration	選用。整數。如果設定這個欄位，則代表設定條件時依據的 metadata.generation。舉例來說，如果 metadata.generation 為 12，但 status.condition[x].observedGeneration 為 9，則條件與執行個體的目前狀態不符。
conditions.reason	這是必要旗標，字串。上次條件轉換的原因。
conditions.status	這是必要旗標，條件狀態：True、False 或 Unknown。
conditions.type	這是必要旗標，Type 是條件類型：Stalled 或 Reconciling。
readyNodes	已成功套用調整設定檔的節點數量。
reconcilingNodes	所選 (或先前所選) 節點的數量，這些節點正在由 nodeconfig-controller-manager DaemonSet 進行協調，以與最新的調整設定檔保持一致。
selectedNodes	已選取的記事數量。也就是符合這個 PerformanceTuningProfile 自訂資源節點選取器的節點數量。

後續步驟

• 設定 SR-IOV 網路
• etcd 效能