本頁說明規劃及設計超大型叢集時，可以遵循的最佳做法。
為何要規劃大型 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 最佳做法」。 |