選擇 Google Kubernetes Engine 叢集的大小與範圍

本文說明決定在共用 Google Kubernetes Engine 叢集上執行的工作負載以及叢集的適當大小時應考量的條件。

使用容器而非虛擬機器,不僅可隔離工作負載,還能在相同的基礎架構上承載更多工作負載。

應用程式及其執行所在的容器有不同的 CPU 與記憶體需求。Kubernetes 是容器自動化調度管理平台,會配合 CPU 與記憶體需求,將容器安排到各個機器。機器是否能夠獲得妥善運用,取決於工作負載以及用於排程工作負載的機器。

比起僅執行少量工作負載的小型叢集,您可能會預期執行大量工作負載的大型叢集能夠提供更優異的使用效率。不過,在眾多工作負載之間共用叢集可能會增加複雜度與限制,導致弊端超過潛在優勢。

Google Kubernetes Engine 的設計可支援各種叢集大小。叢集大小的下限是由其橫跨的區域數所定義:一個區域至少要有一個叢集,一個地區至少要有三個叢集。Google Kubernetes Engine 叢集大小的上限定義如下

  • 每個區域 50 個叢集
  • 每個叢集 5000 個節點
  • 每個節點 100 個 Pod
  • 300,000 個容器

您可以在這些限制之下決定叢集的適當大小。以下各節將針對應該考量的條件與利弊提供相關總覽資訊。

調整 Google Kubernetes Engine 叢集的大小

工作負載的行動性

Kubernetes 會嘗試以能夠發揮可用資源最佳效益的方式將 Pod 安排到各個節點。排程作業不僅包含選擇要初次執行 Pod 的機器,還必須注意 Pod 中斷預算。Kubernetes 也可能會重新排程執行中的 Pod 來發揮最佳使用率。不過,如果工作負載使用特定功能,則可能會影響最佳化效果:

如果有許多工作負載因為上述原因而受到限制,則分配到各個節點的 Pod 大致將會固定不變。無法自由進行 Pod 排程代表可能無法達到最佳使用率,另外叢集自動調度資源的效率也會受到影響。在最糟糕的情況下,如果發生節點無法運作的情形,即使有可用的運算能力,Kubernetes 可能還是無法為 Pod 重新排程。

為達到高使用率,請讓 Kubernetes 自由為 Pod 排程。如果不可行,請考慮使用小型的工作負載專屬叢集。如果您在考量 Pod 的限制後,能夠預期 Pod 會如何分配到各個節點,則可選擇符合容器 CPU 與記憶體大小需求的機器大小。為確保備援能力,請妥善設定節點集區,如此在發生節點或區域無法運作的情形時,工作負載會遷移至其他節點而不會違反任何限制。

工作負載的統一性

如果工作負載完全統一,且所有容器都要求相同數量的 CPU 與記憶體,那麼 Kubernetes 會將工作負載順利地安排到各個節點。但是,如果工作負載大小不一,就很難找到一個完美的分配方法,不會因為分散問題而造成資源浪費。如果是工作負載大小不一的情形,大型叢集會有比較優異的資源使用率。

工作負載的彈性

在大部分情況下,叢集的工作負載並非固定不變。工作負載可能會有新增或移除的部署,更重要的是,執行中的 Pod 數可能會因為採用水平式 Pod 自動調度資源而有所變更。

如果工作負載發生變更,請啟用叢集自動配置器功能。啟用這項功能後,Google Kubernetes Engine 會以動態方式從基本節點集區中新增或移除節點,藉此嘗試預估所需容量。如果機器容量大幅超過所需的額外容量,新增到節點集區的機器在一開始可能會顯示低使用率。在大型叢集中,這樣的影響可能微不足道,但在小型叢集中,可能會大幅加重負擔。為了盡可能減輕負擔與成本,請使用較大的叢集或較小的機器。

調整 Google Kubernetes Engine 叢集的範圍

工作負載的地區性

