排查集群自动扩缩器未扩容问题

如果 Google Kubernetes Engine (GKE) 中的 Pod 停留在 Pending 状态，并且未添加新节点，则通常表示集群自动扩缩器的扩容功能存在问题。此问题可能会导致应用无法通过扩缩来满足需求、延迟部署并影响服务可用性。

您可以使用本页面来诊断和解决导致集群自动扩缩器无法添加新节点的常见问题。修复这些问题后，您的 Kubernetes 调度器便能及时布置工作负载，以便集群适应不断增加的负载。

此信息对于需要确保其应用和服务能够可靠地调度和运行的应用开发者，以及负责确保集群可以动态预配资源来满足工作负载要求并维护服务级别的平台管理员和运维人员至关重要。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE 用户角色和任务。

了解集群自动扩缩器何时会扩容节点

在继续执行问题排查步骤之前，了解集群自动扩缩器何时会尝试扩容节点可能会有所帮助。集群自动扩缩器仅在现有资源不足时才会添加节点。

集群自动扩缩器每 10 秒检查一次是否存在任何不可调度的 Pod。如果 Kubernetes 调度器因资源不足、节点限制或未满足 Pod 要求而无法将 Pod 放置在任何现有节点上，则 Pod 会变为不可调度状态。

当集群自动扩缩器发现不可调度的 Pod 时，会评估添加节点是否会使 Pod 可以进行调度。如果添加节点会使 Pod 可以进行调度，集群自动扩缩器会向托管式实例组 (MIG) 添加新节点。Kubernetes 调度器随后便可以将 Pod 调度到新预配的节点上。

检查您是否有不可调度的 Pod

如需确定集群是否需要扩容，请检查是否有不可调度的 Pod：

1. 在 Google Cloud 控制台中，前往工作负载页面。

   转到“工作负载”

2. 在 filter_list 过滤条件字段中，输入 unschedulable，然后按 Enter。

   如果列出了任何 Pod，则表示您有不可调度的 Pod。如需排查不可调度的 Pod 问题，请参阅错误：Pod 不可调度。解决不可调度的 Pod 的根本原因通常可以使集群自动扩缩器能够进行扩容。如需识别和解决特定于集群自动扩缩器的错误，请参阅以下部分。

   如果未列出任何 Pod，则集群自动扩缩器无需进行扩容，在按预期正常运行。

检查您之前是否有不可调度的 Pod

如果您要调查过去导致集群自动扩缩器失败的原因，请检查之前是否有不可调度的 Pod：

1. 在 Google Cloud 控制台中，前往 Logs Explorer 页面。

   转到日志浏览器

2. 为要查看的日志条目指定时间范围。

3. 在查询窗格中，输入以下查询：

   logName="projects/PROJECT_ID/logs/events"
   jsonPayload.source.component="default-scheduler"
   jsonPayload.reason="FailedScheduling"
   

   将 PROJECT_ID 替换为您的项目 ID。

4. 点击运行查询。

   如果列出了任何结果，则表示您在指定的时间范围内有不可调度的 Pod。

检查问题是否是由限制引起的

确认您有不可调度的 Pod 后，请确保集群自动扩缩器的问题不是由集群自动扩缩器的限制之一引起的。

分析 Cloud Monitoring 指标，排查扩容问题

GKE 集群自动扩缩器会向 Cloud Monitoring 公开指标，以便您深入了解其决策，尤其是与 ComputeClass 相关的决策。这些指标适用于 GKE 1.37 版及更高版本，包括以下指标。

• 待处理 Pod：kubernetes.io/autoscaler/cluster_pending_pods_per_ccc 显示自动扩缩器正在尝试调度的 Pod。
• 预配尝试次数：kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc 跟踪自动扩缩器尝试添加节点的频率。
• 预配失败：kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc 显示失败的节点创建尝试和原因。

这些指标使用 k8s_entity 资源类型，其中 resource.labels.entity_type 字段的值为 ComputeClass。resource.labels.entity_name 字段的值表示 ComputeClass 名称。如果 entity_name 字段的值为空字符串 ("")，则该指标适用于与 ComputeClass 无关的集群自动扩缩器决策。

使用 Metrics Explorer 按 entity_name 字段过滤和分组结果。例如，使用 resource.labels.entity_name = "" 字符串查看与 ComputeClass 无关的活动，并使用指标标签（例如 reason）了解扩容问题是否特定于 ComputeClass。

如需查看查询示例，请参阅监控节点预配和监控待处理 Pod 状态。

查看错误

您通常可以通过查看错误消息来诊断扩容问题的原因：

