排解垂直自動調度 Pod 資源問題

如果 Google Kubernetes Engine (GKE) 中的垂直自動調度 Pod 資源功能無法正常運作，工作負載可能無法正確調度資源。這些問題會導致應用程式無法處理負載，進而造成效能問題或中斷。您可能會發現 Pod 未根據新的資源建議重新啟動，或是建議與實際用量不符。

本文說明如何解決 VerticalPodAutoscaler 設定或非預期建議的常見問題。按照這些疑難排解步驟操作，有助於應用程式根據需求有效率地調度資源，並穩定運作。

應用程式開發人員設定 VerticalPodAutoscaler 資源時，需要確保應用程式正確擴縮，因此這項資訊非常重要。此外，平台管理員和營運人員也能藉此排解叢集設定問題，避免影響自動調整資源配置的工作負載。如要進一步瞭解我們在 Cloud de Confiance by S3NS 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

診斷 VerticalPodAutoscaler 問題

如要診斷 VerticalPodAutoscaler 的問題，請使用 kubectl 或 Cloud de Confiance 控制台檢查狀態和設定。

說明 VerticalPodAutoscaler

如要查看即時計算結果和最近的調整規模決策，請使用 kubectl describe vpa 指令：

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

更改下列內容：

• VPA_NAME：VerticalPodAutoscaler 的名稱。
• NAMESPACE_NAME：VerticalPodAutoscaler 的命名空間。

輸出結果會與下列內容相似：

Name:         sample-deployment-vpa
Namespace:    default
API Version:  autoscaling.k8s.io/v1
Kind:         VerticalPodAutoscaler
# Multiple lines are omitted here
Spec:
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         sample-deployment
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-10-09T10:00:00Z
    Message:               VPA is fetching history in order to provide recommendation
    Reason:                FetchingHistory
    Status:                True
    Type:                  FetchingHistory
    Last Transition Time:  2025-10-09T10:05:00Z
    Message:               VPA pod metrics aren't available yet
    Reason:                NoMetrics
    Status:                True
    Type:                  LowConfidence
    Last Transition Time:  2025-10-09T10:10:00Z
    Message:               VPA is able to provide a recommendation
    Reason:                RecommendationProvided
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  sample-container
      Lower Bound:
        Cpu:     100m
        Memory:  128Mi
      Target:
        Cpu:     200m
        Memory:  256Mi
      Upper Bound:
        Cpu:     500m
        Memory:  512Mi
Events:          <none>

在輸出內容中，查看下列主要區段：

• Spec：顯示設定詳細資料，包括 targetRef 欄位 (目標工作負載) 和 updatePolicy 欄位 (更新套用方式)。
• Status：顯示「Conditions」部分 (運作健康狀態) 和「Recommendation」部分 (為每個容器產生的 CPU 和記憶體資源值)。
• Events：列出與 VerticalPodAutoscaler 物件相關的近期動作或錯誤。

查看 VerticalPodAutoscaler 資訊清單

如要查看 VerticalPodAutoscaler 的完整設定和狀態，請使用 kubectl 或 Cloud de Confiance 控制台檢查其 YAML 資訊清單：

kubectl get vpa VPA_NAME \
    -n NAMESPACE_NAME \
    -o yaml

在 Cloud de Confiance 控制台中檢查 VerticalPodAutoscaler 狀態

如要在 Cloud de Confiance 控制台中檢查工作負載的 VerticalPodAutoscaler 狀態，請按照下列步驟操作：

1. 前往「Workloads」(工作負載) 頁面。

   前往「Workloads」(工作負載)

2. 按一下工作負載名稱。

3. 前往「詳細資料」分頁，然後找到「自動調度器」部分。

4. 查看「垂直 Pod 自動調度器」列，瞭解指標收集和設定健康狀態的相關狀態訊息。

收集決策記錄

如要深入瞭解 VerticalPodAutoscaler 的計算和決策，請在 Cloud Logging 中啟用垂直 Pod 自動配置器決策記錄 (搶先版)。

這些記錄檔會擷取 UPDATE_RECOMMENDATION、EVICT_POD、APPLY_RECOMMENDATION_IN_PLACE 和 APPLY_RECOMMENDATION_ON_EVICTION 等事件。

如要啟用及檢查決策記錄，請參閱「收集垂直 Pod 自動調度資源事件記錄」。

排解 VerticalPodAutoscaler 建議問題

以下各節將說明 VerticalPodAutoscaler 無法產生建議，或產生的建議與預期不同的問題。

VerticalPodAutoscaler 未提供建議

症狀：

• VerticalPodAutoscaler 資訊清單中的 Status.Recommendation 欄位為空白。
• VerticalPodAutoscaler 資訊清單中的條件會顯示 NoPodsMatched、FetchingHistory 或 LowConfidence 狀態條件。

原因：

• 目標不正確：VerticalPodAutoscaler 資訊清單中的 spec.targetRef 欄位未指向相同命名空間中的現有工作負載。
• 初始指標收集：VerticalPodAutoscaler 最近才建立，仍在收集歷來資源用量資料。
• metrics-server 元件問題：VerticalPodAutoscaler 依賴 metrics-server 元件的指標。如果 metrics-server 元件無法正常運作，VerticalPodAutoscaler 就無法擷取用量資料。
• 沒有正在執行的 Pod：目標工作負載沒有正在執行或準備就緒的 Pod，因此 VerticalPodAutoscaler 無法觀察。

解決方法：

