本頁面由 Cloud Translation API 翻譯而成。

調整節點效能

如要提升以容器為基礎的應用程式效能，其中一種方法是新增節點，或在節點中新增 CPU 或記憶體等資源，藉此增加叢集資源。不過，這種方式可能所費不貲。調整叢集節點以提升效能，有助於以經濟實惠的方式，最佳化工作負載的資源用量。本文說明如何使用 Performance Tuning Operator 調整工作站節點，進而提升 Google Distributed Cloud 的工作負載效能。

為充分發揮基礎硬體和軟體的效用，不同類型的應用程式 (尤其是高效能應用程式) 適合調整節點設定，例如：

為講求效能的工作負載提供專屬 CPU
保留給標準 Kubernetes Daemon 和服務的 CPU
記憶體頁面大小增加，並使用 1 GiB (吉位元組) 或 2 MiB (兆位元組) 的巨頁
根據系統架構分配工作負載，例如多核心處理器和 NUMA

您可以透過 Performance Tuning Operator 建立 Kubernetes 自訂資源，套用效能設定，藉此設定節點層級的效能。優點如下：

單一整合式設定介面：使用 Performance Tuning Operator 時，您可以更新一或多個 PerformanceTuningProfile 資訊清單，並透過節點選取器套用至工作站節點。您不需要使用多項設定和政策設定，個別設定每個節點。這個方法可讓您以單一整合方式，管理節點層級和容器層級的設定。
持久性和可靠性：您還能透過 Kubernetes 的高可用性架構，享有 Kubernetes 提供的所有可靠性。您可以隨時更新 PerformanceTuningProfile 自訂資源，且這些資源的設定會在叢集主要作業 (例如升級) 期間保留。

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

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

必要條件和限制

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

僅限 Red Hat Enterprise Linux (RHEL)：Performance Tuning Operator 僅支援執行支援版本的 RHEL 的節點。
使用者或混合叢集 (含工作站節點)：Performance Tuning Operator 僅支援搭配使用者或混合叢集中的工作站節點使用。系統不支援使用 Performance Tuning Operator 調整控制層節點。Performance Tuning Operator 會使用節點選取器，判斷如何套用調整設定檔。為確保調整設定檔只套用至工作站節點，每個設定檔自訂資源的 nodeSelector 都必須包含標準工作站節點標籤 node-role.kubernetes.io/worker: ""。如果微調設定檔中的 nodeSelector 與控制層節點上的標籤相符，該節點就不會經過微調，且會設定錯誤條件。如要進一步瞭解錯誤情況，請參閱「檢查狀態」。安裝 Performance Tuning Operator 和套用調整設定檔前，請先確認叢集運作正常。
TuneD 2.22.0：如要使用 Performance Tuning Operator，必須在要調整的工作站節點中預先安裝 TuneD 2.22.0 版。如要進一步瞭解 TuneD，包括安裝操作說明，請參閱 Red Hat Enterprise Linux 說明文件中的「開始使用 TuneD」。效能調整運算子會使用 TuneD 和 cpu-partitioning 設定檔。如果沒有這個設定檔，可以使用下列指令安裝：
```
dnf install -y tuned-profiles-cpu-partitioning
```
工作負載資源需求：如要充分發揮效能調校效果，您應充分瞭解工作負載的記憶體和 CPU 需求 (資源要求和限制)。
可用節點資源：找出節點的 CPU 和記憶體資源。您可以在 /proc/cpuinfo 和 /proc/meminfo 檔案中，分別取得節點的詳細 CPU 和記憶體資訊。您也可以使用 kubectl get nodes 擷取工作站節點可供 Pod 使用的運算和記憶體資源量 (status.allocatable)。
需要排空：在調整程序中，Performance Tuning Operator 會先排空節點，然後套用調整設定檔。因此，節點在效能調整期間可能會回報 NotReady 狀態。建議您使用輪流更新策略 (spec.updateStrategy.type: rolling) 而非批次更新，盡量減少工作負載無法使用的時間。
需要重新啟動：如要讓節點調整變更生效，Performance Tuning Operator 會在套用調整設定檔後重新啟動節點。

安裝 Performance Tuning Operator

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

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

在管理員工作站上建立 performance-tuning 目錄。
從 performance-tuning 目錄，從 Cloud Storage 發布值區下載最新的 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) 和動態准入控制等相關功能的資訊清單。
以根使用者身分，將所有 Performance Tuning Operator 資訊清單遞迴套用至使用者 (或混合) 叢集：
```
kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG
```
建立並執行 Deployment 和 DaemonSet 後，您唯一需要進行的互動就是編輯及套用 PerformanceTuningProfile 資訊清單。

查看工作負載的資源需求

