ComputeClass 的最佳做法

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

ComputeClass 設計

下列各節提供在叢集中設計及實作 ComputeClass 的最佳做法，協助您達成各種目標，例如盡可能提高運算能力的彈性、效率、可用性和效能。ComputeClass 適用於手動建立和自動建立的節點集區。

根據策略設計每個 ComputeClass

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

提高資源可用性並減少手動作業負擔

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

提升排程效能並微調節點

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

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

  1. 手動建立的節點集區：這些節點集區具有您希望大多數 Pod 執行的確切規格。設定這些節點集區時，請使用特定節點標籤、節點污點、容量預留項目，或 kubelet 參數等特殊設定。建立這些節點集區時，請根據 Pod 的預估需求，設定節點數量。在 ComputeClass 中，為這些節點集區指派最高優先順序。
  2. 自動建立的節點集區：做為備用措施，使用 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 主動遷移功能。

使用 StorageClasses 提高排程可靠性

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

設計基礎架構，確保運算資源具備彈性、效率和可用性

下列各節提供最佳做法，協助您提升 ComputeClass 運算容量的彈性、效率和可用性，縮短 Pod 處於 Pending 狀態的時間。

要求機器系列，而非機器類型

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

為熱門硬體預留運算資源

如果工作負載仰賴熱門硬體 (例如 TPU 或高效能 GPU)，請為硬體建立 Compute Engine 運算資源預留項目，並在 ComputeClasses 中使用這些預留項目。預留運算資源可提高您所在區域或可用區的硬體可用性，進而提升運算資源的彈性、效率和可用性。如要在 ComputeClass 中使用預留項目，而不影響備用行為，請使用 Specific 或 AnyThenFail 預留項目相似度。如果您使用 AnyBestEffort 或 Automatic 親和性，且沒有可用的預留運算資源，Compute Engine 可能會略過 ComputeClass 優先順序規則，改用隨選硬體。詳情請參閱「使用預留的可用區資源」。

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

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

安全性

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

限制 ComputeClass 設定的 API 存取權

工作負載可以使用 ComputeClass 建立節點，執行專用硬體，包括 GPU 和 TPU。限制只有可在叢集中建立、修改和刪除節點的主體，才能建立、修改和刪除 ComputeClass。如要控管 ComputeClasses 的存取權，請使用 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 變更是否會導致工作負載問題：

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

ComputeClass 作業 (例如主動遷移) 會導致 Pod 遭剔除，並遵循任何已設定的 PodDisruptionBudgets。舉例來說，您可以設定推論 Deployment，讓 PodDisruptionBudget 要求超過 70% 的 Pod 必須可用。在進行中的遷移作業期間，如果剔除 Pod 會違反該預算，GKE 就不會剔除 Pod。為工作負載指定 PodDisruptionBudget，例如：

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

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

保護重要工作負載，避免遭到淘汰

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

最佳做法摘要

本文提供下列 ComputeClasses 最佳做法：

後續步驟