在 GKE 上執行最具成本效益的 Kubernetes 應用程式的最佳做法

這份文件介紹 Google Kubernetes Engine (GKE) 的功能與選項，並提供最佳做法，協助您在 GKE 執行成本效益最佳的應用程式，讓您善用 Google Cloud提供的彈性。這份說明文件假設您已熟悉 Kubernetes、Google Cloud、GKE 和自動調度資源機制。

簡介

隨著 Kubernetes 廣為採用，越來越多企業、平台即服務 (PaaS) 和軟體即服務 (SaaS) 供應商，都使用多用戶群 Kubernetes 叢集來處理工作負載。也就是說，單一叢集可能正在執行屬於不同團隊、部門、客戶或環境的應用程式。Kubernetes 提供的多租戶功能可讓公司管理幾個大型叢集，而非多個小型叢集，好處包括適當的資源使用率、簡化的管理控制，以及減少分散。

隨著時間推移，部分 Kubernetes 叢集快速成長的公司開始發現成本大幅增加，這是因為採用 Kubernetes 等雲端解決方案的傳統公司，缺乏具備雲端專業知識的開發人員和營運人員。這種雲端就緒程度不足的情況，會導致應用程式在自動擴充期間變得不穩定 (例如，一天中某段時間的流量波動、突然爆量或尖峰流量，像是電視廣告或黑色星期五和網購星期一等尖峰擴充活動)。為了「修正」問題，這些公司往往會像在非彈性環境中一樣，過度佈建叢集。過度佈建會導致 CPU 和記憶體配置量遠高於應用程式在一天中大部分時間的使用量。

本文提供最佳做法，協助您在 GKE 上執行最具成本效益的 Kubernetes 工作負載。下圖概述了這項做法。

如要建構成本最佳化的應用程式，首先要讓各團隊都養成節省成本的習慣。除了將成本討論移至開發程序開頭，這種做法還能讓您更瞭解應用程式執行的環境 (在本例中為 GKE 環境)。

如要降低成本並確保應用程式穩定性，您必須正確設定或調整部分功能和設定 (例如自動調度資源、機器類型和區域選取)。另一個重要考量是工作負載類型，因為根據工作負載類型和應用程式需求，您必須套用不同的設定，才能進一步降低成本。最後，您必須監控支出並建立防護措施，以便在開發週期的早期階段就落實最佳做法。

下表摘要說明 GKE 有助於解決的挑戰。我們建議您詳閱整份文件，但這份表格會列出涵蓋的主題。

GKE 成本最佳化功能和選項

最具成本效益的 Kubernetes 應用程式非常仰賴 GKE 自動調度資源功能。如要在 GKE 上兼顧成本、可靠性和擴充效能，您必須瞭解自動調度資源的運作方式和可用選項。本節將討論 GKE 自動調度功能，以及適用於服務和批次工作負載的其他實用成本最佳化設定。

微調 GKE 自動調度資源功能

自動調度資源是 GKE 採用的策略，可盡量縮短基礎架構的正常運作時間，讓客戶只支付所需資源的費用。Google Cloud 換句話說，自動調度資源功能會 1) 在需求增加前啟動工作負載和基礎架構，並 2) 在需求減少時關閉這些項目，藉此節省成本。

下圖說明瞭這個概念。在 Kubernetes 中，工作負載是容器化應用程式，會在 Pod 內執行，而由一組節點組成的基礎架構必須提供足夠的運算容量，才能執行工作負載。

如下圖所示，這個環境有四個可擴充性維度。您可以新增及移除 Pod 或節點，水平擴充工作負載和基礎架構，也可以增加及減少 Pod 或節點大小，垂直擴充工作負載和基礎架構。

GKE 會使用下列功能處理這些自動調度資源情境：

• 水平 Pod 自動調度資源 (HPA)：根據使用率指標新增及移除 Pod。
• 垂直 Pod 自動調度資源 (VPA)，用於調整 Pod 大小。
• 叢集自動配置器：根據排定的工作負載新增及移除節點。
• 節點自動佈建：動態建立新的節點集區，其中的節點符合使用者 Pod 的需求。

下圖說明這些情境。

本節的其餘部分會更詳細地討論這些 GKE 自動調度功能，並介紹適用於服務和批次工作負載的其他實用成本最佳化設定。

水平 Pod 自動配置器

水平 Pod 自動調度資源 (HPA) 的用途是根據表示負載的指標，調度在 Pod 中執行的應用程式。您可以設定 CPU 使用率或其他自訂指標 (例如每秒要求數)。簡而言之，HPA 會新增及刪除 Pod 副本，最適合用於無狀態工作站，這類工作站可快速啟動以因應用量暴增的情況，並正常關閉以避免工作負載不穩定。

如上圖所示，HPA 需要以百分比表示的目標使用率門檻，讓您自訂何時自動觸發調度。在本範例中，目標 CPU 使用率為 70%。也就是說，在啟動新副本時，工作負載有 30% 的 CPU 緩衝區可處理要求。緩衝區太小會導致提早擴充，但尖峰時段可能會造成應用程式過載。不過，緩衝區過大會造成資源浪費，導致費用增加。確切目標取決於應用程式，您必須考量緩衝區大小，確保緩衝區足以處理尖峰時段兩到三分鐘內的要求。即使您保證應用程式可以在幾秒內啟動，但當叢集自動配置器將新節點新增至叢集，或 Pod 因資源不足而受到節流時，仍需要這段額外時間。

以下是在應用程式中啟用 HPA 的最佳做法：

