規劃大型 GKE 叢集


本頁說明規劃及設計超大型叢集時,可以遵循的最佳做法。

為何要規劃大型 GKE 叢集

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

大型 GKE 叢集的限制

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

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

最多可有 5,000 個節點的叢集

設計叢集架構時,如要擴充至 5,000 個節點,請考量下列條件:

如果預期叢集會擴充到超過 5,000 個節點,請與 Cloud Customer Care 聯絡,以提高叢集大小和配額限制。

節點超過 5,000 個的叢集

GKE 支援最多 15,000 個節點的大型標準叢集。 在 1.31 以上版本中,GKE 支援最多 65,000 個節點的大型叢集。65,000 的限制是用於執行大規模 AI 工作負載。

如果您預計將叢集擴展至 15,000 個或 65,000 個節點,請完成下列工作:

  1. 請注意下列限制:

    • 不支援叢集自動配置器。請改用 GKE API 調度節點集區資源
    • 不支援多重網路
    • 如果服務的 Pod 超過 100 個,就必須是「無標頭」
    • 每個 Pod 都應在自己的節點上執行,系統 DaemonSet 除外。如要在特定節點上定義 Pod 排程,可以使用 Kubernetes Pod 相容性或反相容性
    • 如要從可用區叢集遷移至地區叢集,您必須重新建立叢集,才能解鎖更高的節點配額層級。
    • 如要遷移至使用 Private Service Connect 的叢集,必須重新建立叢集,才能解鎖更高的節點配額層級。
  2. 請與 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 效能就會降低:
  • 服務過多。
  • Service 後端的數量過多。

啟用 GKE Dataplane V2 後,這項限制就會解除。

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

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

每個命名空間的服務數量 為服務產生的環境變數數量可能會超過殼層限制。這可能會導致 Pod 在啟動時當機。

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

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

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

叢集內單一 Service 背後的 Pod 數量 (未啟用 GKE Dataplane V2)

每個節點都會執行 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-dnsCloud DNS 都會限制每個無 Headless 服務的 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 資源的擴充性

每個節點的 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 設定的每個 SecretConfigMaps 建立監控。所有節點建立的監看項目總數可能會對叢集控制層產生大量負載。

如果每個叢集的監看次數超過 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 有兩種作業模式:

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

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

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

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

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

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

後續步驟