• 如果您已看到错误消息，请参阅错误消息表格，了解有关如何解决错误的建议。

• 如果您还没有看到消息，请使用以下方法之一：

  • 72 小时之内的问题：在 Google Cloud 控制台中查看错误通知。
  • 超过 72 小时的问题：在 Cloud Logging 的事件中查看错误。

在通知中查看错误

如果您发现的问题发生在 72 小时以内，请在 Google Cloud 控制台中查看有关错误的通知。这些通知可提供有关集群自动扩缩器未扩容的原因的宝贵分析洞见，并提供有关如何解决错误以及如何查看相关日志以进行进一步调查的建议。

如需在 Google Cloud 控制台中查看通知，请完成以下步骤：

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   转到 KUBERNETES 集群

2. 查看通知列。以下通知与扩容问题相关：

   • Can't scale up
   • Can't scale up pods
   • Can't scale up a node pool

3. 点击相关通知即可看到一个窗格，其中包含导致问题的原因的详细信息以及解决问题的建议措施。

4. 可选：如需查看此事件的日志，请点击日志。此操作会使您前往 Logs Explorer，其中预先填充了查询，以帮助您进一步调查扩缩事件。如需详细了解扩容事件的工作情况，请参阅查看集群自动扩缩器事件。

如果您在通知中查看建议后仍遇到问题，请参阅错误消息表格以获取更多帮助。

在事件中查看错误

如果您发现的问题发生在 72 小时之前，请在 Cloud Logging 中查看事件。如果发生错误，系统通常会在事件中记录相应错误。

如需在 Google Cloud 控制台中查看集群自动扩缩器日志，请完成以下步骤：

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   转到 KUBERNETES 集群

2. 选择要调查的集群的名称，以查看其集群详情页面。

3. 在集群详情页面上，点击日志标签页。

4. 在日志标签页上，点击自动扩缩器日志标签页以查看日志。

5. 可选：如需应用更高级的过滤条件来缩小结果范围，请点击页面右侧带有箭头的按钮以在 Logs Explorer 中查看日志。

如需详细了解扩容事件的工作情况，请参阅查看集群自动扩缩器事件。如需了解如何使用 Cloud Logging 的示例，请参阅以下问题排查示例。

示例：排查 72 小时以前的问题

以下示例展示了如何调查和解决集群未扩容的问题。

场景：在过去一小时内，某个 Pod 被标记为不可调度。集群自动扩缩器未预配任何新节点来调度该 Pod。

解决方案：

1. 由于问题发生在 72 小时之前，因此您使用 Cloud Logging 而不是通过查看通知消息来调查问题。
2. 在 Cloud Logging 中，您可以找到集群自动扩缩器事件的日志记录详细信息，如在事件中查看错误中所述。

3. 您需搜索 triggeringPods 字段中包含您要调查的 Pod 的 scaleUp 事件。您可以过滤日志条目，包括按特定 JSON 字段值进行过滤。如需了解详情，请参阅高级日志查询。

4. 您未找到任何扩容事件。不过，如果您确实找到了相应事件，可以尝试查找包含与 scaleUp 事件相同的 eventId 的 EventResult。然后，您可以查看 errorMsg 字段并查阅可能出现的 scaleUp 错误消息列表。

5. 由于您未找到任何 scaleUp 事件，因此您继续搜索 noScaleUp 事件并查看以下字段：

   • unhandledPodGroups：包含有关 Pod（或 Pod 的控制器）的信息。
   • reason：提供可能会阻止纵向扩容的全局原因。
   • skippedMigs：提供可能会跳过某些 MIG 的原因。

6. 您找到了针对您的 Pod 的 noScaleUp 事件，同时 rejectedMigs 字段中的所有 MIG 都具有相同的 "no.scale.up.mig.failing.predicate" 原因信息 ID 以及下列两个参数："NodeAffinity" 和 "node(s) did not match node selector"。

解决方法：

查阅错误消息列表后，您会发现由于待处理 Pod 的调度谓词失败，集群自动扩缩器无法扩容节点池。参数为失败谓词的名称以及失败的原因。

为了解决此问题，您会查看相应 Pod 的清单，并发现它有一个节点选择器与集群中的任何 MIG 都不匹配。您可从 Pod 的清单中删除该选择器，然后重新创建 Pod。集群自动扩缩器会添加新节点，Pod 会得到调度。

解决扩容错误

如果您使用的是自定义 ComputeClass，并且扩容问题与 ComputeClass 中定义的特定节点配置有关，请参阅排查自定义 ComputeClass 问题。

确定错误后，请使用以下各表来帮助了解导致错误的原因以及如何解决该错误。

