規劃大型 GKE 叢集的最佳做法

本頁說明規劃及設計超大型叢集時可採用的最佳做法。

如需所有 GKE 最佳做法的整合總覽，請參閱「GKE 最佳做法」。

規劃大型 GKE 叢集的原因

包括 Kubernetes 在內，每個電腦系統都有一些架構限制。 超過上限可能會影響叢集效能，在某些情況下甚至會導致停機。請按照最佳做法操作，並執行建議動作，確保叢集能大規模穩定執行工作負載。

大型 GKE 叢集的限制

當 GKE 將叢集擴充至大量節點時，GKE 會盡力變更可用資源量，以符合系統需求，同時維持在服務等級目標 (SLO) 內。Google Cloud 支援大型叢集。不過，根據您的用途，您必須考量大型叢集的限制，才能更妥善地因應基礎架構規模需求。

本節說明根據預期節點數量設計大型 GKE 叢集時的限制和注意事項。

一般叢集遷移注意事項

無論目標叢集大小為何，遷移至較高的節點限制時，請考慮下列事項：

  • 如要從區域標準叢集遷移至地區標準叢集，您必須重新建立叢集，才能存取更高的節點配額上限。
  • 如要遷移至使用 Private Service Connect 的叢集，您必須重新建立叢集，才能存取較高的節點配額上限。

叢集大小限制和需求

下表根據目標節點數量，摘要說明 GKE 的擴縮限制和需求：

節點限制 基礎架構需求 網路需求 存取限制 應用實例範例
最多 1,000 個 適用於所有叢集。 沒有其他相關規定。 無，系統會自動擴充至最多 1,000 個節點。 一般工作負載、開發和測試。
1,000 至 5,000 適用於地區 Standard 叢集和 Autopilot 叢集。 無，如符合其他規定，系統會自動將節點擴充至 5,000 個。 大量短期工作和企業服務。
5,000 至 15,000 次
  • 僅適用於區域性 Standard 叢集。
  • 建議使用 GKE 1.36 以上版本，充分發揮大型叢集擴充作業的效能提升優勢。
 如要提高叢集大小和配額上限，請與 Cloud Customer Care 團隊聯絡。 HPC 和資料處理工作負載。
15,000 至 65,000
  • 需要 GKE 1.31 以上版本。
  • 建議使用 GKE 1.36 以上版本，充分發揮大型叢集擴充作業的效能提升優勢。
  • 僅適用於區域性 Standard 叢集。
  • 不支援叢集自動調度器。請改用 GKE API 調高或調低節點集區的規模。
  • 如果服務的 Pod 超過 100 個，就必須是「無標頭」。
  • 除了系統 DaemonSet 之外，每個 Pod 都應在自己的節點上執行。如要在特定節點上排程 Pod，請使用 Kubernetes Pod 相依性或反相依性。
 如要申請提高配額，並取得相關協助，請與 Cloud Customer Care 團隊聯絡。 大型模型訓練。

在多個叢集之間分割工作負載的最佳做法

您可以在單一大型叢集上執行工作負載。與多個叢集相比，這種做法更容易管理、成本效益更高，且能更有效利用資源。不過，在某些情況下，您需要考慮將工作負載分割成多個叢集：

  • 請參閱「多叢集應用實例」，進一步瞭解使用多個叢集的一般規定和情境。
  • 此外，從可擴充性的角度來看，當叢集可能超過下方章節所述的其中一個限制或其中一個 GKE 配額時，請分割叢集。降低達到 GKE 限制的風險，可減少停機或其他可靠性問題的風險。

如果您決定分割叢集，請使用機群管理功能，簡化多叢集機群的管理作業。

限制與最佳做法

為確保架構支援大規模 GKE 叢集，請查看下列限制和相關最佳做法。超過這些限制可能會導致叢集效能降低或產生可靠性問題。

這些最佳做法適用於任何未安裝擴充功能的預設 Kubernetes 叢集。使用 Webhook 或自訂資源定義 (CRD) 擴充 Kubernetes 叢集的做法很常見，但可能會限制您擴充叢集的能力。

下表擴充了主要的 GKE 配額和限制。此外，您也應熟悉大規模叢集的開放原始碼 Kubernetes 限制。

表格中提及的 GKE 版本規定，適用於節點和控制層。

GKE 限制 說明 最佳做法
etcd 資料庫大小 etcd 資料庫的大小上限為 6 GB。您應主動監控叢集的 etcd 資料庫大小，並設定快訊，在用量接近此限制時收到通知。超過上限可能會導致控制層問題。