調整節點前，請先瞭解工作負載的運算和記憶體資源需求。如果工作站節點有足夠的資源，您可以調整節點，為工作負載提供有保障的記憶體 (標準和巨頁)，確保服務品質 (QoS) 達到一定水準。

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

如要為 Pod 指派「保證」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)，用於執行 Kubernetes 系統 Daemon，例如 kubelet 和容器執行階段。這組預留 CPU 也會執行作業系統精靈，例如 sshd 和 udev。其餘 CPU 核心會分配為「隔離」。隔離的 CPU 適用於受 CPU 限制的應用程式，這類應用程式需要專屬的 CPU 時間，且不得受到其他應用程式或網路/其他裝置中斷的干擾。

如要在工作站節點的隔離 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。

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

編輯 PerformanceTuningProfile 資訊清單。

如要瞭解資訊清單中的各個欄位，以及查看資訊清單範例，請參閱PerformanceTuningProfile 資源參考資料。
(選用) 為要套用設定檔的工作站節點新增標籤，以符合 spec.nodeSelector 鍵/值組合。

如果自訂資源中未指定任何 spec.nodeSelector 鍵值組，設定檔會套用至所有工作站節點。PerformanceTuningProfile
將資訊清單套用至叢集。
```
kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG
```
更改下列內容：
- PROFILE_MANIFEST：PerformanceTuningProfile 自訂資源的資訊清單檔案路徑。
- KUBECONFIG：叢集 kubeconfig 檔案的路徑。

移除微調設定檔

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

從叢集中刪除 PerformanceTuningProfile 自訂資源。
更新或移除節點上的標籤，以免再次由微調設定檔選取。

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

暫停調整設定檔

如需對叢集執行維護作業，可以編輯 PerformanceTuningProfile 自訂資源，暫時暫停微調作業。建議您在執行叢集升級等重要叢集作業前，暫停微調作業。

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

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

編輯 PerformanceTuningProfile 自訂資源資訊清單，將 spec.paused 設為 true。
使用 kubectl apply 更新資源。

暫停效能調整作業後，效能調整作業控制器會停止所有作業。暫停可避免效能調整作業員控制器作業與任何 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 使用。
拓撲管理工具會使用盡量爭取政策排定工作負載。

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) 系統精靈，例如 `sshd` 和 `udev`。 `cpu.reservedCPUs` 欄位會採用 CPU 編號清單或 CPU 編號範圍。確認 CPU 清單不會與 `cpu.isolatedCPUs` 指定的清單重疊。這兩個欄位列出的 CPU 聯集必須包含節點的所有 CPU。
`cpu.isolatedCPUs`	(選用步驟) 可變動。字串。`cpu.isolatedCPUs` 欄位會定義一組專門用於效能敏感型應用程式的 CPU。CPU 管理工具只會根據 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 的預設大小設為 1G 會從節點中移除所有 2M 相關資料夾。預設的巨大頁面大小為 1G，因此您無法在節點中設定 2M 的巨大頁面。
`pages`	(選用步驟) 可變動。整數。這個欄位指定要在開機時建立的巨頁數量。這個欄位接受頁面陣列。指定 Hugepages 前，請先檢查節點的可用記憶體。請勿要求超出需求的巨頁，也不要將所有記憶體保留給巨頁。工作負載也需要標準記憶體。

節點選取

屬性說明

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

nodeSelector

這是必要旗標，可變動。這個欄位一律需要 Kubernetes 工作站節點標籤 node-role.kubernetes.io/worker:""，確保效能調整作業只在工作站節點上進行。這個欄位會將選用節點標籤做為鍵/值組合。鍵/值組合標籤可用來選取具有相符標籤的特定工作節點。當 nodeSelector 標籤與工作節點上的標籤相符時，系統就會將效能設定檔套用至該節點。如果未在設定檔中指定鍵值標籤，系統會將標籤套用至叢集中的所有工作站節點。

舉例來說，下列 nodeSelector 會指定調整設定檔僅適用於具有相符 app: database 標籤的工作站節點：

...
spec:
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  ...

Kubelet 設定

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

設定檔作業

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

檢查狀態

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

屬性	說明
`conditions`	Condition 代表對設定檔資源目前狀態的最新觀察結果。
`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`	這是必要旗標，類型為條件類型：`Stalled` 或 `Reconciling`。
`readyNodes`	已成功套用調整設定檔的節點數量。
`reconcilingNodes`	`nodeconfig-controller-manager` DaemonSet 正在與最新微調設定檔完成選取 (或先前選取) 節點的數量。
`selectedNodes`	所選記事的數量。也就是符合這個 `PerformanceTuningProfile` 自訂資源節點選取器的節點數量。