• 請設定適當的資源要求和限制，確保應用程式大小正確。
• 設定目標使用率，預留緩衝區，以便在尖峰時段處理要求。
• 請確保應用程式盡快啟動，並按照 Kubernetes 的預期方式關閉。
• 設定有意義的就緒和存活探測。
• 請確保指標伺服器一律處於運作狀態。
• 請告知應用程式的用戶，他們必須考慮實作指數重試，以處理暫時性問題。

詳情請參閱「設定水平 Pod 自動配置器」。

垂直 Pod 自動配置器

與 HPA 不同，HPA 會新增及刪除 Pod 副本，以快速因應用量尖峰，而垂直 Pod 自動調度器 (VPA) 則會長期觀察 Pod，逐步找出 Pod 需要的最佳 CPU 和記憶體資源。設定合適的資源對穩定性和成本效益至關重要。如果 Pod 資源太小，應用程式可能會受到節流，或因記憶體不足錯誤而失敗。如果資源過大，就會造成浪費，因此帳單金額也會較高。VPA 適用於 HPA 無法處理的無狀態和有狀態工作負載，或您不知道適當的 Pod 資源要求時。

如上圖所示，VPA 偵測到 Pod 持續以資源上限執行，因此會重新建立 Pod 並增加資源。如果 Pod 持續未充分運用，系統也會觸發縮減作業。

VPA 可在三種不同模式下運作：

• 關閉。在這個模式 (又稱建議模式) 下，垂直 Pod 自動配置器不會對 Pod 進行任何變更。系統會計算建議，並在 VPA 物件中檢查。
• 初始：垂直 Pod 自動配置器只會在建立 Pod 時指派資源要求，之後不會變更。
• Auto：VPA 會在 Pod 的生命週期內更新 CPU 和記憶體要求。也就是說，系統會刪除 Pod、調整 CPU 和記憶體，然後啟動新的 Pod。

如果您打算使用 VPA，最佳做法是先以「關閉」模式提取 VPA 建議。請務必先讓廣告活動放送 24 小時，最好是至少一週，再提取最佳化建議。然後，只有在您有信心時，才考慮切換至「初始」或「自動」模式。

在應用程式中啟用 VPA 時，請遵循下列最佳做法，無論是初始或自動模式都適用：

• 如需處理流量突然暴增的情況，請勿使用 VPA 的「初始」或「自動」模式。請改用 HPA。
• 請確認您的應用程式可以垂直擴展。
• 在 VPA 物件中設定容器大小下限和上限，避免自動配置器在應用程式未收到流量時大幅變更。
• 請勿突然進行變更，例如一次將 Pod 的副本數從 30 個降至 5 個。這類變更需要新的部署作業、新的標籤集和新的 VPA 物件。
• 請確保應用程式盡快啟動，並按照 Kubernetes 的預期方式關閉。
• 設定有意義的 readiness 和 liveness 探測。
• 請確保指標伺服器一律處於運作狀態。
• 請告知應用程式的用戶，他們必須考慮實作指數重試，以處理暫時性問題。
• 建議搭配使用節點自動佈建功能和 VPA，這樣一來，如果 Pod 變大到足以容納現有機型，叢集自動調度器就會佈建較大的機器，以容納新的 Pod。

無論您是否考慮使用「自動」模式，請務必遵循下列做法：

• 請確認應用程式在接收流量時可以重新啟動。
• 新增 Pod 中斷預算 (PDB)，控管可同時關閉的 Pod 數量。

詳情請參閱「設定垂直 Pod 自動調度資源」。

混合使用 HPA 和 VPA

官方建議是不要在 CPU 或記憶體上混用 VPA 和 HPA。不過，在 VPA 中使用建議模式，或在 HPA 中使用自訂指標 (例如每秒要求數) 時，可以安全地混合使用這兩者。混合使用 VPA 和 HPA 時，請確保部署作業獲得足夠流量，也就是持續高於 HPA 最少副本數。這可讓 VPA 瞭解 Pod 的資源需求。

如要進一步瞭解 VPA 限制，請參閱「垂直 Pod 自動調度資源的限制」。

叢集自動配置器

叢集自動配置器 (CA) 會自動調整基礎運算基礎架構的大小。如果叢集中沒有可供 Pod 執行的位置，CA 會提供節點，並移除使用率偏低的節點。CA 經過最佳化調整，可降低基礎架構成本。換句話說，如果叢集中有兩種以上的節點類型，CA 會選擇最便宜的類型來滿足需求。

與 HPA 和 VPA 不同，CA 不會依據負載指標。而是根據排程模擬和宣告的 Pod 要求。使用 HPA 或 VPA 時，最佳做法是啟用 CA。這麼做可確保 Pod 自動調度器判斷需要更多容量時，基礎架構會隨之擴充。

如這些圖表所示，CA 會自動增減運算能力，以處理流量尖峰，並在客戶睡覺時為您省錢。建議您為所有應用程式定義 Pod 中斷預算 (PDB)。在 CA 縮減階段，PDB 會控管一次可關閉的副本數量，因此這項設定特別重要。

如果某些 Pod 導致暫時中斷，任何自動配置器都無法重新啟動這些 Pod，因此無法刪除這些 Pod 執行的節點。舉例來說，系統 Pod (例如 metrics-server 和 kube-dns) 和使用本機儲存空間的 Pod 不會重新啟動。不過，您可以定義這些系統 Pod 的 PDB，並為使用本機儲存空間的 Pod 設定 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 註解，讓自動配置器安全地重新啟動 Pod，藉此變更這項行為。此外，建議您在獨立的節點集區上執行無法重新啟動的長期 Pod，以免這些 Pod 阻礙其他節點縮減。最後，請參閱這篇文章，瞭解如何分析記錄中的 CA 事件，找出特定擴充活動未如預期執行的原因。

