本頁說明在多個 GKE 叢集上管理大型工作負載時，可以採行的最佳做法。這些最佳做法涵蓋將工作負載分散到多個專案，以及調整必要配額的注意事項。
在多個 Google Cloud 專案中分配 GKE 工作負載的最佳做法
為根據業務需求，更妥善地定義專案結構和 GKE 工作負載分配情形，建議您考慮採取下列設計和規劃行動： Google Cloud
- 請按照「決定登陸區的資源階層 Google Cloud 」一文中的指引，初步決定機構的資料夾和專案結構。 Google Cloud 建議使用資源階層元素 (例如資料夾和專案)，根據機構界線或存取權政策劃分工作負載。
- 請考慮是否需要因專案配額而分割工作負載。 Google Cloud 會使用專案配額來限制共用資源的使用量。 您需要按照下方的建議調整大型工作負載的專案配額。對於大多數工作負載，您應該都能在單一專案中達到所需的高配額。這表示配額不應是將工作負載分散到多個專案的主要因素。將工作負載放在較少的專案中，可簡化配額和工作負載的管理作業。
- 請考慮是否打算執行非常大型的工作負載 (數十萬個以上的 CPU)。在這種情況下，將工作負載分割成多個專案，可以提高雲端資源 (例如 CPU 或 GPU) 的可用性。這是因為使用了區域虛擬化的最佳化設定。在這種情況下，請與您的客戶經理聯絡，以取得特別支援和建議。
調整大型 GKE 工作負載配額的最佳做法
本節說明如何調整 GKE 工作負載所用資源的配額。 Google Cloud請根據下列準則調整專案配額。如要瞭解如何使用 Google Cloud 控制台管理配額，請參閱「使用配額」。
Compute Engine 配額與最佳做法
無論是 Autopilot 還是標準模式，GKE 叢集都會使用 Compute Engine 資源執行工作負載。與 Google Cloud內部管理的 Kubernetes 控制平面資源不同，您可以管理及評估工作流程使用的 Compute Engine 配額。
所有在相同專案和區域中代管的 GKE 叢集，都會共用資源和 API 的 Compute Engine 配額。這些配額也與其他 (非 GKE 相關) Compute Engine 資源共用，例如獨立 VM 執行個體或執行個體群組。
預設配額值可支援數百個工作站節點，但如果工作負載較大，則需要調整。不過，平台管理員可以主動調整 Compute Engine 配額，確保 GKE 叢集有足夠資源。評估或調整配額值時，也請考量未來的資源需求。
GKE 工作站節點使用的 Compute Engine 資源配額
下表列出 GKE 工作站節點最常用的 Compute Engine 資源配額。這些配額是依專案和區域設定。配額必須涵蓋工作負載使用的 GKE 工作站節點最大總大小，以及與 GKE 無關的其他 Compute Engine 資源。
| 資源配額 | 說明 |
|---|---|
| CPU | 所有叢集的所有工作站節點使用的 CPU 數量。 |
| CPU 類型 | 所有叢集的所有工作站節點使用的各類型 CPU 數量。 |
| VM 執行個體 | 所有工作站節點的數量。這項配額會自動計算為 CPU 數量的 10 倍。 |
| 每個虛擬私有雲網路的執行個體數 | 連線至 VPC 網路的所有工作站節點數。 |
| 永久磁碟標準 (GB) | 附加至所有工作站節點的標準永久開機磁碟總大小。 |
| Persistent Disk SSD (GB) | 所有工作站節點連接的 SSD 永久開機磁碟總大小。 |
| 本機 SSD (GB) | 附加至所有工作站節點的本機 SSD 暫時磁碟總大小。 |
請務必一併調整工作負載可能需要的資源配額，例如 GPU、IP 位址或搶占型資源。
Compute Engine API 呼叫配額
大型或可擴充的叢集需要較多的 Compute Engine API 呼叫。在下列活動期間，GKE 會發出這些 Compute Engine API 呼叫：
- 檢查運算資源的狀態。
- 在叢集中新增或移除節點。
- 新增或移除新的節點集區。
- 定期為資源加上標籤。
規劃大型叢集架構時，建議您採取下列做法：
- 觀察歷來配額用量。
- 請視需要調整配額，但仍要保留合理的緩衝空間。您可以參考下列最佳做法建議，並根據工作負載需求調整配額。
- 由於配額是依區域設定，因此請只在您打算執行大型工作負載的區域調整配額。
下表列出 Compute Engine API 呼叫的配額。這些配額是針對每個專案設定，且每個區域的配額各自獨立。配額由同一個專案和區域中託管的所有 GKE 叢集共用。
| API 配額 | 說明 | 最佳做法 |
|---|---|---|
| 每個區域每分鐘的查詢數 | GKE 會使用這些呼叫，對各種運算資源的狀態執行多項檢查。 |
如果專案和區域有數百個動態節點，請將這個值調整為 3,500。 如果專案和區域有數千個高度動態的節點，請將這個值調整為 6,000。 |
| 每個區域每分鐘的讀取要求數 | GKE 會使用這些呼叫來監控 VM 執行個體 (節點) 的狀態。 |
如果專案和區域有數百個節點，請將這個值調整為 12,000。 如果專案和區域有數千個節點，請將這個值調整為 20,000。 |
| 每個地區每分鐘的清單要求數 | GKE 會使用這些呼叫來監控執行個體群組 (節點集區) 的狀態。 |
如果專案和區域有數百個動態節點，請勿變更預設值，因為預設值已足夠。 對於有數千個高度動態節點的專案和區域，在多個節點集區中，請將這個值調整為 2,500。 |
| 每個區域每分鐘的執行個體清單參照網址要求數 | GKE 會使用這些呼叫，取得執行中 VM 執行個體 (節點) 的相關資訊。 |
如果專案和區域有數千個高度動態的節點，請將這個值調整為 6,000。 |
| 每個地區每分鐘的作業讀取要求數 | GKE 會使用這些呼叫，取得進行中 Compute Engine API 作業的相關資訊。 |
如果專案和區域有數千個高度動態的節點，請將這個值調整為 3,000。 |
Cloud Logging API 和 Cloud Monitoring API 配額與最佳做法
視叢集設定而定，在 GKE 叢集上執行的大型工作負載可能會產生大量診斷資訊。如果超過 Cloud Logging API 或 Cloud Monitoring API 配額，記錄和監控資料可能會遺失。建議您設定記錄檔的詳細程度，並調整 Cloud Logging API 和 Cloud Monitoring API 配額，以便擷取產生的診斷資訊。Managed Service for Prometheus 會耗用 Cloud Monitoring 配額。
由於每個工作負載都不盡相同，建議您採取下列做法：
- 觀察歷來配額用量。
- 視需要調整配額，或調整記錄與監控設定。 預留合理緩衝時間，以因應非預期問題。
下表列出 Cloud Logging API 和 Cloud Monitoring API 呼叫的配額。這些配額是依專案設定，且由同一專案中託管的所有 GKE 叢集共用。
| 服務 | 配額 | 說明 | 最佳做法 |
|---|---|---|---|
| Cloud Logging API | 每分鐘寫入要求數 | 將項目新增至 Cloud Logging 中儲存的記錄檔時，GKE 會使用這項配額。 |
記錄檔插入率取決於叢集中 Pod 產生的記錄檔量。根據 Pod 數量、應用程式記錄的詳細程度和記錄設定，增加配額。 詳情請參閱管理 GKE 記錄。 |
| Cloud Monitoring API | 每分鐘時間序列擷取要求數 |
將 Prometheus 指標傳送至 Cloud Monitoring 時，GKE 會使用這項配額：
|
請視情況監控及調整這項配額。 詳情請參閱管理 GKE 指標。 |
GKE 節點配額和最佳做法
GKE 支援下列限制：
- 單一叢集最多可有 15,000 個節點，預設配額為 5,000 個節點。這項配額是為每個 GKE 叢集分別設定，不像其他配額是以專案為單位。
- 在 1.31 以上版本中，GKE 支援最多 65,000 個節點的大型叢集。
如果打算將叢集擴充至超過 5,000 個節點，請執行下列步驟：
- 找出要擴充超過 5,000 個節點的叢集。
- 請確保工作負載在調度後，仍符合叢集限制和 GKE 配額。
- 請務必視需要提高Compute Engine 配額，以因應擴充工作負載。
- 請確認叢集的可用性類型為區域，且叢集使用 Private Service Connect。
- 如要申請提高每個叢集的節點數量配額，請與 Cloud Customer Care 團隊聯絡。GKE 團隊會與您聯絡，確保工作負載遵循擴充性最佳做法，並準備好在單一叢集上擴充至超過 5,000 個節點。
避免大型工作負載超出其他限制的最佳做法
每個位置的每個網路可透過 VPC 網路對等互連使用的叢集數量上限
每個位置 (區域和地區視為不同位置) 的同一虛擬私有雲網路中，最多可建立 75 個使用虛擬私有雲網路對等互連的叢集。如果嘗試建立超出限制的額外叢集，系統會傳回類似下列內容的錯誤訊息：
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
在 1.29 版之前建立的 GKE 叢集 (含私人節點) 會使用虛擬私有雲網路對等互連，在 Kubernetes API 伺服器 (由 Google 管理) 與僅具備內部位址的私人節點之間提供內部通訊。
如要解決這個問題，可以使用採用 Private Service Connect (PSC) 連線的叢集。使用 PSC 連線的叢集與使用 VPC 網路對等互連的叢集一樣，可提供相同程度的隔離，且沒有 75 個叢集的限制。具有 PSC 連線的叢集不會使用 VPC 網路對等互連，因此不受 VPC 對等互連數量限制影響。
您可以按照「重複使用 VPC 網路對等互連」一文中的指示，判斷叢集是否使用 VPC 網路對等互連。
如要避免在建立新叢集時達到上限，請按照下列步驟操作：
- 確認叢集使用 PSC。
- 為每個節點集區使用
enable-private-nodes參數，設定節點集區的隔離功能，使其成為私有節點集區。 - 您也可以在叢集層級使用
enable-private-endpoint參數，設定控制層的隔離功能。詳情請參閱「自訂網路區隔」。
或者，您也可以聯絡 Google Cloud 支援團隊，要求提高透過 VPC 網路對等互連建立的叢集數量上限 (75 個)。我們會根據個案情況評估這類要求，如果可以提高限制，則會增加一位數。
使用 HTTP/2 提升擴充性和可靠性
如要在 GKE 上執行大規模工作負載，請使用 HTTP/2，而非 HTTP/1.1。 HTTP/2 可在高流量或高延遲環境中提升效能和連線可靠性。
HTTP/2 的優點
減少連線數： HTTP/2 可讓您透過單一連線傳送多個要求及接收多個回應。這會降低負載平衡器、Proxy 和 NAT 閘道等系統元件的負載。
提升效能一致性： 使用 HTTP/1.1 時，每個要求通常都需要專屬連線。如果其中一個連線發生問題，可能會導致要求延遲或中斷。舉例來說，如果某個 TCP 連線捨棄封包或發生高延遲，可能會影響該連線上的所有要求，進而導致應用程式發生延遲或錯誤。使用 HTTP/2 時，多個要求會共用同一個連線，因此網路問題會以相同方式影響所有要求，讓效能更具可預測性。
內建多項功能，可確保連線穩定：
流量控制：流量控制可協助管理一次傳送的資料量。避免寄件者傳送大量郵件給收件者，並有助於避免網路壅塞。
Ping 框架：Ping 框架是輕量信號，用於檢查連線是否仍處於啟用狀態。 這些信號有助於維持持續連線，並防止中介系統 (例如防火牆或 Proxy) 關閉閒置連線，導致連線中斷。
在 HTTP/1.1 中，如果一段時間沒有流量，連線可能會意外中斷。防火牆或 Proxy 關閉閒置連線以釋出資源時，特別容易發生這種情況。在 HTTP/2 中，ping 影格會定期檢查連線狀態，確保連線保持運作。
多工處理：在 HTTP/1.1 中，如果使用個別連線同時傳送多項要求，接收回應的順序可能會導致問題 (如果一項要求取決於另一項要求)。舉例來說，如果一個要求先完成，但另一個要求有網路延遲，結果可能會是錯誤或順序錯誤的回應。這個問題可能會導致競爭狀況。HTTP/2 會透過單一連線多工處理所有要求，確保回應正確對齊，避免發生這種情況。
使用 HTTP/2 的最佳做法
- 如果應用程式處理大量流量或需要低延遲通訊，請使用 HTTP/2。
- 設定應用程式層級的存活訊號，保持連線開啟。詳情請參閱「連線的運作方式」。
- 監控流量，確認流量使用 HTTP/2。
詳情請參閱「Cloud Load Balancing 中的 HTTP/2 支援」。
後續步驟
- 請參閱我們有關建構大型 GKE 叢集的集數。