ScaleUp 错误

您可以在相应 eventResult 事件的 resultInfo.results[].errorMsg 字段中找到针对 scaleUp 事件的事件错误消息。

如果纵向扩容操作因超出配额而失败，则会发生节点创建错误，从而触发系统退避期，该退避期最长可达 30 分钟。如需了解详情，请参阅退避期。

noScaleUp 事件的原因

当集群中有不可调度的 Pod 且集群自动扩缩器无法扩容集群以调度 Pod 时，系统会定期发出 noScaleUp 事件。noScaleUp 事件是尽力而为事件，无法涵盖所有可能的情况。

NoScaleUp 顶级原因

noScaleUp 事件的顶级原因消息会显示在 noDecisionStatus.noScaleUp.reason 字段中。该消息包含导致集群自动扩缩器无法对集群进行纵向扩容的顶级原因。

NoScaleUp 顶级节点自动预配原因

noScaleUp 事件的顶级节点自动预配原因消息会显示在 noDecisionStatus.noScaleUp.napFailureReason 字段中。该消息包含导致集群自动扩缩器无法预配新节点池的顶级原因。

NoScaleUp MIG 级原因

noScaleUp 事件的 MIG 级原因消息会显示在 noDecisionStatus.noScaleUp.skippedMigs[].reason 和 noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason 字段中。 该消息包含集群自动扩缩器无法增加特定 MIG 大小的原因。

NoScaleUp Pod 组级节点自动预配原因

noScaleUp 事件的 Pod 组级节点自动预配原因消息会显示在 noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[] 字段中。该消息包含集群自动扩缩器无法预配新节点池以调度特定 Pod 组的原因。

进行进一步调查

以下部分提供了有关如何使用 Logs Explorer 和 gcpdiag 进一步了解错误的指导。

在 Logs Explorer 中调查错误

如果您想进一步调查错误消息，请查看特定于错误的日志：

1. 在 Google Cloud 控制台中，前往 Logs Explorer 页面。

   转到日志浏览器

2. 在查询窗格中，输入以下查询：

   resource.type="k8s_cluster"
   log_id("container.googleapis.com/cluster-autoscaler-visibility")
   jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"
   

   将 ERROR_MESSAGE 替换为您要调查的消息。例如 scale.up.error.out.of.resources。

3. 点击运行查询。

使用 gcpdiag 调试某些错误

gcpdiag 是在 Google Cloud技术工程师的支持下创建的开源工具，不是官方支持的 Google Cloud 产品。

如果您遇到以下某个错误消息，可以使用 gcpdiag 来帮助排查问题：

• scale.up.error.out.of.resources
• scale.up.error.quota.exceeded
• scale.up.error.waiting.for.instances.timeout
• scale.up.error.ip.space.exhausted
• scale.up.error.service.account.deleted

如需查看所有 gcpdiag 工具标志的列表和说明，请参阅 gcpdiag 使用说明。

解决复杂的扩容错误

以下部分将帮助您解决需要执行多个步骤或没有来自集群自动扩缩器的关联事件消息的错误。

Pod 不适合在节点上运行

症状：

您的 Pod 仍处于 Pending 状态，并显示 PodUnschedulable 出错提示，或者您的集群显示 Pods unschedulable 出错提示，并且集群自动扩缩器不会扩容以添加节点。

原因：

只有当机器类型为待处理 Pod 提供足够的资源（例如 CPU、GPU、内存和存储空间）时，集群自动扩缩器才会向节点池添加节点。如果 Pod 的资源请求超过单个节点的资源，则集群自动扩缩器不会扩容，因为 Pod 仍然无法在新的节点上运行。

此外，节点的可分配资源少于其总资源，因为系统组件会预留一部分资源。如需详细了解 GKE 如何计算可分配资源，请参阅节点可分配资源。

解决方法：

如需检查 Pod 的资源请求是否超出节点提供的资源并解决问题，请完成以下步骤。此示例检查的是 CPU 资源，但相同的步骤也适用于 GPU、内存和存储资源：

1. 在 Google Cloud 控制台中，前往工作负载页面。

   转到“工作负载”

2. 点击 PodUnschedulable 错误消息。

3. 在详细信息窗格中，点击 Pod 的名称。如果有多个 Pod，请从第一个 Pod 开始，并对每个 Pod 重复以下过程。

4. 在 Pod 详情页面上，点击 YAML 标签页。

5. 记下 Pod 中每个容器的资源请求，以得到资源请求总数。例如，在以下 Pod 配置中，Pod 需要 2 个 vCPU：

   resources:
     limits:
       cpu: "3"
     requests:
       cpu: "2"
   

