本頁面說明如何分析及最佳化資源分配，以便在 Google Kubernetes Engine (GKE) 中使用垂直 Pod 自動調度資源功能，提高工作負載效率。分析工作負載一段時間內的資源用量，即可取得最佳化建議，並自動調整 CPU 和記憶體要求，以及 Pod 內容器的限制。
本頁面說明垂直自動調度 Pod 資源功能的運作方式、優點和限制、使用最佳做法，以及 VerticalPodAutoscaler 自訂資源和相關類型的 API 參考資料。
本頁面適用於佈建及設定雲端資源、部署工作負載，以及管理應用程式資源調度的操作人員和開發人員。如要進一步瞭解常見角色，請參閱「常見的 GKE 使用者角色和工作」。
閱讀本頁面前，請先確認您熟悉 Kubernetes 中的資源要求和限制。
如需快速擴充資源，以因應資源用量突然增加的情況，請使用水平 Pod 自動配置器。
如要瞭解自動調度資源的最佳做法，請參閱「在 GKE 上執行最具成本效益的 Kubernetes 應用程式的最佳做法」。
使用垂直自動調度 Pod 資源功能的原因
垂直自動調度 Pod 資源有下列優點：
- 為工作負載設定適當的資源要求和限制，可提升穩定性和成本效益。如果 Pod 資源大小小於工作負載所需，應用程式可能會受到限制，或因記憶體不足錯誤而失敗。如果資源規模過大，就會造成浪費，帳單金額也會增加。
- Pod 只會使用所需資源，因此叢集節點的使用效率很高。
- Pod 會被安排到具有適當節點的資源上。
- 您不必執行耗時的基準化任務來決定 CPU 和記憶體要求的正確值。
- 自動配置器會隨著時間調整 CPU 和記憶體要求，您不必採取任何行動，因此可以減少維護時間。
- 垂直自動調度 Pod 資源功能最適合用於長時間執行的同質工作負載。
相較於開放原始碼 Kubernetes 自動配置器，GKE 垂直自動調度 Pod 資源功能具有下列優點：
- 決定建議目標時，會考量節點大小上限和資源配額。
- 通知叢集自動配置器調整叢集容量。
- 使用歷來資料，包括啟用 VerticalPodAutoscaler 前收集的指標。
- 以控制層程序的形式執行 VerticalPodAutoscaler Pod，而非在worker 節點上部署。
垂直自動調度 Pod 資源的運作方式
垂直自動調度 Pod 資源功能可讓您分析及設定 Pod 所需的 CPU 和記憶體資源。您不必為 Pod 中的容器設定最新的 CPU 要求和限制，以及記憶體要求和限制，而是可以設定垂直自動調度 Pod 資源，提供 CPU 和記憶體要求和限制的建議值，以便手動更新 Pod，或者設定垂直自動調度 Pod 資源，自動更新這些值。
Autopilot 叢集預設會啟用垂直自動調度 Pod 資源功能。
與 Kubernetes 開放原始碼 VerticalPodAutoscaler 的關係
GKE 垂直自動調度 Pod 資源功能是以開放原始碼 Kubernetes VerticalPodAutoscaler API 為基礎，但採用 GKE 專屬的獨立實作方式。GKE 實作項目旨在透過專屬建議工具進行資源調度，但會保留開放原始碼版本中定義的相同 VerticalPodAutoscaler API 種類和欄位。
詳情請參閱 Kubernetes 說明文件中有關垂直自動調度 Pod 資源的部分。
垂直自動調度 Pod 資源模式
您可以套用不同的更新模式，設定垂直自動調度 Pod 資源功能套用資源變更的方式。
Auto (Recreate) 模式
在 Recreate 模式下，如果需要變更 Pod 的資源要求，垂直自動調度 Pod 資源功能會淘汰 Pod。由於 Kubernetes 1.33 之前的版本有限制，因此必須執行淘汰作業，才能修改執行中 Pod 的資源要求。
如要限制 Pod 重新建立的數量，請使用 Pod disruption budget。為確保叢集能處理新的工作負載大小，請使用叢集自動配置器和自動佈建節點。
垂直自動調度 Pod 資源功能會在更新前通知叢集自動配置器，並在重新建立工作負載前，提供調整大小後的工作負載所需的資源，盡可能縮短中斷時間。
Initial模式
啟用 Initial 後，垂直自動調度 Pod 資源功能只會在建立 Pod 時指派資源要求，之後不會再變更。
InPlaceOrRecreate模式
InPlaceOrRecreate 模式會嘗試更新 Pod 資源，而不重新建立 Pod，藉此減少服務中斷。
如要使用 InPlaceOrRecreate 模式，請將 VerticalPodAutoscaler 物件中的 spec.updatePolicy.updateMode 欄位設為 "InPlaceOrRecreate"。這個模式會依據工作負載資訊清單中定義的 resizePolicy 欄位，判斷資源變更是否需要重新啟動。如未定義 resizePolicy 欄位，CPU 和記憶體會預設為 NotRequired，也就是嘗試就地更新。
如果容器因 OOM (記憶體不足) 事件而終止，InPlaceOrRecreate 模式中的垂直自動調度 Pod 資源功能會與 Auto 模式類似：從失敗中學習。當系統因當機而重新建立 Pod 時，垂直自動調度 Pod 資源功能會套用包含安全緩衝區的建議 (通常是額外 20% 的記憶體或 100 MB，以較大者為準)，防止 OOM 錯誤立即重複發生。
InPlaceOrRecreate 模式適用於 Kubernetes 1.34.0-gke.2201000 以上版本。
InPlaceOrRecreate模式的備用方案
如果垂直自動調度 Pod 資源功能判定無法就地更新，就會改用 Recreate 模式行為，也就是剔除並重新建立 Pod，以便套用變更。垂直自動調度 Pod 資源功能會改為重新建立 Pod 的常見情況包括：
- 節點容量不足：更新後的資源要求超出目前節點的可分配容量，且無法就地排定更新作業 (「不可行」或「延遲」狀態超過逾時時間)。
- QoS 類別變更：資源更新會變更 Pod 的服務品質 (QoS) 類別，例如從
Burstable變更為Guaranteed。 RestartContainer政策：針對垂直自動調度 Pod 資源功能嘗試變更的資源，Pod 的resizePolicy欄位設為RestartContainer。- 逾時：就地更新要求處於待處理狀態的時間過長。
Off模式
在 Off 模式下，垂直自動調度 Pod 資源功能不會自動對 Pod 套用任何變更。您仍可根據歷來用量，查看 CPU 和記憶體要求與限制的建議值，但系統不會為您套用這些建議。如有需要，您可以手動將建議值套用至 Pod。
CPU 啟動強化
CPU 啟動提升功能會在初始化期間暫時增加 CPU 要求，並在初始化完成後將要求調整回基準層級，藉此加快應用程式啟動速度，並提高成本效益。
如要進一步瞭解如何設定 CPU 啟動強化功能，請參閱「使用 CPU 啟動強化功能加快應用程式啟動速度」。
CPU 啟動提升功能的運作方式
CPU 啟動提升功能會根據容器的基準 CPU 要求，計算暫時增加的資源。啟動階段結束後，Pod 會回到這個基準要求層級。
提升功能會以倍數或固定數量增加這項基準要求。這項提高的要求會維持有效，直到 Pod 準備就緒，GKE 才會將 CPU 要求還原至基準層級。
瞭解提升生命週期
啟動加速程序包含三個階段：
- 准入階段：在 Pod 准入期間，VPA 准入 Webhook 會攔截要求，並在 GKE 排定 Pod 之前，插入提升的 CPU 值。
- 啟動階段：應用程式會使用暫時提高的 CPU 分配量進行初始化，避免初始化節流。
- 取消加速階段：Pod 達到
Ready狀態且durationSeconds期間結束後，VPA 會將 CPU 要求就地縮減至基準值。
選擇提升工作負載的更新模式
無論是否啟用 VPA 的持續資源管理功能，您都可以設定 CPU 啟動加速。VPA 的持續資源管理功能會在啟動階段結束後，自動調整 Pod 資源要求。如要選擇偏好設定，請在 VPA 物件中設定 updateMode 欄位。如要進一步瞭解 VPA 更新模式，請參閱「垂直自動調度 Pod 資源模式」。
updateMode: "Off"：VPA 只會管理 Pod 准入 (Pod 建立階段) 期間的初始提升，以及啟動後的後續縮減。不會修改容器的穩態資源要求。updateMode: "Auto"、"Recreate"或"InPlaceOrRecreate"：VPA 會管理啟動加速功能，並根據 Pod 的持續用量，自動調整 Pod 的資源要求。
CPU 提升資源分配的計算方式
GKE 會以下列方式計算暫時提高的 CPU 要求：
決定基本 CPU：基準 CPU 要求取決於 VPA
updateMode欄位：Auto、Recreate或InPlaceOrRecreate：基準 CPU 要求是 VPA 建議。如果沒有建議，GKE 會改用 Pod 規格中定義的 CPU 要求。Off：基準 CPU 要求是 Pod 規格中的要求值。
計算提升後的 CPU：計算方式取決於您在提升設定
type欄位中指定的計算方法：Factor：將乘數套用至基本 CPU 要求：提升後的 CPU = 基本 CPU ×
factorQuantity：在基本 CPU 要求中加入絕對 CPU 數量：提升後的 CPU = 基本 CPU +
quantity
最終 CPU 要求取決於叢集模式：
- Standard 叢集：最終 CPU 要求為提高後的 CPU 值。
- Autopilot 叢集：最終 CPU 要求為提升後的 CPU 值，上限為分配的 Pod 記憶體允許的最大 CPU。
瞭解 CPU 限制在提升期間的行為
GKE 處理 CPU 限制的方式取決於 containerResourcePolicy 中的 controlledValues 設定：
RequestsAndLimits(預設)：GKE 會提高 CPU 要求和限制，並維持原始比例，以保留容器的服務品質 (QoS) 類別。RequestsOnly：GKE 只會提高 CPU 要求。GKE 會將提升後的要求限制在任何定義的 CPU 限制之下，以維持 QoS。
Autopilot 叢集的注意事項
由於 GKE Autopilot 會強制執行特定的 CPU 與記憶體比率範圍和 Pod 大小下限，因此 GKE 會在 Pod 許可期間評估提升作業，確保符合規定。在下列情況下，系統可能會修改或忽略提升：
- Autopilot 最小值：如果提升後的要求低於 Autopilot 工作負載的 CPU 需求下限 (例如一般用途 Pod 為 50m)，GKE 就不會套用提升，而是強制執行標準最小值。
- 比率上限 (部分或略過提升)：如果提升後的 CPU 要求會超過必要的 CPU 與記憶體比率範圍，GKE 會將提升值限制在符合分配記憶體的最高值。如果原始 Pod 要求已使用允許的 CPU 與記憶體比例上限，GKE 會略過提升，避免調整記憶體大小。
- 向外擴充 ComputeClass：向外擴充 ComputeClass 嚴格執行 1:4 (CPU:記憶體) 的比率。如果嘗試提高水平擴展 Pod 的 CPU，但未增加記憶體，GKE 可能會忽略提升。
資源政策
您可以使用 ContainerResourcePolicy，自訂垂直自動調度 Pod 資源功能為特定容器產生建議的方式。這項政策可讓您設定限制，並控管要調整哪些資源。
下限和上限
您可以指定容器的資源值下限 (minAllowed) 和上限 (maxAllowed)。
minAllowed：垂直自動調度 Pod 資源功能不會建議低於這個限制的值。這項限制有助於確保達到基準效能，或符合應用程式特定需求。maxAllowed：垂直自動調度 Pod 資源功能不會建議高於這個限制的值。這項限制有助於控制成本，或防止單一容器耗用過多節點資源。
受控資源
根據預設，垂直自動調度 Pod 資源功能會計算 CPU 和記憶體的建議值。您可以使用 controlledResources 欄位，指定要自動調度資源的資源。舉例來說，您可以設定自動配置器，只提供記憶體建議，不變更 CPU 要求。
限制
- 如要搭配使用垂直自動調度 Pod 資源和水平自動調度 Pod 資源來調度 CPU 資源，請搭配使用 VPA 調整 HPA 大小 (預先發布版) 或多維度自動調度 Pod 資源。您也可以搭配使用垂直自動調度 Pod 資源和水平自動調度 Pod 資源，並依據自訂和外部指標進行調度。
- 垂直自動調度 Pod 資源功能不適用於 JVM 工作負載，因為無法完整掌握工作負載的實際記憶體用量。
- 在 GKE 1.35.1 版和更早版本中，Deployment 的垂直自動調度 Pod 資源預設設定為至少兩個副本，以便將 Pod 替換為修訂後的資源值。在 1.35.2 以上版本中，預設值為一個最低副本。在 1.22 以上版本中，您可以為 PodUpdatePolicy 欄位中的
minReplicas欄位指定值，藉此覆寫這項設定。 - 如果您使用垂直自動調度 Pod 資源的
InPlaceOrRecreate更新模式，且無法就地更新 (例如將 Pod 擴充至超出節點容量)，垂直自動調度 Pod 資源會剔除並重新建立 Pod，以套用建議。即使 Pod 的規格中設定了resizePolicy欄位，以避免重新建立，系統仍會驅逐並重新建立 Pod。Autopilot 大小調整要求會發生這種行為，包括套用最低資源和 CPU：記憶體比率限制時。 - 垂直自動調度 Pod 資源功能需要管理 Pod 的工作負載物件，例如 Deployment、StatefulSet、ReplicaSet 或 ReplicationController。您無法將垂直自動調度 Pod 資源功能與獨立 Pod 搭配使用，因為必須有工作負載控制器，才能管理 Pod 重新建立程序。
- 垂直自動調度 Pod 資源功能只會針對容器層級的資源要求和限制 (
spec.containers[].resources) 產生建議及套用更新，不支援 Pod 層級的資源規格 (spec.resources)。
最佳做法
- 限制
VerticalPodAutoscaler物件數量。為避免叢集更新中斷，每個叢集的VerticalPodAutoscaler物件數量應保持在 1,000 個以下。 - 垂直自動調度 Pod 資源功能最適合用於長時間執行的同質工作負載。
- 長時間執行：執行至少 24 小時的工作負載。垂直自動調度 Pod 資源功能需要大量歷來資料，才能產生高可信度的建議。在
Auto或Recreate模式下，更新通常會在 Pod 建立至少 24 小時後進行，有助於避免 Pod 頻繁重新啟動和流失。 - 同質：單一
VerticalPodAutoscaler物件指定的 Pod (例如 Deployment 中的所有副本) 應呈現類似的資源消耗模式。垂直 Pod 自動配置器會匯總所有指定 Pod 的用量資料，產生建議。如果副本的使用情形不一致，例如部分 Pod 閒置，其他 Pod 負載過重，垂直 Pod 自動配置器可能會提供建議，過度佈建閒置的 Pod，或佈建不足忙碌的 Pod。
- 長時間執行：執行至少 24 小時的工作負載。垂直自動調度 Pod 資源功能需要大量歷來資料，才能產生高可信度的建議。在
- 如果工作負載的需求會突然激增，請使用水平自動調度 Pod 資源功能。垂直自動調度 Pod 資源功能旨在穩定調整資源，不適用於突然、短暫的資源用量激增。如果工作負載的流量或 CPU/記憶體需求波動劇烈，請改用水平 Pod 自動配置器。
- 運用 OOM 保護機制。雖然垂直 Pod 自動配置器是被動的，但確實包含針對記憶體不足 (OOM) 事件的自動防護功能。如果 Pod
OOMKilled，垂直自動調度 Pod 資源功能會立即觀察事件，並將建議記憶體增加約 20% (或 100 MB，以較大者為準)，在重新建立 Pod 時提高穩定性。如要進一步瞭解 OOM 事件，請參閱「排解 OOM 事件」。
API 參考資料
這是 v1 API 參考資料。強烈建議使用這個版本的 API。
VerticalPodAutoscaler v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
|
API 群組、版本和種類。 |
metadata |
標準物件中繼資料。 |
spec |
|
status |
|
VerticalPodAutoscalerSpec v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
targetRef |
參考管理 Pod 組合的控制器以便自動配置器進行控制 (例如部署或 StatefulSet)。
您可以將 |
updatePolicy |
指定在啟動 Pod 時是否套用建議的更新，以及在 Pod 的生命週期內是否套用建議的更新。 |
resourcePolicy |
指定個別容器的 CPU 和記憶體要求調整政策。資源政策可用於設定個別容器建議的限制。如未指定，自動配置器會計算 Pod 中所有容器的建議資源，不會有額外限制。 |
recommenders |
負責為這個 VPA 物件產生建議的推薦工具。留空即可使用 GKE 提供的預設建議工具。否則，清單只能包含一項使用者提供的替代建議工具。 自 GKE 1.22 起支援。 |
VerticalPodAutoscalerList v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
|
API 群組、版本和種類。 |
metadata |
標準物件中繼資料。 |
items |
|
PodUpdatePolicy v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
updateMode |
指定在啟動 Pod 時是否套用建議的更新，以及在 Pod 的生命週期內是否套用建議的更新。可能的值如下：
|
minReplicas |
必須有多少個副本處於運作中狀態，系統才會嘗試剔除 Pod (須先通過 Pod disruption budget 等其他檢查)。只能使用正值。在 GKE 1.35.2 以上版本中，預設值為 |
PodResourcePolicy v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
containerPolicies |
個別容器的資源政策陣列。每個具名容器最多只能有一個項目，並可選擇使用 `containerName = '*'` 的單一萬用字元項目，處理所有沒有個別政策的容器。 |
ContainerResourcePolicy v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
containerName |
政策套用的容器名稱。若未指定，該政策將作為預設政策使用。 |
mode |
指定在啟動容器時是否套用建議的更新，以及在容器的生命週期內是否套用建議的更新。可能的值為「Off」和「Auto」。 如未指定值，預設為「自動」。 |
minAllowed |
指定容器允許的 CPU 要求和記憶體要求下限。預設無下限。 |
maxAllowed |
指定容器允許的 CPU 要求和記憶體要求上限。預設無上限。 |
controlledResources |
指定 |
VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
name |
負責為這個物件產生建議的推薦工具名稱。 |
VerticalPodAutoscalerStatus v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
recommendation |
最近建議的 CPU 和記憶體要求。 |
conditions |
說明 |
RecommendedPodResources v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
containerRecommendations |
個別容器的資源建議系列。 |
RecommendedContainerResources v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
containerName |
建議套用的容器名稱。 |
target |
容器的建議 CPU 要求和記憶體要求。 |
lowerBound |
容器的最小建議 CPU 要求和記憶體要求。此數量不足以使應用程式穩定。若使用較小的 CPU 和記憶體要求來執行，可能會對效能或可用性產生重大影響。 |
upperBound |
容器的最大建議 CPU 要求和記憶體要求。高於這些值的 CPU 和記憶體要求可能會被浪費。 |
uncappedTarget |
自動配置器根據實際資源用量計算出的最新資源建議，不考慮 ContainerResourcePolicy。如果實際資源用量導致目標違反 ContainerResourcePolicy，這個值可能會與繫結建議不同。這個欄位不會影響實際的資源指派。僅用於表示狀態。 |
VerticalPodAutoscalerCondition v1 autoscaling.k8s.io
| 欄位 | |
|---|---|
type |
已說明的條件類型。可能的值為「RecommendationProvided」、「LowConfidence」、「NoPodsMatched」和「FetchingHistory」。 |
status |
條件的狀態。可能的值為「True」、「False」和「Unknown」。 |
lastTransitionTime |
條件最近一次從一個狀態轉變為另一個狀態的時間。 |
reason |
上次從一種狀態轉換到另一種狀態的原因。 |
message |
人類可讀的字串，提供有關從一個狀態到另一個狀態最後一次轉換的詳情。 |
後續步驟
- 瞭解如何設定垂直自動調度 Pod 資源功能。
- 瞭解如何使用 VPA 調整 HPA 工作負載。
- 瞭解如何使用 CPU 啟動加速功能加快應用程式啟動速度。
- 進一步瞭解水平自動調度 Pod 資源。
- 進一步瞭解叢集自動配置器。