規劃大型 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 次 |
|
|
如要提高叢集大小和配額限制，請與 Cloud Customer Care 團隊聯絡。 | HPC 和資料處理工作負載。 |
| 15,000 至 65,000 次 |
|
|
如要申請提高配額，並取得相關協助，請與 Cloud Customer Care 團隊聯絡。 | 訓練大型模型。 |
在多個叢集之間分割工作負載的最佳做法
您可以在單一大型叢集上執行工作負載。與多個叢集相比，這種做法更容易管理、更具成本效益，且能更有效地利用資源。不過，在某些情況下，您需要考慮將工作負載分割為多個叢集：
- 請參閱「多叢集用途」，進一步瞭解使用多個叢集的一般需求和情境。
- 此外，從可擴充性的角度來看，當叢集可能超過下方章節所述的其中一個限制，或其中一個 GKE 配額時，請分割叢集。降低達到 GKE 限制的風險，可減少停機或其他可靠性問題。
如果您決定分割叢集，請使用機群管理功能，簡化多叢集機群的管理作業。
限制與最佳做法
為確保架構支援大規模 GKE 叢集，請查看下列限制和相關最佳做法。超過這些限制可能會導致叢集效能降低或產生可靠性問題。
這些最佳做法適用於任何未安裝擴充功能的預設 Kubernetes 叢集。使用 Webhook 或自訂資源定義 (CRD) 擴充 Kubernetes 叢集是常見的做法，但可能會限制叢集的擴充能力。
下表擴充了主要的 GKE 配額和限制。此外，您也應熟悉大規模叢集的開放原始碼 Kubernetes 限制。
表格中提及的 GKE 版本規定適用於節點和控制層。
| GKE 限制 | 說明 | 最佳做法 |
|---|---|---|
| etcd 資料庫大小 | etcd 資料庫的大小上限為 6 GB。建議您主動監控叢集的 etcd 資料庫大小，並設定快訊，以便在用量接近這項限制時收到通知。超過上限可能會導致控制層發生問題。 | 如要監控用量，請參閱下列資源： 如要進一步瞭解 etcd 用量接近上限時的應對方式，請參閱「找出 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 效能會降低：
啟用 GKE Dataplane V2 後，這項限制就會取消。 |
請將叢集中的服務數量維持在 10,000 以下。 詳情請參閱「使用 Service 公開應用程式」。 |
| 每個命名空間的服務數量 | 為服務產生的環境變數數量可能會超過殼層限制。這可能會導致 Pod 在啟動時異常終止。 |
每個命名空間的服務數量不得超過 5,000 個。 您可以選擇不採用填入這些環境變數。請參閱說明文件，瞭解如何將 PodSpec 中的 詳情請參閱「使用 Service 公開應用程式」。 |
| 叢集中單一服務後方的 Pod 數量 (未啟用 GKE Dataplane V2) |
每個節點都會執行 kube-proxy，並使用監控功能監控任何服務變更。叢集越大，代理程式處理的變更相關資料就越多。如果叢集超過 500 個節點，這種情況會更加明顯。 端點資訊會分散在不同的 元件仍可使用端點物件，但超過 1,000 個 Pod 的端點會自動截斷。 |
單一 Service 後方的 Pod 數量應低於 10,000 個。 詳情請參閱「使用服務公開應用程式」。 |
| 啟用 GKE Dataplane V2 的叢集中，單一服務後方的 Pod 數量 |
GKE Dataplane V2 限制單一 Service 可公開的 Pod 數量。 Autopilot 叢集使用 GKE Dataplane V2，因此適用相同限制。 |
在 GKE 1.23 和更早版本中，單一服務後方的 Pod 數量不得超過 1,000 個。 在 GKE 1.24 以上版本中，單一 Service 後方的 Pod 數量應低於 10,000 個。 詳情請參閱「使用服務公開應用程式」。 |
| 每個無頭服務的 DNS 記錄 |
每個無頭 Service 的 DNS 記錄數量，kube-dns 應低於 1,000 筆，Cloud DNS 則應低於 3,500/2,000 筆 (IPv4/IPv6)。 |
|
| 所有服務端點的數量 | 所有 Service 的端點數量可能達到上限。這可能會增加程式設計延遲時間，或導致完全無法設計新的端點。 |
所有服務中的端點總數應低於 260,000 個。 GKE Dataplane V2 是 GKE Autopilot 的預設資料層，依賴的 eBPF 對應目前在所有 Service 中最多只能有 260,000 個端點。 |
| 每個叢集的 HorizontalPodAutoscaler 物件數量 |
每隔 15 秒就會處理一次水平 Pod 自動配置器 (HPA)。 根據預設，GKE 最多支援 300 個 HPA 物件。如需更高的上限，效能 HPA 設定檔在 1.31 以上版本可支援 1,000 個 HPA 物件，在 1.33 以上版本則可支援最多 5,000 個 HPA 物件。超過這些限制可能會導致效能線性下降。 |
將 HPA 物件數量控制在叢集設定檔支援的上限內 (300、1,000 或 5,000 個物件)。否則，HPA 處理頻率可能會線性下降。舉例來說，如果使用標準設定的 HPA 數量為 2,000 個，每個 HPA 每 1 分 40 秒只會重新處理一次。 詳情請參閱「依據資源使用率自動調度資源」、「水平自動調度 Pod 資源擴充性」和「設定效能 HPA 設定檔」。 |
| 每個節點的 Pod 數量 | 在 Standard 叢集中，GKE 每個節點最多可有 512 個 Pod。這項假設的前提是每個 Pod 平均有兩個或更少的容器。如果增加每個 Pod 的容器數量，這個上限可能會降低，因為 GKE 會為每個容器分配更多資源。 |
建議每 10 個 Pod 使用至少一個 vCPU 的 worker 節點。 詳情請參閱「手動升級叢集或節點集區」。 |
| 廣告連播變更率 |
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 數量 | 啟用應用程式層 Secret 加密功能後，叢集啟動時必須解密所有 Secret。如果儲存超過 30,000 個 Secret，叢集在啟動或升級期間可能會不穩定，導致工作負載中斷。 | 使用應用程式層 Secret 加密功能時，儲存的 Secret 數量應少於 30,000 個。 詳情請參閱「在應用程式層加密 Secret」。 |
| 每個節點的記錄頻寬 |
每個節點傳送至 Cloud Logging API 的記錄數量設有上限。預設限制介於 100 Kbps 和 500 Kbps 之間，視負載而定。如果是 Standard 叢集，您可以部署高處理量 Logging 代理程式設定，將限制提高至 10 MiB。 如果超過此限制，系統可能會捨棄記錄項目。 |
設定記錄功能，確保不超過預設限制，或設定高處理量的 Logging 代理程式。 詳情請參閱「調整記錄處理量」。 |
| 節點集區 | 如果節點集區數量過多，可能會影響基礎架構自動調整資源配置延遲時間，因為這會增加可新增至叢集的節點集。工作負載分離或自訂 ComputeClass 等功能會增加節點集區數量。 | 節點集區數量應少於 200 個。 |
| 許可 Webhook 的平均和最長延遲時間 |
系統會平行 (驗證) 或依序 (變更) 呼叫許可 Webhook。在上述兩種情況下，系統都會為符合 Webhook 選擇器的每個已設定要求新增延遲時間。執行 Webhook 時，如果持續出現短暫延遲 (例如 50 到 100 毫秒)，可能會導致效能大幅降低。 |
請設定網路鉤子，讓執行延遲時間平均低於 10 毫秒。指定 Webhook 應參照的作業、資源類型和命名空間。請避免擷取事件，因為這可能會導致效能問題，例如圖片預先擷取速度變慢。在與工作負載不同的節點上執行多個 Webhook 端點執行個體，並維持低延遲。建議您執行 |
| GKE 備份限制 |
您可以使用 GKE 備份服務備份及還原 GKE 工作負載。 定義備份方案時，請務必留意 GKE 備份的限制。 |
查看 GKE 備份的限制。 如果工作負載可能超出這些限制，建議您建立多個備份方案，將備份作業分區，並保持在限制範圍內。 |
| Config Connector 限制 |
您可以使用 Config Connector，透過 Kubernetes 管理 Google Cloud 資源。 Config Connector 有兩種作業模式： 每種模式的擴充性特徵和限制都不同。 |
如要進一步瞭解資源限制，請參閱「Config Controller 擴充指南」。如要瞭解如何管理大量資源，請參閱「Config Connector 最佳做法」。 |