如果您的工作負載可承受節點意外重新啟動和容量損失，則建立含有 Spot VM 的叢集或節點集區，即可節省更多費用。為確保 CA 正常運作，Pod 資源要求必須夠大，Pod 才能正常運作。如果資源要求太小，節點可能沒有足夠的資源，Pod 可能會在執行階段當機或發生問題。

以下是在叢集中啟用叢集自動配置器的最佳做法摘要：

• 使用 HPA 或 VPA 自動調度工作負載。
• 請務必遵循所選 Pod 自動調度器中說明的最佳做法。
• 設定適當的資源要求和限制，或使用 VPA，正確調整應用程式大小。
• 為應用程式定義 PDB。
• 為可能阻礙縮減作業的系統 Pod 定義 PDB。例如 kube-dns。為避免叢集暫時中斷服務，請勿為只有 1 個副本的系統 Pod (例如 metrics-server) 設定 PDB。
• 在不同的節點集區中執行生命週期較短的 Pod 和可重新啟動的 Pod，以免生命週期較長的 Pod 阻礙縮減作業。
• 在叢集中設定閒置節點，避免過度佈建。為此，您必須瞭解最低容量 (許多公司都是在夜間)，並在節點集區中設定最低節點數，以支援該容量。
• 如需額外容量來處理尖峰時段的要求，請使用暫停 Pod，詳情請參閱「自動調度器和超額佈建」。

詳情請參閱自動調度叢集。

節點自動佈建

節點自動佈建 (NAP) 是叢集自動配置器的一項機制，除了代表使用者管理節點集區大小，還會自動新增節點集區。如果未啟用節點自動佈建功能，GKE 只會從使用者建立的節點集區組合中啟動新的節點。啟用節點自動佈建功能後，GKE 就能自動建立及刪除新的節點集區。

節點自動佈建功能會動態建立最適合排定工作負載的節點集區，因此有助於減少資源浪費。不過，如果需要建立新的節點集區，自動調整規模的延遲時間可能會稍微偏高。如果工作負載可承受節點意外重新啟動和容量損失，您可以在 Pod 中設定 Spot VM 容許度，進一步降低費用。

啟用節點自動佈建功能的最佳做法如下：

• 遵循叢集自動配置器的所有最佳做法。
• 設定資源大小下限和上限，避免應用程式未收到流量時，NAP 對叢集做出重大變更。
• 使用水平 Pod 自動調度器處理工作負載時，請考慮預留稍大的目標使用率緩衝區，因為在某些情況下，NAP 可能會增加自動調度延遲。

詳情請參閱使用節點自動佈建功能和不支援的功能。

自動調度程式和過度佈建

為控管費用，我們強烈建議您根據前幾節的內容啟用自動調整功能。沒有任何單一設定能適用於所有可能情境，因此您必須微調工作負載的設定，確保自動調度程式能正確回應流量增加的情況。

不過，如「水平自動調度 Pod 資源」一節所述，由於基礎架構佈建作業需要時間，因此擴充作業可能需要一段時間。如要以視覺化方式呈現時間差異和可能的擴充情境，請參考下圖。

當叢集有足夠空間可部署新 Pod 時，系統會觸發其中一個工作負載擴充情境。也就是說，如果現有節點從未部署應用程式，就必須先下載容器映像檔，才能啟動 Pod (情境 1)。不過，如果同一節點必須啟動應用程式的新 Pod 副本，由於不需要下載映像檔 (情境 2)，因此總擴充時間會縮短。

如果叢集沒有足夠空間部署新 Pod，系統會觸發其中一個基礎架構和工作負載擴充情境。也就是說，叢集自動配置器必須佈建新節點並啟動必要軟體，才能接近應用程式 (情境 1)。如果您使用節點自動佈建功能，可能需要視排定的工作負載而定，建立新的節點集區。在這種情況下，叢集自動配置器必須佈建節點和節點集區 (情境 2)，因此總擴充時間會增加。

如果需要新基礎架構，請勿過度壓縮叢集，也就是必須超量佈建，但僅限於保留必要緩衝區，以處理擴充期間預期的尖峰要求。

這類過度佈建主要有兩種策略：

• 微調 HPA 使用率目標。以下方程式是找出合適 CPU 目標的簡單安全方法：

  (1 - buff)/(1 + perc)

  • buff 是安全緩衝區，可避免 CPU 使用率達到 100%。這項變數很有用，因為 CPU 達到 100% 時，表示要求處理的延遲時間遠高於平常。
  • perc 是指您預期在兩到三分鐘內流量的成長百分比。

  舉例來說，如果您預期要求會成長 30%，並想定義 10% 的安全緩衝區，避免 CPU 達到 100%，公式會如下所示：

  (1 - 0.1)/(1 + 0.3) = 0.69

• 設定暫停 Pod。您無法設定叢集自動調度器，預先啟動節點。您可以改為設定 HPA 使用率目標，提供緩衝區來處理負載尖峰。不過，如果預期會出現大量爆發流量，設定較小的 HPA 使用率目標可能不夠，或會變得太過昂貴。

  這個問題的替代解決方案是暫停 Pod。暫停 Pod 是低優先順序的 Deployment，除了在叢集中保留空間外，不會執行任何操作。每當排定高優先順序的 Pod 時，系統會撤銷暫停 Pod，並立即由高優先順序的 Pod 取代。接著，系統會重新排定遭驅逐的暫停 Pod，如果叢集沒有空間，叢集自動調度器會啟動新節點來容納這些 Pod。最佳做法是每個節點只保留一個暫停 Pod。舉例來說，如果您使用 4 個 CPU 節點，請將暫停 Pod 的 CPU 要求設為約 3200m。

選擇合適的機器類型

