排查 Pod 纵向自动扩缩问题

Autopilot Standard

如果 Google Kubernetes Engine (GKE) 中的 Pod 纵向自动扩缩未按预期运行，您的工作负载可能无法正确扩缩。这些问题可能会阻碍应用处理负载，从而导致性能问题或服务中断。您可能会看到 Pod 未使用新的资源建议重启，或者建议与实际用量不符。

您可以使用本文档解决 VerticalPodAutoscaler 配置或意外建议方面的常见问题。按照这些问题排查步骤操作，有助于确保您的应用根据需求高效可靠地扩缩。

对于配置 VerticalPodAutoscaler 资源并需要确保其应用正确扩缩的应用开发者，此信息非常重要。它还可以帮助平台管理员和运维人员排查影响自动扩缩的工作负载的集群配置问题。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅 常见的 GKE 用户角色和任务。

诊断 VerticalPodAutoscaler 问题

如需诊断 VerticalPodAutoscaler 的问题，请使用 kubectl 或 Google Cloud 控制台检查其状态和 配置。

描述 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 或 Google Cloud 控制台检查其 YAML 清单：

控制台

1. 在 Google Cloud 控制台中，前往对象浏览器页面。

   转到对象浏览器

2. 点击对象种类 过滤条件列表。

3. 清除所有现有选择。

4. 选择 VerticalPodAutoscaler ，然后点击确定 。

5. 在过滤后的列表中，选择 autoscaling.k8s.io API 组。

6. 选择 VerticalPodAutoscaler 对象种类。

7. 点击要检查的 VerticalPodAutoscaler 的名称。

kubectl

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

替换以下内容：

• VPA_NAME：VerticalPodAutoscaler 的名称。
• NAMESPACE_NAME：VerticalPodAutoscaler 的命名空间。

在 Google Cloud 控制台中检查 VerticalPodAutoscaler 状态

如需在 Google Cloud 控制台中检查工作负载的 VerticalPodAutoscaler 状态，请执行以下操作：

1. 前往工作负载 页面。

   转到“工作负载”

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 的问题。

Pod 资源请求未更新

症状：

• VerticalPodAutoscaler 清单的 Status 部分显示建议，但 Pod 清单中的 resources.requests 字段未更新。
• Pod 未重启以在使用 Auto 或 Recreate 更新模式时应用建议。

原因：

• **updateMode 字段为 Off**：当 spec.updatePolicy.updateMode 字段设置为 Off 时，VerticalPodAutoscaler 会生成建议，但 不会应用这些建议。
• 工作负载只有一个副本：在 Auto 或 Recreate 更新模式下， VerticalPodAutoscaler 会避免驱逐单副本工作负载，以防止 停机。

解决方法：

• 检查 updateMode 字段：修改 VerticalPodAutoscaler 清单 将 spec.updatePolicy.updateMode 字段设置为 Auto、Recreate 或 InPlaceOrRecreate。
• 增加副本数量：对于使用 Auto 或 Recreate 更新模式的工作负载，请确保 Deployment 或 StatefulSet 有多个 副本。

就地更新失败或仍处于延迟状态

症状：

• 就地调整容器大小失败或仍处于延迟状态。

原因：

• 节点容量不足：如果节点没有足够的容量来满足更新后的资源请求，则就地调整大小操作会延迟。

解决方法：

• 验证延迟调整大小状态和节点容量：

  如果调整大小操作延迟超过 5 分钟，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 Customer Care 联系，以提交支持请求。
  • 通过在 StackOverflow 上提问并使用 google-kubernetes-engine 标记搜索类似问题，从社区获得支持。您还可以加入 #kubernetes-engine Slack 频道 以获得更多社区支持。
  • 使用 公开问题跟踪器提交问题或功能请求。