• 驗證 targetRef 欄位：檢查 spec.targetRef 區段中 kind、name 和 apiVersion 欄位的值。確認所有值都符合目標工作負載。如要確認工作負載是否存在，請執行下列指令：

  kubectl get KIND WORKLOAD_NAME \
      -n NAMESPACE_NAME
  

  更改下列內容：

  • KIND：工作負載類型，例如 deployment 或 statefulset。
  • WORKLOAD_NAME：工作負載的名稱。
  • NAMESPACE_NAME：工作負載的命名空間。

• 等待一段時間，讓系統收集指標：新的 VerticalPodAutoscaler 資源需要一段時間才能收集資料。監控 Status.Conditions 欄位，確認是否轉換為 RecommendationProvided 狀態條件。

• 檢查 metrics-server 元件：

  1. 確認 metrics-server 元件的 Pod 正在執行：

     kubectl get pods -n kube-system | grep metrics-server
     

  2. 如果 Pod 未執行或重新啟動次數過多，請檢查其記錄：

     kubectl logs -n kube-system -l k8s-app=metrics-server
     

     如果記錄項目包含 error、failed 或 unable to fetch 等字詞，表示指標收集作業發生問題。

• 確認 Pod 正在執行：確認目標工作負載至少有一個正在執行且已準備就緒的 Pod。

VerticalPodAutoscaler 建議不符預期

症狀：

• Status.Recommendation 區段中的 CPU 或記憶體值高於或低於預期。
• 建議與觀察到的工作負載資源用量不符。

原因：

• 工作負載行為變更：VerticalPodAutoscaler 建議是根據歷來用量提供。系統可能尚未反映應用程式使用模式的近期變化。
• 工作負載特性：如果工作負載是短期作業，或是使用模式變化劇烈，可能無法獲得最佳建議。
• VerticalPodAutoscaler 資源衝突：多個 VerticalPodAutoscaler 資源可能設定為以相同工作負載為目標。

解決方法：

• 給予調整時間：應用程式變更後，請給 VerticalPodAutoscaler 時間學習新的使用模式。
• 評估適用性：評估垂直 Pod 自動調度器或水平 Pod 自動調度器是否最適合工作負載類型。

• 檢查是否有衝突的 VerticalPodAutoscaler 資源：

  1. 列出叢集中的所有 VerticalPodAutoscaler 資源：

     kubectl get vpa --all-namespaces
     

  2. 檢查每個資源的 spec.targetRef 欄位。如果多個 VerticalPodAutoscaler 資源以相同的工作負載為目標，請移除或調整衝突的資源，確保只有一個 VerticalPodAutoscaler 以特定工作負載為目標。

排解 Pod 資源更新問題

下列各節將說明最佳化建議存在，但未套用至目標 Pod 的問題。

廣告連播資源要求未更新

症狀：

• VerticalPodAutoscaler 資訊清單會在 Status 區段中顯示建議，但 Pod 資訊清單中的 resources.requests 欄位不會更新。
• 使用 Auto 或 Recreate 更新模式時，Pod 不會重新啟動來套用建議。

原因：

• updateMode 欄位為 Off：當 spec.updatePolicy.updateMode 欄位設為 Off 時，VerticalPodAutoscaler 會產生建議，但不會套用。
• 工作負載只有一個副本：在 Auto 或 Recreate 更新模式中，VerticalPodAutoscaler 會避免逐出單一副本工作負載，以防停機。

解決方法：

• 檢查 updateMode 欄位：修改 VerticalPodAutoscaler 資訊清單，將 spec.updatePolicy.updateMode 欄位設為 Auto、Recreate 或 InPlaceOrRecreate。
• 增加副本數量：如為使用 Auto 或 Recreate 更新模式的工作負載，請確保 Deployment 或 StatefulSet 有多個副本。

就地更新失敗或延後

症狀：

• 無法完成容器就地調整大小，或仍處於延遲狀態。

原因：

• 節點容量不足：如果節點容量不足，無法滿足更新後的資源要求，系統會延後執行就地調整大小作業。

解決方法：

• 確認延遲調整大小狀態和節點容量：

  如果調整大小作業延遲超過五分鐘，VerticalPodAutoscaler 就會改為移除並重新建立 Pod，以套用建議。如要查看延後更新的狀態，請按照下列步驟操作：

  1. 檢查 Pod 註解，確認 vpaInPlaceUpdated 註解是否設為 "true"：

     metadata:
       annotations:
         vpaInPlaceUpdated: "true"
         vpaUpdates: 'Pod resources updated by sample-deployment-vpa: container 0: cpu request, memory request'
     

  2. 檢查延遲狀態，方法是檢查延遲大小調整事件的 status.conditions 欄位：

     status:
       conditions:
       - type: PodResizePending
         status: "True"
         reason: Deferred
         message: "Node didn't have enough resource: ..."
     

  3. 檢查 Pod 的 Kubernetes 事件：

     kubectl get events -n NAMESPACE_NAME --field-selector involvedObject.kind=Pod,involvedObject.name=POD_NAME
     

     更改下列內容：

     • NAMESPACE_NAME：Pod 的命名空間。
     • POD_NAME：Pod 名稱。

     尋找有下列任一原因的事件：ResizedPod (成功就地更新) 或 EvictedByVPA (回復重新建立)。

後續步驟

• 如果無法在文件中找到問題的解決方案，請參閱「取得支援」一文，瞭解如何取得進一步協助， 包括下列主題的建議：

  • 與 Cloud 客戶服務聯絡，建立支援案件。
  • 在 StackOverflow 上提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。你也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
  • 使用公開 Issue Tracker 開啟問題或功能要求。