除了自動調度資源外，您也可以透過其他設定，在 GKE 上執行最具成本效益的 Kubernetes 應用程式。本節將說明如何選擇合適的機型。

Spot VM

Spot VM 是 Compute Engine VM 執行個體，不提供可用性保證。Spot VM 的價格最多可比標準 Compute Engine VM 便宜 91%，但我們建議您在 GKE 叢集上使用時務必謹慎。GKE 的 Spot VM 最適合執行批次或容錯工作，這類工作比較不會受到 Spot VM 的暫時性和無保證性質影響。有狀態和服務工作負載不得使用 Spot VM，除非您已準備好系統和架構，可處理 Spot VM 的限制。

無論工作負載類型為何，都必須注意下列限制：

• Spot VM 可能會意外關閉，因此系統可能不會遵守 Pod 中斷預算。
• 節點先占忽略 Pod 寬限期後，我們無法保證 Pod 會正常關閉。
• GKE 可能需要幾分鐘的時間才能偵測到節點遭到先占及 Pod 已停止執行，因此會延遲 Pod 重新安排至新節點的作業。

從 GKE v1.20 開始，系統會預設啟用節點正常關機功能，向執行中的工作負載發出通知。

Spot VM 不保證可用性，因此在某些區域可能很容易缺貨。為解決這項限制，建議您設定不含 Spot VM 的備用節點集區。叢集自動調度器會優先使用 Spot VM，因為這項工具已針對基礎架構成本進行最佳化。

詳情請參閱「使用 Spot VM 以較低的費用執行容錯工作負載」、「使用 Spot Pod 以較低的費用執行容錯工作負載」和「使用成本效益最高的 Spot VM 在 GKE 上執行網頁應用程式」。

E2 機器類型

E2 機型 (E2 VM) 是經過成本最佳化的 VM，與 N1 機型相比，可節省 31% 的費用。E2 VM 適用於各種工作負載，包括網路伺服器、微服務、重要業務應用程式、中小型資料庫和開發環境。

如要進一步瞭解 E2 VM，以及與其他Google Cloud 機器類型的比較，請參閱「E2 VM 中以效能為導向的動態資源管理」和「機器類型」。

選取適當的區域

如果費用是限制條件，那麼執行 GKE 叢集的地區就很重要。由於多種因素，每個運算區域的費用有所不同。因此，請務必以最便宜的選項執行工作負載，但延遲時間不得影響客戶。如果工作負載需要將資料從一個區域複製到另一個區域 (例如執行批次工作)，您也必須考量遷移這類資料的費用。

如要進一步瞭解如何選擇合適的地區，請參閱「選擇 Compute Engine 地區的最佳做法」。

申請承諾使用折扣

如果您打算使用 Google Cloud 幾年，強烈建議您購買承諾使用折扣，以更優惠的費率使用 VM。簽署承諾使用合約後，您承諾在未來一年或三年會支付這些資源的費用，因此可以用折扣價格購買運算資源 (最多可享 3 折優惠)。如果不確定要承諾多少資源，請查看最低運算用量 (例如夜間)，並承諾支付該金額。

如要進一步瞭解不同機器類型的承諾使用價格，請參閱「VM 執行個體定價」一文。

查看小型開發叢集

對於需要盡量降低成本的小型開發叢集，建議使用 Autopilot 叢集。採用這種運作模式的叢集不會收取系統 Pod、作業系統成本或未排定工作負載的費用。

檢查記錄和監控策略

如果您使用 Cloud Logging 和 Cloud Monitoring 監控應用程式和基礎架構，則只需支付實際用量費用。不過，基礎架構和應用程式記錄的內容越多，保留這些記錄的時間越長，您支付的費用就越高。同樣地，外部和自訂指標越多，費用就越高。

查看區域和多區域叢集中的跨區域輸出流量

GKE 提供單一可用區、多可用區和區域叢集。由於節點在各可用區之間具有高可用性，區域和多區域叢集非常適合用於正式環境。不過，系統會針對可用區之間的輸出流量向您收費。如果是實際工作環境，建議您監控各區域的流量負載，並改善 API，盡量減少負載。此外，也請考慮使用Pod 間的相依性和反相依性設定，將不同服務中相依的 Pod 共置於相同節點或相同可用區，盡量降低兩者之間的費用和網路延遲時間。建議啟用 GKE 用量計算功能和網路輸出代理程式 (預設為停用)，監控這類流量。

對於非正式環境，節省費用的最佳做法是部署單一可用區叢集。

準備適合工作負載類型的環境

企業對成本和供應情形有不同的要求。他們的工作負載可分為服務工作負載 (必須快速回應爆量或尖峰流量) 和批次工作負載 (著重於最終完成的工作)。放送工作負載需要較短的擴充延遲時間，批次工作負載則對延遲時間的容忍度較高。這些工作負載類型的期望不同，因此選擇不同的節省成本方法時，彈性也較大。

批次工作負載

由於批次工作負載著重於最終工作，因此可節省 GKE 成本，因為工作負載通常可容許工作啟動時的某些延遲。這項容許值可讓叢集自動調度資源在工作排定時啟動新節點，並在工作完成時關閉節點。

第一個建議做法是使用標籤和選取器，以及污點和容許度，將批次工作負載區隔到不同的節點集區。理由如下：

• 叢集自動配置器不需要重新啟動 Pod 時，可以更快刪除空白節點。批次工作完成後，如果工作負載是在專屬節點上執行，且這些節點現在已清空，叢集就會加快縮減程序。如要進一步提升縮減速度，請考慮設定 CA 的最佳化使用率設定檔。
• 部分 Pod 無法重新啟動，因此會永久封鎖節點的縮減作業。這些 Pod (包括系統 Pod) 必須在不同的節點集區上執行，以免影響縮減作業。

