排解垂直自動調度 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 資訊清單：

控制台

  1. 前往 Cloud de Confiance 控制台的「物件瀏覽器」頁面。

    前往物件瀏覽器

  2. 按一下「Object Kind」(物件種類) 篩選器清單。

  3. 清除所有現有選項。

  4. 選取「VerticalPodAutoscaler」，然後按一下「OK」。

  5. 在篩選後的清單中，選取「autoscaling.k8s.io」autoscaling.k8s.ioAPI 群組。

  6. 選取「VerticalPodAutoscaler」VerticalPodAutoscaler物件種類。

  7. 按一下要檢查的 VerticalPodAutoscaler 名稱。

kubectl

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

更改下列內容：

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

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

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

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

    前往「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 時間學習新的使用模式。
  • 評估適用性：評估 VerticalPodAutoscaler 或 水平 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 (回復為重新建立)。

後續步驟