如要監控用量，請參閱下列資源：

  • 如要查看目前用量，請前往「配額」頁面，查看預先篩選的 GKE 配額清單。
  • 使用洞察資料和建議，在叢集達到 80%、90% 和 95% 的用量時收到快訊。

如要進一步瞭解如何因應用量即將達到上限的情況，請參閱「找出 etcd 用量即將達到上限的叢集」。
各類型 etcd 物件的總大小 指定資源類型所有物件的總大小不得超過 800 MB。舉例來說，您可以建立 750 MB 的 Pod 執行個體和 750 MB 的 Secret，但無法建立 850 MB 的 Secret。如果建立超過 800 MB 的物件，可能會導致 Kubernetes 或自訂控制器無法初始化，進而造成中斷。

儲存在 etcd 中的每種物件總大小不得超過 800 MB。如果叢集使用許多大型 Secret 或 ConfigMap，或是大量 CRD，就特別適用這項功能。
未啟用 GKE Dataplane V2 的叢集服務數量 如果發生下列任一情況，kube-proxy 使用的 iptables 效能就會降低：
  • 服務數量過多。
  • Service 後端的數量過多。

啟用 GKE Dataplane V2 後，即可解除這項限制。

將叢集中的 Service 數量維持在 10,000 個以下。

詳情請參閱「使用服務公開應用程式」。
每個命名空間的服務數量 為服務產生的環境變數數量可能會超過殼層限制。這可能會導致 Pod 在啟動時異常終止。

每個命名空間的 Service 數量應低於 5,000 個。

您可以選擇不填入這些環境變數。請參閱說明文件，瞭解如何將 PodSpec 中的 enableServiceLinks 設為 false。

詳情請參閱「使用服務公開應用程式」。
叢集 (未啟用 GKE Dataplane V2) 中單一 Service 背後的 Pod 數量

每個節點都會執行 kube-proxy，並使用監控功能監控任何 Service 變更。叢集越大，代理程式處理的變更相關資料就越多。在超過 500 個節點的叢集中，這個問題尤其明顯。

端點資訊會分散在不同的 EndpointSlices 中。這項分割作業可減少每次變更時傳輸的資料量。

元件仍可使用端點物件，但超過 1,000 個 Pod 的任何端點都會自動截斷。

單一 Service 背後的 Pod 數應低於 10,000 個。

詳情請參閱「使用服務公開應用程式」。

啟用 GKE Dataplane V2 的叢集，單一 Service 背後的 Pod 數量

GKE Dataplane V2 限制單一服務可公開的 Pod 數量。

Autopilot 叢集使用 GKE Dataplane V2，因此適用相同限制。

在 GKE 1.23 版和更早版本中，單一 Service 背後的 Pod 數應低於 1,000 個。

在 GKE 1.24 以上版本中，單一 Service 背後的 Pod 數應低於 10,000 個。

詳情請參閱「使用服務公開應用程式」。
每個無頭服務的 DNS 記錄

kube-dns 和 Cloud DNS 的無 Headless 服務 DNS 記錄數量都有限制。

將每個無標頭服務的 DNS 記錄數保持在 kube-dns 的 1,000 以下，以及 Cloud DNS 的 3,500/2,000 (IPv4/IPv6) 以下。
所有服務端點的數量 所有服務的端點數量可能會達到上限。這可能會增加程式設計延遲時間，或導致完全無法設計新的端點。

將所有服務中的端點總數維持在 260,000 個以下。

GKE Dataplane V2 是 GKE Autopilot 的預設資料層，目前依賴的 eBPF 對應項最多只能有 260,000 個端點 (所有服務加總)。
每個叢集的 HorizontalPodAutoscaler 物件數量

系統每 15 秒會處理一次 HorizontalPodAutoscaler (HPA)。

根據預設，GKE 最多支援 300 個 HPA 物件。如要提高限制，效能 HPA 設定檔在 1.31 以上版本支援最多 1,000 個 HPA 物件，在 1.33 以上版本則支援最多 5,000 個 HPA 物件。超過這些限制可能會導致效能線性下降。

請將 HPA 物件數量控制在叢集設定檔支援的上限內 (300、1,000 或 5,000 個物件)。否則，HPA 處理頻率可能會線性下降。舉例來說，2,000 個採用標準設定的 HPA 會導致每個 HPA 每 1 分 40 秒重新處理一次。