第二項建議做法是使用節點自動佈建功能，自動為具有相符汙點或容許度的作業建立專屬節點集區。這樣一來，您就能區隔許多不同的工作負載，不必設定所有不同的節點集區。

如果執行容錯工作，且工作較不容易受到 Spot VM 的暫時性和無保證性質影響，我們才建議使用 Spot VM。

提供工作負載

與批次工作負載不同，服務工作負載必須盡快回應爆量或尖峰流量。流量突然增加的原因有很多，例如電視廣告、黑色星期五等大型活動，或是突發新聞。您的應用程式必須準備好處理這些情況。

處理這類尖峰流量時發生問題，通常與下列一或多項原因有關：

• 應用程式尚未準備好在 Kubernetes 上執行，例如映像檔大小過大、啟動時間過長，或 Kubernetes 設定不夠完善。
• 應用程式依賴需要一段時間才能佈建的基礎架構，例如 GPU。
• 自動調度器和過度佈建設定不當。

準備雲端 Kubernetes 應用程式

本節中的部分最佳做法本身就能省錢。不過，這些做法大多是為了確保應用程式能與自動調整程式穩定運作，因此強烈建議您採用。

瞭解應用程式容量

規劃應用程式容量時，請瞭解應用程式可處理多少並行要求、需要多少 CPU 和記憶體，以及應用程式在大量負載下的回應方式。大多數團隊都不知道這些容量，因此建議您測試應用程式在壓力下的行為。請嘗試在自動調度功能關閉的情況下，隔離單一應用程式 Pod 副本，然後執行測試，模擬實際使用負載。這有助於瞭解每個 Pod 的容量。 接著，建議您設定叢集自動調度器、資源要求和限制，以及水平 Pod 自動調度器或垂直 Pod 自動調度器。然後再次對應用程式進行壓力測試，但這次要提高強度，模擬流量突然激增或達到尖峰的情況。

為消除延遲問題，這些測試最好在應用程式執行的相同區域或地帶執行 Google Cloud。您可以選擇使用任何工具進行這些測試，無論是自製指令碼或 Apache Benchmark、JMeter 或 Locust 等進階效能工具，都沒問題。

如需如何執行測試的範例，請參閱使用 Google Kubernetes Engine 進行分散式負載測試。

確保應用程式可垂直和水平成長

確保應用程式可以放大和縮小。也就是說，您可以選擇增加 CPU 和記憶體，或增加更多 Pod 副本，以處理流量增加的情況。您可以彈性地實驗哪種設定最適合應用程式，例如不同的自動調整規模設定或節點大小。很遺憾，部分應用程式是單一執行緒，或受限於固定數量的工作人員或子程序，因此必須徹底重構架構，才能進行這項實驗。

設定適當的資源要求和限制

瞭解應用程式容量後，您就能判斷要在容器資源中設定哪些項目。Kubernetes 中的資源主要定義為 CPU 和記憶體 (RAM)。您可以使用要求 spec.containers[].resources.requests.<cpu|memory>，將 CPU 或記憶體設定為執行應用程式所需的數量，並使用要求 spec.containers[].resources.limits.<cpu|memory> 設定上限。如要進一步瞭解如何設定資源要求，請參閱「手動設定 Pod 資源要求」。

正確設定資源要求後，Kubernetes 排程器就能使用這些要求，決定要將 Pod 放置在哪個節點上。這可確保 Pod 放置在能正常運作的節點中，進而提升穩定性並減少資源浪費。此外，定義資源限制有助於確保這些應用程式絕不會使用運算節點提供的所有可用基礎架構。

設定容器資源要求和限制時，請採用下列最佳做法：

• 記憶體：將要求和限制設為相同的記憶體量。
• CPU：根據您自己的 SLO，為要求指定確保正確運作所需的最低 CPU。設定無上限的 CPU 限制。

以下列部署作業為例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

上述模式的理由是根據 Kubernetes 資源不足處理機制的運作方式。簡單來說，電腦資源耗盡時，節點就會變得不穩定。為避免這種情況，kubelet 會對耗用大量資源的 Pod 進行排序，監控並防止這些資源完全匱乏。CPU 發生爭用時，這些 Pod 的 CPU 使用量可能會受到節流，降至要求值。不過，由於記憶體是不可壓縮的資源，因此記憶體用盡時，Pod 就必須關閉。為避免 Pod 遭到終止 (進而導致環境不穩定)，您必須將要求的記憶體設為記憶體限制。您可以查看 REQUEST_OR_LIMIT_NOT_SET 子類型的洞察資料，找出未為容器設定資源要求或限制的工作負載。詳情請參閱「找出沒有資源要求或限制的工作負載」。

您也可以在建議模式中使用 VPA，協助判斷特定應用程式的 CPU 和記憶體用量。詳情請參閱「分析資源要求」。

由於 VPA 會根據應用程式用量提供這類建議，因此建議您在類似實際工作環境的環境中，以建議模式使用 VPA，以因應實際流量。VPA 狀態接著會產生一份報表，其中包含建議的資源要求和限制，您可以在部署資訊清單中靜態指定這些項目。如果應用程式已定義 HPA，請參閱「混合使用 HPA 和 VPA」。

確保容器盡可能精簡

在 Kubernetes 上執行容器時，應用程式隨時可能啟動和停止。因此，請務必遵循下列最佳做法：

• 盡可能縮小圖片。建議使用小型映像檔，因為每當叢集自動配置器為叢集佈建新節點時，節點都必須下載要在該節點中執行的映像檔。映像檔越小，節點下載速度就越快。

• 盡快啟動應用程式。有些應用程式可能需要幾分鐘才能啟動，因為要載入類別、快取等。如果 Pod 需要長時間啟動，應用程式啟動時，客戶的要求可能會失敗。

