在多個 Google Cloud 專案中分配 GKE 工作負載的最佳做法
為根據業務需求更妥善定義專案結構和 GKE 工作負載分配情形，建議您考慮採取下列設計和規劃行動： Google Cloud
- 請按照「為登陸區決定資源階層 Google Cloud 」中的指引，初步決定貴機構的資料夾和專案結構。 Google Cloud 建議使用資源階層元素 (例如資料夾和專案)，根據貴機構的界線或存取權政策劃分工作負載。
- 請考慮是否需要因專案配額而分割工作負載。Google Cloud 會使用專案配額限制共用資源用量。您需要按照下列建議調整大型工作負載的專案配額。對於大多數工作負載，您應該只要在單一專案中，就能達到所需的高配額。這表示配額不應是將工作負載分散到多個專案的主要動機。將工作負載集中在少數專案中，可簡化配額和工作負載的管理作業。
- 如果您打算執行非常大型的工作負載 (數十萬個以上的 CPU)，在這種情況下，將工作負載拆分為多個專案，可以提高雲端資源 (例如 CPU 或 GPU) 的可用性。這是因為使用了區域虛擬化的最佳化設定。如遇上述情況，請與客戶經理聯絡，取得專屬支援和建議。
調整大型 GKE 工作負載配額的最佳做法
本節說明如何調整 GKE 工作負載使用的 Google Cloud資源配額。請根據下列規範調整專案配額。如要瞭解如何使用 Google Cloud 控制台管理配額，請參閱「查看及管理配額」。
Compute Engine 配額與最佳做法
無論是 Autopilot 還是 Standard 模式，GKE 叢集都會使用 Compute Engine 資源執行工作負載。Kubernetes 控制層資源是由 Google Cloud內部管理，但您可以管理及評估工作流程使用的 Compute Engine 配額。
所有資源和 API 的 Compute Engine 配額，都會由同一個專案和地區中代管的所有 GKE 叢集共用。其他 (與 GKE 無關) Compute Engine 資源 (例如獨立 VM 執行個體或執行個體群組) 也會共用相同的配額。
預設配額值可支援數百個 worker 節點，但如果工作負載較大，則需要調整。不過，平台管理員可以主動調整 Compute Engine 配額，確保 GKE 叢集有足夠資源。評估或調整配額值時，也應考量未來的資源需求。
GKE worker 節點使用的 Compute Engine 資源配額
下表列出 GKE worker 節點最常用的 Compute Engine 資源配額。上述配額設定是以每個專案和區域為基準。配額必須涵蓋工作負載使用的 GKE worker 節點最大合併大小，以及與 GKE 無關的其他 Compute Engine 資源。
| 資源配額 | 說明 |
|---|---|
| CPU | 所有叢集的所有 worker 節點使用的 CPU 數量。 |
| CPU 類型 | 所有叢集的所有 worker 節點使用的各類型 CPU 數量。 |
| VM 執行個體 | 所有 worker 節點的數量。這項配額會自動計算為 CPU 數量的 10 倍。 |
| 每個虛擬私有雲網路的執行個體數 | 連線至虛擬私有雲網路的所有 worker 節點數量。 |
| Persistent Disk 標準 (GB) | 附加至所有 worker 節點的標準永久開機磁碟總大小。 |
| Persistent Disk SSD (GB) | 所有 worker 節點連接的 SSD 永久開機磁碟總大小。 |
| 本機 SSD (GB) | 所有 worker 節點連接的本機 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 | 每分鐘寫入要求數 | GKE 會在將項目新增至 Cloud Logging 儲存的記錄檔時，使用這項配額。 |
記錄插入率取決於叢集內 Pod 產生的記錄量。根據 Pod 數量、應用程式記錄的詳細程度和記錄設定，增加配額。 詳情請參閱「管理 GKE 記錄檔」。 |
| Cloud Monitoring API | 每分鐘時間序列擷取要求數 |
將 Prometheus 指標傳送至 Cloud Monitoring 時，GKE 會使用這項配額：
|
請視情況監控及調整這項配額。 詳情請參閱「管理 GKE 指標」。 |
GKE 節點調度限制和配額
GKE Standard 叢集最多可擴充至 65,000 個節點。視目標節點數量而定，您可能需要滿足特定基礎架構需求，或與 Cloud Customer Care 聯絡。詳情請參閱「叢集大小限制和需求」。
準備擴大規模時，您也應完成下列工作：
- 請參閱 GKE 配額和限制，確認整體支援等級。
- 視需要更新及提高Compute Engine 配額，以因應擴充的工作負載。
使用驗證和變動許可 Webhook 的最佳做法
大規模要求會開始爭奪 kube-apiserver 元件的資源。如果設定的 Webhook 造成不必要的延遲，或涵蓋過多要求，基本叢集作業的效能可能會降低。
建議您將 Webhook 範圍限定在所需作業、資源和命名空間的精確子集，以達成預期行為。如果延遲 100 毫秒，在 65,000 個節點的規模下，Pod 建立速度甚至可能慢兩倍。
避免大型工作負載其他限制的最佳做法
每個位置的每個網路可使用虛擬私有雲網路對接的叢集數量上限
在每個位置 (可用區和區域視為不同位置)，您最多可以建立 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 連線的叢集與使用虛擬私有雲網路對接的叢集一樣，可提供隔離功能，且沒有 75 個叢集的限制。具有 PSC 連線能力的叢集不會使用虛擬私有雲網路對等互連，因此不受虛擬私有雲對等互連數量限制影響。
您可以按照「重複使用虛擬私有雲網路對等互連」一文中的操作說明，判斷叢集是否使用虛擬私有雲網路對等互連。
如要避免在建立新叢集時達到上限，請按照下列步驟操作：
- 確認叢集使用 PSC。
- 使用每個節點集區的
enable-private-nodes參數，將節點集區的隔離設定設為私人。 - 您可以視需要使用叢集層級的
enable-private-endpoint參數，設定控制層的隔離功能。詳情請參閱「自訂網路區隔」。
或者，您也可以聯絡 Google Cloud 支援團隊，要求提高使用虛擬私有雲網路對等互連的叢集數量上限 (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 叢集的集數。