詳情請參閱「根據資源使用率自動調度資源」、「水平 Pod 自動調度資源的可擴充性」和「設定效能 HPA 設定檔」。
每個節點的 Pod 數 GKE 對每個節點的 Pod 數量有 256 個的硬性限制。這會假設每個 Pod 平均有兩個或更少的容器。如果增加每個 Pod 的容器數量，這個限制可能會降低，因為 GKE 會為每個容器分配更多資源。

建議您使用每個 10 個 Pod 至少有一個 vCPU 的工作節點。

詳情請參閱手動升級叢集或節點集區。
Pod 變更率

Kubernetes 有內部限制，會影響因應擴縮要求建立或刪除 Pod 的速率 (Pod 變動)。此外，如果刪除屬於服務一部分的 Pod，也可能會影響 Pod 流失率。

對於節點數最多 500 個的叢集，每秒平均可建立 20 個 Pod，每秒可刪除 20 個 Pod。

如果叢集超過 500 個節點，預計每秒可建立 100 個 Pod，每秒可刪除 100 個 Pod。

規劃如何擴充工作負載時，請考量 Pod 建立和刪除速率限制。

Pod 與其他資源類型 (例如 EndpointSlice) 共用相同的刪除輸送量。將 Pod 定義為服務的一部分時，可以降低刪除作業的輸送量。

如要讓叢集自動配置器有效移除使用率過低的節點中的 Pod，請避免過於嚴格的 PodDisruptionBudgets和過長的終止寬限期。

我們也不建議使用萬用字元容許條件，因為這可能會導致工作負載排定在即將移除的節點上。
開啟的觀看次數

節點會為您為 Pod 設定的每個 Secret 和 ConfigMaps 建立監控。所有節點建立的監看項目總數，可能會對叢集控制層產生大量負載。

如果每個叢集的監控項目超過 20 萬個，可能會影響叢集的初始化時間。這個問題可能會導致控制層頻繁重新啟動。

定義較大的節點，以減少大量監看項目造成問題的可能性和嚴重程度。提高 Pod 密度 (減少大型節點數量) 可能會減少監看次數，並減輕問題的嚴重程度。

詳情請參閱機器系列比較。
啟用應用程式層 Secret 加密時，每個叢集的 Secret 數量 啟用應用程式層密鑰加密後，叢集啟動時必須解密所有密鑰。如果儲存超過 30,000 個密鑰，叢集在啟動或升級期間可能會變得不穩定，導致工作負載中斷。

使用應用程式層 Secret 加密時，最多可儲存 30,000 個 Secret。

詳情請參閱在應用程式層加密 Secret 物件。
每個節點的記錄頻寬

每個節點傳送至 Cloud Logging API 的記錄檔數量設有上限。預設限制介於 100 Kbps 和 500 Kbps 之間，視負載而定。如果是標準叢集，您可以部署高輸送量的 Logging 代理程式設定，將限制提高至 10 MiB。 如果超過這項限制，系統可能會捨棄記錄項目。

設定 Logging，確保不超過預設限制，或設定高總處理量的 Logging 代理程式。

詳情請參閱「調整記錄處理量」。
節點集區 如果節點集區數量過多，可能會影響基礎架構自動調度資源的延遲時間，因為可新增至叢集的節點組合會增加。工作負載分離或自訂 ComputeClass 等功能會增加節點集區數量。 節點集區數量應少於 200 個。
GKE 備份限制

您可以使用 GKE 備份服務備份及還原 GKE 工作負載。

定義備份方案時，請務必留意 GKE 備份 的限制。

查看 GKE 備份的限制。

如果工作負載可能超出這些限制，建議您建立多個備份計畫來分割備份作業，確保備份作業不會超出限制。
Config Connector 限制

您可以使用 Config Connector，透過 Kubernetes 管理 Google Cloud 資源。 Config Connector 有兩種作業模式：

  • 叢集模式：每個 GKE 叢集都有一個 Config Connector 執行個體。

    在這個模式下，單一 Config Connector 執行個體會載入所有資源。

  • 命名空間模式：叢集中的每個命名空間都有個別的 Config Connector 執行個體。

    在這個模式中，您可以透過命名空間分割受管理資源。 這樣一來，單一 Config Connector 執行個體需要管理的資源量就會減少，進而降低 CPU 和記憶體使用量。

每種模式的擴充性特徵和限制都不同。

如要瞭解資源限制，請參閱「Config Controller 可擴充性指南」。 如要瞭解如何管理大量資源，請參閱「Config Connector 最佳做法」。

後續步驟