設計系統時，請考慮採用這兩項做法，特別是預期會出現爆量或尖峰流量時。縮小映像檔並加快啟動速度，有助於減少擴充延遲。因此，您能更妥善地處理流量增加的情況，不必過於擔心不穩定性。這些做法與 GKE 自動調度資源中討論的自動調度資源最佳做法搭配使用，效果更佳。

將 Pod 中斷預算新增至應用程式

Pod 中斷預算 (PDB) 會限制可因自願中斷而同時關閉的 Pod 數量。也就是說，在推出、節點升級和任何自動調度活動時，系統都會遵守定義的干擾預算。不過，如果發生非自願事件 (例如硬體故障、核心恐慌或有人誤刪 VM)，就無法保證預算。

在叢集自動配置器的壓縮階段，如果系統會遵守 PDB，建議您為每個應用程式定義 Pod 中斷預算。這樣一來，您就能控管支援負載所需的最低副本數，包括 CA 調降叢集資源配置時。

詳情請參閱「為應用程式指定中斷預算」。

為應用程式設定有意義的完備性與活躍性探測結果

設定有意義的探測，確保應用程式只會在正常運作且準備好接受流量時接收流量。GKE 會使用完備性探測，判斷何時要在負載平衡器中新增或移除 Pod。GKE 會使用存活探測來判斷何時要重新啟動 Pod。

有效性探測可讓 Kubernetes 瞭解特定 Pod 無法繼續運作，例如偵測到死結狀態時。就緒探測器可讓 Kubernetes 瞭解應用程式尚未準備好接收流量，例如在啟動時載入大型快取資料。

為確保應用程式在擴充活動期間的生命週期正確無誤，請務必採取下列做法：

• 為所有容器定義就緒探測器。
• 如果應用程式必須在啟動時載入快取，readiness 探測就必須在快取完全載入後，才表示已就緒。
• 如果應用程式可以立即開始提供服務，良好的預設探查實作方式可以盡可能簡單，例如傳回 200 狀態碼的 HTTP 端點。
• 如果您實作更進階的探查，例如檢查連線集區是否有可用資源，請確保錯誤率不會增加，與較簡單的實作方式相比。
• 探查邏輯絕不能存取其他服務。如果這些服務無法及時回應，可能會影響 Pod 的生命週期。

詳情請參閱「設定執行中、就緒和啟動探測器」。

確認應用程式是否按照 Kubernetes 的預期方式關閉

自動調度器可協助您啟動新的 Pod 和節點，因應用量尖峰，並在尖峰結束時刪除這些 Pod 和節點。也就是說，為避免在放送期間發生錯誤，Pod 必須準備好快速啟動或正常關閉。

由於 Kubernetes 會非同步更新端點和負載平衡器，請務必遵循下列最佳做法，確保關機程序不會中斷：

• 請勿在 SIGTERM 後立即停止接受新要求。應用程式不得立即停止，而是必須完成所有進行中的要求，並繼續監聽 Pod 終止後傳入的連線。Kubernetes 可能需要一段時間，才能更新所有 kube-proxy 和負載平衡器。如果應用程式在更新這些項目之前終止，部分要求可能會導致用戶端發生錯誤。
• 如果您的應用程式未遵循上述做法，請使用 preStop hook。 大多數計畫不會立即停止接受要求。不過，如果您使用第三方程式碼，或是管理您無法控制的系統 (例如 nginx)，preStop hook 是觸發正常關機的好選擇，不必修改應用程式。常見的策略是在 preStop hook 中執行幾秒的休眠，以延後 SIGTERM。這可讓 Kubernetes 有更多時間完成 Pod 刪除程序，並減少用戶端連線錯誤。
• 處理 SIGTERM 以進行清理。如果應用程式必須清除或有必須在程序終止前保存的記憶體內狀態，現在就是執行這項操作的時機。不同的程式設計語言有不同的方式來擷取這項信號，因此請找出適合您所用語言的方法。
• 設定 terminationGracePeriodSeconds 以符合應用程式需求。部分應用程式需要超過預設的 30 秒才能完成。在這種情況下，你必須指定 terminationGracePeriodSeconds。舉例來說，高值可能會增加節點升級或推出時間。如果值太低，Kubernetes 可能沒有足夠時間完成 Pod 終止程序。無論採用哪種方式，我們都建議您將應用程式的終止期設為 10 分鐘以下，因為叢集自動調度器只會遵守 10 分鐘的終止期。
• 如果應用程式使用容器原生負載平衡，請在收到 SIGTERM 時開始讓準備狀態探測失敗。這項動作會直接向負載平衡器發出信號，要求停止將新要求轉送至後端 Pod。視健康狀態檢查設定和端點程式設計之間的競爭情況而定，後端 Pod 可能會提早從流量中移除。

詳情請參閱「Kubernetes 最佳做法：安全終止」。

設定 NodeLocal DNSCache

GKE 代管的 DNS 是由 kube-dns 實作，這是部署在所有 GKE 叢集中的外掛程式。執行需要大量 DNS 查詢的應用程式時，預設的 kube-dns-autoscaler 設定 (根據叢集中的節點和核心數量調整 kube-dns 副本數量) 可能不夠。在這種情況下，DNS 查詢可能會變慢或逾時。為解決這個問題，企業通常會調整 kube-dns-autoscaler ConfigMap，增加叢集中的 kube-dns 副本數量。雖然這項策略可能如預期運作，但會增加資源用量和 GKE 總成本。

