本頁說明規劃及設計超大型叢集時,可以遵循的最佳做法。
為何要規劃大型 GKE 叢集
包括 Kubernetes 在內,每個電腦系統都有一些架構限制。超過上限可能會影響叢集效能,甚至導致停機。請按照最佳做法操作,並執行建議動作,確保叢集能大規模穩定執行工作負載。
大型 GKE 叢集的限制
當 GKE 將叢集擴充至大量節點時,GKE 會盡力變更可用資源量,以符合系統需求,同時維持在服務等級目標 (SLO) 內。Google Cloud 支援大型叢集。不過,根據您的用途,您必須考量大型叢集的限制,才能更妥善地因應基礎架構規模需求。
本節說明根據預期節點數量設計大型 GKE 叢集時的限制和注意事項。
最多可有 5,000 個節點的叢集
設計叢集架構時,如要擴充至 5,000 個節點,請考量下列條件:
- 僅適用於區域叢集。
- 僅適用於使用 Private Service Connect 的叢集。
- 如要從可用區叢集遷移至地區叢集,您必須重新建立叢集,才能解鎖更高的節點配額層級。
如果預期叢集會擴充到超過 5,000 個節點,請與 Cloud Customer Care 聯絡,以提高叢集大小和配額限制。
節點超過 5,000 個的叢集
GKE 支援最多 15,000 個節點的大型標準叢集。 在 1.31 以上版本中,GKE 支援最多 65,000 個節點的大型叢集。65,000 的限制是用於執行大規模 AI 工作負載。
如果您預計將叢集擴展至 15,000 個或 65,000 個節點,請完成下列工作:
請注意下列限制:
- 不支援叢集自動配置器。請改用 GKE API 調度節點集區資源。
- 不支援多重網路。
- 如果服務的 Pod 超過 100 個,就必須是「無標頭」。
- 每個 Pod 都應在自己的節點上執行,系統 DaemonSet 除外。如要在特定節點上定義 Pod 排程,可以使用 Kubernetes Pod 相容性或反相容性。
- 如要從可用區叢集遷移至地區叢集,您必須重新建立叢集,才能解鎖更高的節點配額層級。
- 如要遷移至使用 Private Service Connect 的叢集,必須重新建立叢集,才能解鎖更高的節點配額層級。
請與 Cloud 客戶服務聯絡,視您的擴充需求,將叢集大小和配額上限提高至 15,000 個節點或 65,000 個節點。
在多個叢集之間分割工作負載的最佳做法
您可以在單一大型叢集上執行工作負載。與多個叢集相比,這種做法更容易管理、成本效益更高,且能更充分地運用資源。不過,在某些情況下,您需要考慮將工作負載分割成多個叢集:
- 請參閱「多叢集應用實例」,進一步瞭解使用多個叢集的一般規定和情境。
- 此外,從可擴充性的角度來看,當叢集可能超過下方章節所述的其中一項限制,或是其中一項 GKE 配額時,請分割叢集。降低達到 GKE 限制的風險,有助於減少停機或其他可靠性問題的風險。
如果您決定分割叢集,請使用機群管理功能,簡化多叢集機群的管理作業。
限制與最佳做法
為確保架構支援大規模 GKE 叢集,請查看下列限制和相關最佳做法。超過這些限制可能會導致叢集效能降低或產生可靠性問題。
這些最佳做法適用於任何未安裝擴充功能的預設 Kubernetes 叢集。使用 Webhook 或自訂資源定義 (CRD) 擴充 Kubernetes 叢集的做法很常見,但可能會限制您擴充叢集的能力。
下表擴充了主要的 GKE 配額和限制。此外,您也應熟悉大規模叢集的開放原始碼 Kubernetes 限制。
表格中提及的 GKE 版本規定,適用於節點和控制層。
GKE 限制 | 說明 | 最佳做法 |
---|---|---|
etcd 資料庫大小 | etcd 資料庫的大小上限為 6 GB。如果您執行非常大的叢集,其中有數萬個資源,etcd 執行個體可能會超過這個限制。您可以在Google Cloud 控制台中查看叢集的使用率。建議會在叢集即將達到限制的 24 小時內顯示。詳情請參閱「找出 etcd 用量即將達到上限的叢集」。 | 如果超過這項限制,GKE 可能會將 etcd 執行個體標示為不正常。這會導致叢集控制層沒有回應。 如果超過這項限制,請與Google Cloud 支援團隊聯絡。 |
每種型別的 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 效能就會降低:
啟用 GKE Dataplane V2 後,這項限制就會解除。 |
將叢集中的服務數量維持在 10,000 個以下。 詳情請參閱「使用服務公開應用程式」。 |
每個命名空間的服務數量 | 為服務產生的環境變數數量可能會超過殼層限制。這可能會導致 Pod 在啟動時當機。 |
每個命名空間的 Service 數量應低於 5,000 個。 您可以選擇不填入這些環境變數。請參閱說明文件,瞭解如何將 PodSpec 中的 詳情請參閱「使用服務公開應用程式」。 |
叢集內單一 Service 背後的 Pod 數量 (未啟用 GKE Dataplane V2) |
每個節點都會執行 kube-proxy,並使用監控功能監控任何 Service 變更。叢集越大,代理程式處理的變更相關資料就越多。在超過 500 個節點的叢集中,這種情況尤其明顯。 端點相關資訊會分散在不同的 元件仍可使用端點物件,但超過 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 記錄 |
將每個無標頭服務的 DNS 記錄數保持在 1,000 以下 (kube-dns) 和 3,500/2,000 (IPv4/IPv6) 以下 (Cloud DNS)。 |
|
所有服務端點的數量 | 所有服務的端點數量可能會達到上限。這可能會增加程式設計延遲時間,或導致完全無法設計新端點。 |
所有服務中的端點總數不得超過 26 萬個。 GKE Dataplane V2 是 GKE Autopilot 的預設資料平面,目前依賴的 eBPF 對應表最多只能有 260,000 個端點 (適用於所有服務)。 |
每個叢集的水平 Pod 自動配置器物件數量 |
系統每 15 秒會處理一次水平 Pod 自動調度資源 (HPA)。 超過 300 個 HPA 物件可能會導致效能線性下降。 |
請將 HPA 物件數量控制在這個上限內,否則 HPA 處理頻率可能會線性下降。舉例來說,在 GKE 1.22 中,如果 HPA 數量為 2,000 個,系統每 1 分 40 秒就會重新處理一個 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 代理程式。 詳情請參閱「調整記錄吞吐量」。 |
節點集區 | 如果節點集區數量過多,可能會影響基礎架構自動調度資源的延遲時間,因為可新增至叢集的節點組合會增加。工作負載分離或自訂運算類別等功能會增加節點集區數量。 | 節點集區數量應少於 200 個。 |
Backup for GKE 限制 |
您可以使用 GKE 備份服務備份及還原 GKE 工作負載。 定義備份方案時,請務必留意 Backup for GKE 的限制。 |
查看 GKE 備份的限制。 如果工作負載可能超出這些限制,建議您建立多個備份計畫來分割備份作業,確保備份作業不會超出限制。 |
Config Connector 限制 |
您可以使用 Config Connector,透過 Kubernetes 管理 Google Cloud 資源。 Config Connector 有兩種作業模式: 每種模式的擴充性特徵和限制都不同。 |
如要瞭解資源限制,請參閱「Config Controller 可擴充性指南」。 如要瞭解如何管理大量資源,請參閱「Config Connector 最佳做法」。 |