Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

ComputeClass 的最佳做法

自動駕駛標準

平台工程師可以使用自訂 ComputeClasses，以宣告方式設定節點設定和備援優先順序，Google Kubernetes Engine (GKE) 會在自動調度資源期間使用這些設定建立節點。您可以根據特定策略和工作負載需求建立 ComputeClass。本文提供在叢集中設計及實作 ComputeClass 的最佳做法。您應該已熟悉自訂 ComputeClass。如需所有 GKE 最佳做法的整合總覽，請參閱「GKE 最佳做法」。

ComputeClass 設計

下列各節提供最佳做法，說明如何根據目標 (例如盡量提高可取得性和效能)，在叢集中設計及實作 ComputeClass。ComputeClass 適用於手動建立和自動建立的節點集區。

根據策略設計每個 ComputeClass

設計每個 ComputeClass 時，請考量工作負載、團隊或機構的特定目標。使用 ComputeClasses 的備援行為，以及選取手動建立和自動建立節點集區的功能，優先處理特定結果，例如減少手動作業負擔或提升排程效能。以下各節說明常見策略。

提高取得性並減少手動作業

如要將節點集區建立作業委派給 GKE，請僅在 ComputeClass 中使用自動建立的節點集區。自動調度器會根據硬體可用性、Pod 資源需求和區域容量設定節點。這項策略可免除手動建立及調整節點集區的需求，並減少與閒置、未使用的節點容量相關的費用。

提升排程效能及微調節點

如要微調最高優先順序的節點並縮短排程延遲時間，請在 ComputeClass 中混合使用手動建立和自動建立的節點集區。這種混合策略可減少 Pod 等待 GKE 建立新節點集區的頻率。由於最高優先順序的節點集區是手動建立，因此您可以微調硬體，以滿足 Pod 的確切需求。

混合策略涉及下列類型的節點集區，這些節點集區在 ComputeClass 中的優先順序如下：

手動建立的節點集區：這些節點集區具有您希望大多數 Pod 執行的確切規格。使用特定節點標籤、節點汙點、容量預留或特殊設定 (例如 kubelet 參數) 設定這些節點集區。建立這些節點集區時，節點數量應與 Pod 預估需求量相同。在 ComputeClass 中，為這些節點集區指派最高優先順序。
自動建立的節點集區：做為備援措施，請使用 ComputeClass 要求額外的節點集區，這些集區仍會針對 Pod 進行最佳化。為這些自動建立的節點集區指派的優先順序，要低於手動建立的節點集區。

下列 ComputeClass 範例使用這項混合策略：

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

部署使用這個 ComputeClass 的工作負載時，GKE 會將 Pod 放置在 manual-pool1 的可用節點上。只有在手動建立的節點集區沒有可用容量時，GKE 才會建立新的節點集區。手動建立的節點集區中現有節點數量增加時，排程延遲時間會縮短，因為 GKE 不必經常建立新節點。

明確定義最後手段的調度資源行為

如果 GKE 無法滿足 ComputeClass 中任何優先順序規則的需求，whenUnsatisfiable 欄位會控管後續作業。為避免版本升級後發生非預期行為，請在每個 ComputeClass 中明確指定這個欄位的值。設定值可協助 ComputeClass 使用者瞭解在工作負載中選取該 ComputeClass 時的預期情況。這個欄位的建議值取決於工作負載類型，如下所示：

一般用途工作負載：如果工作負載可在任何機器系列上執行，請指定 ScaleUpAnyway 值。如果沒有符合 ComputeClass 中優先順序規則的節點，GKE 會擴大使用叢集預設機器系列的節點。
需要特殊硬體的工作負載：如要使用加速器或高效能運算工作負載，且這些工作負載需要特定硬體 (例如 GPU 或特定 Compute Engine 機器系列)，請指定 DoNotScaleUp 值。如果沒有符合 ComputeClass 中優先順序規則的節點，Pod 會維持 Pending 狀態，直到資源可用為止。這種方法可避免 Pod 在不相容的硬體上執行。

詳情請參閱「定義沒有優先順序規則適用時的資源調度行為」。

為大多數工作負載設定叢集層級的預設 ComputeClass

如果大部分工作負載的硬體需求相同，請為叢集設定預設 ComputeClass。如果工作負載未明確選取 ComputeClass，GKE 會套用預設的 ComputeClass。設定預設 ComputeClass 後，應用程式運算子就不必變更節點選取器，也不必在個別 Pod 中手動要求特定節點集區和硬體。如果您設定叢集層級的預設 ComputeClass，請勿為叢集中現有的節點集區新增其他 ComputeClass 的節點標籤和汙點。在叢集層級預設 ComputeClass 的排程期間，GKE 會忽略具有其他 ComputeClass 節點標籤或節點汙染的任何節點集區。

為命名空間設定預設 ComputeClass，以區隔租戶