另一個可節省成本且更具擴充性的替代方案，是在叢集中設定 NodeLocal DNSCache。NodeLocal DNSCache 是選用的 GKE 外掛程式，可縮短 DNS 查詢延遲時間、讓 DNS 查詢時間更加一致，並在每個叢集節點上執行 DNS 快取，減少對 kube-dns 的 DNS 查詢次數。

詳情請參閱「設定 NodeLocal DNSCache」。

透過 Ingress 使用容器原生負載平衡功能

容器原生負載平衡可讓負載平衡器直接指定 Kubernetes Pod，並使用稱為網路端點群組 (NEG) 的資料模型，將流量平均分配給 Pod。這種做法可提升網路效能、增加可見度、啟用進階負載平衡功能，並使用 Cloud Service Mesh，這是Google Cloud針對服務網格推出的全代管流量控制層。

基於上述優點，建議您透過 Ingress 使用容器原生負載平衡功能。 將 NEG 與 GKE Ingress 搭配使用時，Ingress 控制器會協助建立 L7 負載平衡器的所有層面。包括建立虛擬 IP 位址、轉送規則、健康狀態檢查、防火牆規則等。

使用叢集自動調度器時，容器原生負載平衡就更顯重要。對於非 NEG 負載平衡器，在縮減期間，叢集自動調整功能終止節點執行個體前，負載平衡程式設計和連線排除作業可能無法完全完成。即使後端 Pod 不在節點上，這也可能會中斷透過節點進行的連線。

如果符合下列所有條件，系統會預設為 Service 啟用容器原生負載平衡：

• 服務是在 GKE 叢集 1.17.6-gke.7 以上版本中建立。
• 如果您使用虛擬私有雲原生叢集。
• 如果未使用共用虛擬私有雲。
• 如果您未使用 GKE 網路政策。

詳情請參閱 Ingress GKE 說明文件和「使用容器原生負載平衡」。

考慮使用指數輪詢重試

在 Kubernetes 上執行的微服務架構中，暫時性故障可能會因各種原因而發生，例如：

• 觸發仍在運作的擴充作業的大量尖峰
• 網路發生問題
• Pod 未關閉，導致連線中斷
• Spot VM 意外關機
• 達到評分限制的應用程式

這些問題是暫時性的，延遲後再次呼叫服務即可解決。不過，為避免請求過多而導致目的地服務不堪負荷，請務必使用指數輪詢執行這些呼叫。

為方便使用這類重試模式，許多現有程式庫都實作了指數重試邏輯。你可以使用所選程式庫或自行編寫程式碼。如果您使用 Istio 或 Cloud Service Mesh (ASM)，可以選擇 Proxy 層級的重試機制，系統會代表您透明地執行重試作業。

請務必規劃應用程式支援服務呼叫重試，例如避免插入已插入的資訊。請注意，一連串的重試可能會影響最終使用者的延遲，如果規劃不當，可能會導致逾時。

監控環境，並強制執行具備最佳成本效益的設定和做法

在許多中大型企業中，集中式平台和基礎架構團隊通常負責為整間公司建立、維護及監控 Kubernetes 叢集。這代表您非常需要資源使用情況的問責制，並確保所有團隊都遵守公司政策。本節說明如何監控及強制執行與費用相關的做法。

監控 GKE 叢集並查看建議

您可以檢查容器、Pod 和服務，以及整體叢集的特性，瞭解 Kubernetes 叢集的資源用量。執行這項工作的方法有很多，但我們建議的初始做法是透過監控資訊主頁觀察 GKE 叢集。這項功能會提供叢集使用情況的時間序列資料，方便您從基礎架構、工作負載和服務匯總及跨越資料。

雖然這是個好的起點，但 Google Cloud 也提供其他選項，例如：

• 在 Google Cloud 控制台的「GKE Clusters」(GKE 叢集) 頁面中，查看「Notifications」(通知) 欄。如果叢集中的資源浪費率偏高，使用者介面會提示您整體分配與要求資訊。

  前往 GKE 叢集清單

• 在 Google Cloud 控制台的「最佳化建議」頁面中，尋找「節省費用」建議資訊卡。

  前往建議中心

詳情請參閱「觀察 GKE 叢集」和「開始使用建議中心」。

啟用 GKE 用量計算功能

如要採用更彈性的做法，查看約略的費用明細，請試用 GKE 用量計算功能。有了 GKE 用量計算功能，您就能依據命名空間和標籤查看詳細的 GKE 叢集用量資料。這項功能會追蹤叢集工作負載的資源要求和資源耗用量相關資訊，例如 CPU、GPU、TPU、記憶體、儲存空間，以及網路輸出 (選用)。

GKE 用量計算功能可協助您瞭解 GKE 叢集的整體費用結構、哪個團隊或應用程式的支出最多、哪個環境或元件導致用量或費用突然暴增，以及哪個團隊浪費資源。比較資源要求與實際用量，即可瞭解哪些工作負載的資源配置不足或過多。

您可以運用預設的 Looker Studio 範本，或進一步根據機構需求自訂資訊主頁。如要進一步瞭解 GKE 用量計算功能和相關必要條件，請參閱「瞭解叢集資源用量」。

瞭解指標伺服器的運作方式並加以監控

指標伺服器是 GKE 內建自動調度資源管道的容器資源指標來源。指標伺服器會從 kubelet 擷取指標，並透過 Kubernetes Metrics API 公開這些指標。接著，水平 Pod 自動配置器和垂直 Pod 自動配置器會使用這些指標，判斷何時觸發自動調度資源。

如要確保 GKE 自動調度資源的健康狀態，您必須擁有運作正常的指標伺服器。使用 GKE metrics-server 部署作業時，系統會安裝調整大小的 nanny，根據叢集的節點數量新增或移除 CPU 和記憶體，垂直擴充指標伺服器容器。Kubernetes 仍不支援 Pod 的就地更新，因此 Nanny 必須重新啟動 metrics-server Pod，才能套用新的必要資源。