為了盡可能降低延遲、提升可用性,或遵循法規,您可能需要在特定地區或跨越多個地區執行工作負載。Google Kubernetes Engine 叢集會在單一地區或單一區域內執行。因此,執行工作負載所需的地區數,即為所需的 Google Kubernetes Engine 最小叢集數。

工作負載的關鍵性

每當發生會影響關鍵任務工作負載的事件時,都應通知操作人員,讓他們能夠開始修復問題。但是,如果叢集同時執行關鍵任務與非關鍵任務的工作負載時又該如何?事件發生時,可能無法立即掌握是否僅有非關鍵工作負載受到影響,還是關鍵工作負載也受到影響。雖然 Kubernetes 能夠讓您按照優先順序將工作負載分類,不過同一個叢集最好還是執行關鍵程度相同的工作負載。

服務探索與通訊

在相同叢集上執行的工作負載可能會依賴 Kubernetes 的服務探索與負載平衡功能。不過,如果工作負載需要進行跨叢集通訊,您可能會需要使用外部服務註冊資料庫或負載平衡器,確保這些工作負載可彼此探索並連線。

從服務探索與通訊的觀點來看,在一個較大的叢集上管理獨立的工作負載 (例如前端與後端應用程式),通常會比在多個較小的專用叢集上管理來得容易。

身分與存取權管理

在 Google Cloud Platform (GCP) 中,存取權管理是在專案範圍內進行處理。因此,根據組織團隊架構建立專案模型是常見且建議的做法。

Google Kubernetes Engine 叢集屬於專案的一部分,無法由多個專案共用。因此,Google Kubernetes Engine 叢集也必須符合專案的 Cloud 身分與存取權管理 (IAM) 設定。

結合對應的叢集、團隊及專案能簡化角色與權限的管理作業。在大部分情況下,Cloud IAM 能讓您更精細地管理 Kubernetes 存取權,不用在 Kubernetes 上額外設定以角色為基礎的存取權控制 (RBAC)。

不過,如果要在不同團隊之間共用相同叢集,則叢集的上層 GCP 專案也必須跨越多個團隊。在此情況下,Cloud IAM 提供用於管理 Google Kubernetes Engine 存取權的角色可能不夠具體,需要在 Kubernetes 內管理額外 (命名空間層級) 的 RBAC 設定。在 Cloud IAM 與 Kubernetes 兩個位置管理 RBAC 設定會提高系統管理複雜度,所以最好選擇能夠讓您在 Cloud IAM 中管理所有存取權控管的叢集範圍。

維護

雖然 Google Kubernetes Engine 是全代管服務,但還是有幾項維護活動需要考量:

  • 選擇 Kubernetes 版本
  • 選擇升級模型 (手動或排程) 以及維護期間
  • 啟動升級
  • 變更節點集區設定

這些活動都會影響在叢集上執行的工作負載。如果有多個團隊共用相同叢集,那麼要讓團隊對於何時執行工作達成共識,將會是個挑戰。為避免排程問題,請限制與叢集的維護活動相關聯的團隊數。

網路

無論使用多少個節點集區,Google Kubernetes Engine 叢集都會屬於同一個虛擬私人雲端 (VPC) 與子網路。如果連線要求必須在不同的虛擬私人雲端或子網路上執行工作負載,那麼您必須按照一個虛擬私人雲端或子網路至少一個叢集的方式,建立個別叢集。

監控和記錄

由於監控和記錄設定在 Google Kubernetes Engine 叢集中為全域通用,如果工作負載的記錄與監控需求符合,則可在同一個叢集上執行多個工作負載。

計費功能

GCP 會根據個別專案收取費用。對於共用相同叢集以及 (進而共用) 相同 GCP 專案的工作負載,很難判斷哪個工作負載佔整體費用的金額。如需個別工作負載的費用明細,請使用專用的 Google Kubernetes Engine 叢集與 GCP 專案。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