除了叢集層級的預設 ComputeClass，您也可以為特定命名空間設定預設 ComputeClass。如果您有多租戶環境，或是想將在專用硬體上執行的工作負載分開，請為這些命名空間設定預設 ComputeClass。如要防止系統 Pod 在 GPU 節點等專用硬體上執行，請將一般用途的 ComputeClass 新增為系統命名空間的預設 ComputeClass。

在 Autopilot 模式下執行低互動工作負載

如果工作負載不需要手動互動或管理，請使用 ComputeClasses 在 Autopilot 模式下執行這些工作負載。即使您有 Standard 叢集，也可以在任何 ComputeClass 中啟用 Autopilot 模式。GKE 會在全代管節點上執行選取 Autopilot ComputeClass 的工作負載，並實作 GKE Autopilot 的安全防護、資源調度和帳單功能。詳情請參閱「關於 GKE Standard 中的 Autopilot 模式工作負載」。

有狀態工作負載

下列各節說明如何運用最佳做法，減少依賴持續性資料的有狀態工作負載發生中斷或非預期行為。

停用進行中的遷移作業

主動遷移功能會自動將 Pod 移至 ComputeClass 中優先順序較高的新節點，或有容量可執行未排程 DaemonSet Pod 的節點。在遷移作業進行期間，GKE 會終止現有節點上的 Pod，並在高優先順序節點上建立新 Pod。如果工作負載依賴本機永久儲存空間中的資料，將 Pod 移至新節點可能會導致中斷，因為 Pod 會無法存取永久資料。為避免這個問題，請針對適用於具狀態工作負載的 ComputeClass 停用進行中的遷移作業。

使用 StorageClass 提高排程可靠性

使用 StorageClasses 可透過下列方式，提高有狀態工作負載的排程可靠性：

僅在建立 Pod 後建立磁碟區：如果您使用動態磁碟區佈建，請在 StorageClass 的 volumeBindingMode 欄位中指定 WaitForFirstConsumer 值。這個磁碟區繫結模式會防止建立 PersistentVolume，直到 GKE 建立使用對應 PersistentVolumeClaim 的 Pod 為止。GKE 會在執行 Pod 的節點所在區域中，佈建 PersistentVolume。
使用拓撲感知 StorageClass：如果 ComputeClass 跨越多個機器系列 (例如 C4 和 C3)，請使用啟用自動磁碟類型選取功能的 StorageClass，並僅在支援指定磁碟類型的節點上排程。您可以使用內建的 dynamic-rwo StorageClass 或自訂 StorageClass。由於叢集自動調度器會動態選擇相容的磁碟類型，因此有狀態工作負載可在多個 Compute Engine 執行個體世代上執行。

可取得性

下列各節提供改善 ComputeClass 可取得性的最佳做法，讓 Pod 處於 Pending 狀態的時間縮短。

要求機器系列，而非機型

您可以在 ComputeClass 優先順序規則中，要求 Compute Engine 機器系列或特定機器類型。除非您嚴格依賴特定機型，否則請使用machineFamily欄位選取機器系列。在擴縮作業期間，GKE 可以建立使用該機器系列中任何可行機型的節點，提高 Pod 在最偏好節點設定上執行的可能性。

使用運算資源預留項目，確保熱門硬體可用

如果工作負載需要使用熱門硬體 (例如 TPU 或高效能 GPU)，請為這些硬體建立 Compute Engine 容量預留項目，並在 ComputeClass 中使用這些預留項目。容量預留項目可提高您所在區域或可用區的硬體可用性，有助於提高資源取得率。如要在 ComputeClass 中使用預留項目，又不影響回退行為，請使用 Specific 或 AnyThenFail 預留項目親和性。如果您使用 AnyBestEffort 或 Automatic 親和性，但沒有可用的預留容量，Compute Engine 可能會略過 ComputeClass 優先順序規則，改用隨選硬體。詳情請參閱「耗用可用區保留資源」。

至少一小時內不要使用新的預留項目

叢集自動調度器會將容量預留項目的相關資訊儲存在快取中。建立新的運算資源預留項目時，自動調整程式可能需要最多一小時才能探索到該預留項目。建立預訂後，請等待至少一小時，再於工作負載中使用該預訂。如果您在自動配置器將預留項目儲存在快取之前，部署使用預留項目的工作負載，自動調度資源作業可能會失敗。

安全性

下列各節提供最佳做法，協助您提升叢集中 ComputeClass 的安全性。這些措施非常重要，因為 ComputeClass 可用於建立及設定使用昂貴或供應量有限硬體的節點。有意或無意誤用可能會導致工作負載中斷、產生未規劃的資源用量費用，以及配額用盡。

限制對 ComputeClass 設定的 API 存取權

工作負載可使用 ComputeClass 建立執行特殊硬體的節點，包括 GPU 和 TPU。將建立、修改及刪除 ComputeClass 的存取權，限制為與叢集中建立、修改及刪除節點的相同主體。如要控管 ComputeClass 的存取權，請使用 RBAC 政策。