6. 查看包含不可调度的 Pod 的集群的节点池详细信息：

   1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

      转到 KUBERNETES 集群

   2. 点击具有 Pods unschedulable 错误消息的集群的名称。

   3. 在集群详情页面上，点击节点标签页。

   4. 在节点池部分中，记下机器类型列中的值，例如 n1-standard-1。

7. 将资源请求与机器类型提供的 vCPU 进行比较。例如，如果 Pod 请求 2 个 vCPU，但可用节点使用 n1-standard-1 机器类型，则这些节点只有 1 个 vCPU。使用此类配置时，集群自动扩缩器不会触发扩容，因为 Pod 仍然不适合在节点上运行。如需详细了解可用机器类型，请参阅 Compute Engine 文档中的机器家族资源和比较指南。

8. 根据工作负载需求解决不匹配问题：

   • 如果 Pod 需要请求的资源：请使用可支持 Pod 资源请求的机器类型创建节点池。
   • 如果 Pod 的资源请求不准确：请更新 Pod 的定义，以便 Pod 适合在现有节点上运行。

MIG 实例未能及时出现

症状：

您会看到以下某条出错提示：

• 在 Google Cloud 控制台中，集群会显示以下通知：

  Can't scale up because instances in managed instance groups hosting node pools failed to appear in time
  

• 在日志记录中，扩容的 eventResult 事件包含以下出错提示：

  scale.up.error.waiting.for.instances.timeout
  

原因：

Compute Engine 无法在 MIG 中创建节点，或者新节点在扩容操作超时之前无法向控制平面注册。以下任何原因都可能导致此问题：

• 节点注册失败：Compute Engine 创建了节点，但由于一个或多个防火墙规则、最近对专用服务访问通道或 VPC 网络对等互连的更改，或者缺少 Identity and Access Management (IAM) 服务账号，节点未向控制平面注册。
• 超出项目配额：MIG 中的新实例未显示，因为您的项目超出了 CPU、IP 地址或其他资源的配额。
• IP 地址不可用：子网没有足够的可用 IP 地址来创建新节点。
• 实例模板无效：MIG 使用的实例模板无效（例如模板缺少映像），导致无法扩容。
• 资源不足：可用区没有足够的 Compute Engine 资源（例如 GPU 或 CPU）来创建新节点。
• 无法访问的 API：由于防火墙规则或 VPC Service Controls 边界，无法访问所需的 API（例如 compute.googleapis.com）。
• 网络延迟：严重的网络延迟会延误新节点的创建或可用性。

解决方法：

1. 如需找出超时原因，请列出 MIG 中的实例错误，然后检查结果：

   • MIG 未列出故障发生时的错误：Compute Engine 创建了节点，但节点未在超时之前向控制平面注册。在下一步中，从节点注册失败开始。如果节点已注册但用时过长，请参阅网络延迟。

   • MIG 会列出故障发生时的错误：Compute Engine 无法创建节点。使用错误代码和出错提示在下一步中查找原因。常见错误代码包括：

     • QUOTA_EXCEEDED：超出了项目配额
     • IP_SPACE_EXHAUSTED：不可用的 IP 地址
     • ZONE_RESOURCE_POOL_EXHAUSTED：资源不足

     某些错误代码带有 _WITH_DETAILS 后缀，并在出错提示中包含更多信息。如果错误消息报告了不存在的资源（例如来源映像），请参阅实例模板无效要点。