雖然重新啟動的速度很快，但自動調度器在metrics-server調整大小後，可能需要較長的時間才能意識到必須採取行動，因此總延遲時間可能會稍微增加。為避免 Metrics Server 在快速變更的叢集中頻繁重新啟動，從 GKE 1.15.11-gke.9 開始，保母支援調整大小延遲。

使用指標伺服器時，請遵循下列最佳做法：

• 選擇支援metrics-server調整大小延遲的 GKE 版本。如要確認，請檢查部署 YAML 檔案的 metrics-server-nanny 容器中是否含有 scale-down-delay 設定。metrics-server
• 監控 metrics-server 部署作業。如果指標伺服器停止運作，表示自動調度資源功能完全無法運作。您希望優先監控服務監控這項部署作業。
• 遵循「GKE 自動調度資源」一文中的最佳做法。

使用 Kubernetes 資源配額

在多用戶群叢集中，不同團隊通常會負責在不同命名空間中部署的應用程式。對於集中式平台和基礎架構群組而言，一個團隊可能會使用超出必要的資源，如果耗盡所有叢集的運算資源，甚至觸發過多擴充作業，可能會增加費用。

如要解決這項疑慮，請務必使用資源配額。資源配額會管理命名空間中物件使用的資源量。您可以根據運算 (CPU 和記憶體) 和儲存空間資源或物件數量來設定配額。資源配額可確保用戶群使用的叢集資源不會超過指定的份額。

詳情請參閱「為命名空間設定記憶體和 CPU 配額」。

建議使用 GKE Enterprise Policy Controller

GKE Enterprise Policy Controller 是 Kubernetes 的動態許可控管服務，可按照安全、法規或任意商業規則的相關政策檢查、稽核叢集，並確保叢集確實遵循這些政策。Policy Controller 會使用限制，強制讓叢集符合政策。舉例來說，您可以在叢集中安裝限制，以套用「準備雲端 Kubernetes 應用程式」一節中討論的許多最佳做法。這樣一來，如果部署作業未嚴格遵守 Kubernetes 做法，就會遭到拒絕。強制執行這類規則有助於避免非預期成本暴增，並降低自動調度資源期間工作負載不穩定的機率。

如要進一步瞭解如何強制執行及編寫自己的規則，請參閱「建立限制」 和「編寫限制範本」。 如果您不是 GKE Enterprise 客戶，可以考慮使用 Gatekeeper，這是 Policy Controller 的建構基礎開放原始碼軟體。

設計 CI/CD 管道，強制執行節省成本的做法

GKE Enterprise Policy Controller 可協助您避免在 GKE 叢集中部署不符規定的軟體。不過，建議您在開發週期的早期階段強制執行這類政策限制，無論是在預先提交檢查、提取要求檢查、交付工作流程，或環境中任何有意義的步驟，都應如此。這項做法可讓您快速找出並修正設定錯誤，並透過建立防護措施，瞭解需要注意的事項。

此外，也建議在 CI/CD pipeline 中使用 kpt 函式，驗證 Kubernetes 設定檔是否遵守 GKE Enterprise Policy Controller 強制執行的限制，並估算資源用量或部署費用。這樣一來，系統偵測到費用相關問題時，您就能停止管道。或者，您也可以為增加副本數量的設定建立不同的部署核准程序。

詳情請參閱「在 CI 管道中使用 Policy Controller」，如需完整的交付平台範例，請參閱「使用 GKE Enterprise 打造現代化 CI/CD 管道」。

推廣節省成本的文化

許多機構會建立抽象化和平台，對您隱藏基礎架構的複雜性。如果公司要將服務從虛擬機器遷移至 Kubernetes，通常會採取這種做法。有時這些公司會允許開發人員在正式環境中設定自己的應用程式。不過，開發人員從未接觸過 Kubernetes 叢集的情況並不少見。

本節建議的做法並非要您完全停止進行抽象化，而是協助您查看Google Cloud 的支出，並訓練開發人員和營運人員使用基礎架構。您可以建立學習獎勵和計畫，並使用傳統或線上課程、討論群組、同儕審查、配對程式設計、持續整合/持續推送軟體更新，以及節省成本的遊戲化等方式，舉例來說，在 Kubernetes 世界中，瞭解 3 GB 映像檔應用程式、缺少的就緒探查或 HPA 設定錯誤的影響非常重要。

最後，如Google 的 DORA 研究所示，文化能力是提升機構績效、減少重工和倦怠等問題的主要因素。節省的費用不會有任何差異。讓員工查看支出，有助於他們更貼近業務目標和限制。

最佳做法摘要

下表總結了本文建議的最佳做法。

後續步驟

• 如要瞭解如何最佳化工作負載成本，請參閱 Google Cloud Google Cloud Well-Architected Framework：成本最佳化，取得設計建議和最佳做法。
• 如要瞭解如何在夜間或用量較低的時段節省費用，請參閱在離峰時段縮減 GKE 叢集規模以降低成本教學課程。
• 如要進一步瞭解如何使用 Spot VM，請參閱「在 GKE 上使用成本效益最高的 Spot VM 執行網頁應用程式」教學課程。
• 如要瞭解如何節省記錄和監控費用，請參閱「最佳化成本：雲端作業」。
• 如要 Google Cloud 一般情況下降低費用，請參閱「瞭解成本最佳化原則」。
• 如要進一步瞭解可擴充性，請參閱「可擴充及具有彈性的應用程式模式」。
• 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
• 進一步瞭解如何在 Spot VM 上執行 GKE 應用程式，並將隨選節點做為備援。