依命名空間限制 ComputeClass 可用性

GKE 客戶通常會依 Kubernetes 命名空間，區隔不同團隊或工作負載類型。ComputeClass 是叢集範圍內的資源，也就是說，根據預設，任何命名空間中的任何工作負載都可以選取任何 ComputeClass。為避免蓄意或意外誤用，請使用 ValidatingAdmissionPolicies 控制每個命名空間中的工作負載可選取的 ComputeClass 集。舉例來說，您可能會禁止網頁前端命名空間中的 Pod 選取會建立加速器的 ComputeClass。確認 ValidatingAdmissionPolicies 檢查是否包含下列常見設定：

檢查所有選取欄位：工作負載可以使用 Pod 規格中的 nodeSelector、nodeAffinity 或 tolerations 欄位選取 ComputeClass。為避免誤選 ComputeClass，請檢查 ValidatingAdmissionPolicy 表達式中的所有這些欄位。
檢查是否略過萬用字元容許條件：明確封鎖或驗證萬用字元容許條件 (例如沒有鍵的 operator: Exists 容許條件)。這些萬用字元選取器可涵蓋大多數節點汙點，包括 ComputeClass 汙點。
檢查所有工作負載控制器：設定政策的 matchConstraints，涵蓋所有工作負載控制器資源 (例如 Deployment、StatefulSet、DaemonSet、Job 和 CronJob)。請勿將檢查範圍僅限於 Pod 資源。

詳情請參閱「限制修改及選取 ComputeClass 的存取權」。

可靠性

以下各節提供最佳做法，可提升 ComputeClass 的自動調度功能和 Pod 遷移作業的可靠性，降低中斷或 Pod 停滯的風險。

避免使用衝突的節點選取器

Pod 中的節點選取器會影響 GKE 放置這些 Pod 的位置，而且在 Autopilot 模式中或使用節點集區自動建立功能時，可能會觸發在叢集中建立新的節點集區。如果 Pod 選取 ComputeClass，並使用節點選取器要求與 ComputeClass 設定衝突的節點，GKE 可能完全不會排程 Pod。

舉例來說，假設 ComputeClass 只要求隨選執行個體。如果 Pod 選取該 ComputeClass，並在節點選取器中選取 Spot VM，GKE 就無法排程 Pod，因為 ComputeClass 和節點選取器彼此衝突。為避免這個問題，請使用 ValidatingAdmissionPolicies 等方法，防止選取 ComputeClasses 的 Pod 也選取系統節點標籤。詳情請參閱「系統節點標籤的節點選取器」。

測試有效遷移作業和自動調整資源配置設定的所有變更

ComputeClass 中的有效遷移和自動調度設定，會直接影響 GKE 終止 Pod 的頻率，以執行將 Pod 移至偏好硬體，以及合併使用率過低的節點等工作。修改現有 ComputeClass 中的這些設定，可能會導致工作負載意外中斷。在現有 ComputeClass 中套用這些設定的任何修改內容之前，請先在預備環境中測試變更。您也可以使用註解，在擴縮期間防止重要工作負載遭到驅逐。

在叢集升級前測試 ComputeClass CRD 更新

GKE 會定期更新 ComputeClass CustomResourceDefinition (CRD)，以新增欄位、修改欄位行為及修正問題。新增和修改的欄位通常會在特定 GKE 版本中生效。將正式環境叢集升級至新的次要版本或修補程式版本之前，請按照下列指引操作，確認 CRD 的變更是否會導致工作負載問題：

在測試環境中測試升級。
如要瞭解 ComputeClass CRD 的變更或新增項目，請參閱 GKE 版本資訊。
請參閱ComputeClass CRD 參考頁面，瞭解目標升級版本中的欄位更新。

使用 PodDisruptionBudget 提高工作負載可用性

造成 Pod 撤銷的 ComputeClass 作業 (例如主動遷移) 會遵守任何已設定的 PodDisruptionBudgets。舉例來說，您可以設定推論 Deployment 的 PodDisruptionBudget，要求可用 Pod 數量超過 70%。在遷移作業進行期間，如果 Pod 遭到驅逐會違反該預算，GKE 就不會驅逐 Pod。為下列工作負載指定 PodDisruptionBudget：

無狀態工作負載，例如推論部署。
複製有狀態的工作負載，例如高可用性資料庫應用程式。

如果工作負載需要執行完畢、只有一個執行個體，或依賴本機永久資料，請勿使用 PodDisruptionBudgets 保護工作負載。指定預算，在工作負載可用性之間取得平衡，並允許升級等函式完成。

防止重要工作負載遭到驅逐

如果工作負載中的每個 Pod 都必須執行完畢才能終止，請在 Pod 規格中新增 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 註解。這項註解可防止 GKE 在自動調度作業期間逐出 Pod。使用這項註解保護無法容許中斷的 Pod，例如單一執行個體有狀態工作負載和長時間執行的批次工作。