2. 请根据问题的原因，使用相应的解决方法：

   • 节点注册失败：请按照查找节点注册失败的实例中的步骤操作。您还可以检查最近的配置更改：

     • 防火墙规则：如需检查最近是否创建、更新或删除了防火墙规则，请在 Logs Explorer 中运行以下查询：

       resource.type="gce_firewall_rule"
       log_id("cloudaudit.googleapis.com/activity")
       

       如果某项更改阻止了节点与控制平面之间或节点与 Google API 之间的流量，请更新或替换防火墙规则。如需详细了解所需的连接，请参阅成功注册节点的前提条件。

     • IAM 服务账号：对于缺失的服务账号，请参阅扩容错误表中的 scale.up.error.service.account.deleted 行。

     • 专用服务访问通道：如需查看审核日志中的近期更改，请参阅专用服务访问通道审核日志记录。

     • VPC 网络对等互连：如需检查最近是否添加、更新或移除了对等互连，请在 Logs Explorer 中针对每个对等互连项目运行以下查询：

       log_id("cloudaudit.googleapis.com/activity")
       resource.type="gce_network"
       protoPayload.methodName:("compute.networks.addPeering" OR
       "compute.networks.updatePeering" OR
       "compute.networks.removePeering")
       

       如果对等互连更改中断了与控制平面的连接，请更新对等互连连接。如果连接已被删除，请参阅 VPC 网络对等互连连接意外删除。

   • 超出项目配额：请参阅扩容错误表中的 scale.up.error.quota.exceeded 行。

   • IP 地址不可用：请参阅扩容错误表中的 scale.up.error.ip.space.exhausted 行。

   • 实例模板无效：请参阅 Compute Engine 文档中的实例模板无效。

   • 资源不足：请参阅扩容错误表中的 scale.up.error.out.of.resources 行。

   • 无法访问的 API：在 Logs Explorer 中，运行查询以检查与防火墙规则或 VPC Service Controls 边界相关的活动：

     • 如需检查防火墙规则最近是否发生了更改，请运行节点注册失败的防火墙规则要点中的审核日志查询。如果您为规则启用了防火墙规则日志记录，则还可以通过运行以下查询来查看规则拒绝的连接：

       resource.type="gce_subnetwork"
       log_id("compute.googleapis.com/firewall")
       jsonPayload.disposition="DENIED"
       

       如果日志显示有防火墙规则阻止了流向所需 Google API 的流量，请更新或替换该防火墙规则以允许流量。如需详细了解网络要求，请参阅与 Google API 和服务的网络连接的前提条件。

     • 如果您使用 VPC Service Controls，请在 Google Cloud 控制台中选择您的组织，然后在 Logs Explorer 中运行以下查询，以检查最近是否添加或修改了边界：

       logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
       protoPayload.serviceName="accesscontextmanager.googleapis.com"
       

       将 ORGANIZATION_ID 替换为您的组织 ID。

       您还可以添加以下过滤条件，以查找 VPC Service Controls 边界的更新或创建：

       severity=NOTICE
       protoPayload.methodName=("google.identity.accesscontextmanager.v1.AccessContextManager.CreateServicePerimeter"
       OR "google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter")
       

       如果新的或修改后的边界阻止了对所需 Google API 的访问，请从审核日志中检索 VPC Service Controls 错误，以识别被阻止的服务并更新服务边界以允许访问。如需详细了解如何在边界内使用集群自动扩缩器，请参阅自动扩缩器在启用了可访问服务和受限服务的边界内无法正常工作。

   • 网络延迟：暂时性网络延迟通常会在后续扩容尝试中得到解决。如需了解持续延迟，请参阅 Compute Engine 文档中的排查常见网络问题。

健康状况不佳的集群阻止了扩容

症状：

集群自动伸缩器会停止所有伸缩操作，并且 cluster-autoscaler-status ConfigMap 包含一个类型为 Warning 的事件，其中将 ClusterUnhealthy 列为原因。

如需查看 cluster-autoscaler-status ConfigMap，请运行以下命令：

kubectl describe configmap cluster-autoscaler-status -n kube-system

原因：

如果集群自动扩缩器认为集群健康状况不佳，则不会执行扩容。集群自动扩缩器根据健康节点和就绪节点的比率（而非控制平面健康状况）来确定集群健康状况。如果集群中 45% 的节点健康状况不佳或未就绪，集群自动扩缩器会停止所有操作。

当就绪节点具有带 ignore-taint.cluster-autoscaler.kubernetes.io/ 前缀的污点时，集群自动扩缩器也会将该节点视为 NotReady。 只要存在该污点，集群自动扩缩器就会将节点视为 NotReady。

解决方法：

如需解决此问题，请执行以下一项或两项操作，以减少健康状况不佳节点的数量：

• 调查并修复运行状况不佳或 NotReady 的节点，使集群中运行状况不佳的节点少于 45%。
• 如果就绪节点具有带 ignore-taint.cluster-autoscaler.kubernetes.io/ 前缀的污点，请移除该污点。

后续步骤

• 查看 Kubernetes 集群自动扩缩器常见问题解答。
• 观看有关如何排查和解决扩缩问题的 YouTube 视频。

• 排查自定义 ComputeClass 问题。

• 如果您在文档中找不到问题的解决方案，请参阅获取支持以获取进一步的帮助，包括以下主题的建议：

  • 请与 Cloud Customer Care 联系，以提交支持请求。
  • 通过在 StackOverflow 上提问并使用 google-kubernetes-engine 标记搜索类似问题，从社区获得支持。您还可以加入 #kubernetes-engine Slack 频道，以获得更多社区支持。
  • 使用公开问题跟踪器提交问题或功能请求。