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

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

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

為何要規劃大型 GKE 叢集

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

大型 GKE 叢集的限制

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

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

一般叢集遷移注意事項

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

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

自動叢集大小限制

設計叢集架構時，請注意 GKE 允許使用 Private Service Connect 和 GKE Dataplane V2 的區域標準叢集，自動擴充至 5,000 個節點，不必聯絡支援團隊。

請考慮下列情況：

如果您預期叢集會超出這個自動上限，請與 Cloud Customer Care 聯絡，以提高叢集大小和配額上限。

需要提高配額的叢集大小

如果您打算將叢集擴充至超過自動限制，請完成下列工作：

叢集節點數介於 5,000 到 15,000 之間

在這個規模範圍內，GKE 支援最多 15,000 個節點的大型標準叢集，叢集自動調度器最多支援 15,000 個節點。如要擴充至這些限制，請與 Cloud Customer Care 團隊聯絡，以提高叢集大小和配額限制。

巨型叢集 (超過 15,000 個節點，最多 65,000 個)

在 1.31 以上版本中，GKE 支援最多 65,000 個節點的大型叢集。這項限制主要經過最佳化調整，可執行大規模 AI 工作負載。

如果您打算將叢集擴展至 65,000 個節點，請完成下列工作：

  1. 請注意下列限制：

  2. 請與 Cloud Customer Care 聯絡，視您的擴充需求，將叢集大小和配額上限提高至最多 65,000 個節點。

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

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

  • 請參閱「多叢集應用實例」，進一步瞭解使用多個叢集的一般規定和情境。
  • 此外，從可擴充性的角度來看，當叢集可能超過下方章節所述的其中一個限制，或其中一個 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。

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

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

端點資訊會分成多個 EndpointSlices。這項分割作業可減少每次變更時傳輸的資料量。

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

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

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

啟用 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 記錄數保持在 1,000 以下 (kube-dns) 和 3,500/2,000 (IPv4/IPv6) 以下 (Cloud DNS)。
所有服務端點的數量 所有服務的端點數量可能會達到上限。這可能會增加程式設計延遲時間，或導致完全無法設計新的端點。

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

GKE Dataplane V2 是 GKE Autopilot 的預設資料層，目前依賴的 eBPF 對應項最多只能有 260,000 個端點，且這些端點會分布在所有服務中。
每個叢集的水平 Pod 自動配置器物件數量

系統每 15 秒會處理一次水平 Pod 自動調度資源 (HPA)。

如果 HPA 物件超過 300 個，效能可能會線性下降。

請將 HPA 物件數量控制在這個上限內，否則 HPA 處理頻率可能會線性下降。舉例來說，在有 2,000 個 HPA 的 GKE 1.22 中，每個 HPA 每 1 分 40 秒就會重新處理一次。

詳情請參閱依據資源使用率自動調度資源和自動水平調度 Pod 資源的擴充性。
每個節點的 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，叢集在啟動或升級期間可能會變得不穩定，導致工作負載服務中斷。

使用應用程式層 Secret 加密時，儲存的 Secret 不得超過 30,000 個。

詳情請參閱在應用程式層加密 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 最佳做法」。

後續步驟