查看集群自动扩缩器事件。

标准

本页面介绍了 Google Kubernetes Engine (GKE) 中的集群自动扩缩器发出的可见性事件。通过分析这些事件，您可以深入了解集群自动扩缩器如何管理集群的扩缩，并了解其决策背后的原因。

GKE 集群自动扩缩器会发出可见性事件，这些事件在 Cloud Logging 中可作为日志条目使用。本指南中介绍的事件与集群自动扩缩器生成的 Kubernetes 事件互不相关。

要求

要查看自动扩缩器事件，您必须在集群中启用 Cloud Logging。如果停用 Logging，则不会生成这些事件。

查看事件

集群自动扩缩器的可见性事件存储在 Cloud Logging 日志中，与 GKE 集群在同一项目中。您还可以在 Google Cloud 控制台的 Google Kubernetes Engine 页面的通知中查看这些事件。

查看可见性事件日志

如需查看日志，请执行以下操作：

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到“Kubernetes 集群”
选择集群的名称以查看其集群详细信息页面。
在集群详情页面上，点击日志标签页。
在日志标签页上，点击自动扩缩器日志标签页以查看日志。
（可选）如需应用更高级的过滤条件来缩小结果范围，请点击页面右侧的按钮以在日志浏览器中查看日志。

查看可见性事件通知

如需在 Google Kubernetes Engine 页面上查看可见性事件通知，请执行以下操作：

转到 Google Cloud 控制台中的 Google Kubernetes Engine 页面：

前往 Google Kubernetes Engine
查看特定集群的通知列，以找到与扩缩相关的通知。
点击通知以显示详细信息、推荐措施以及访问此事件的日志。

事件类型

所有记录的事件都采用 JSON 格式，并且可以在日志条目的 jsonPayload 字段中找到。事件中的所有时间戳均为 UNIX 时间戳（以秒为单位）。

以下总结集群自动扩缩器发出的事件的类型：

事件类型	说明
`status`	定期发生，描述所有经过自动扩缩的节点池的大小以及集群自动扩缩器观察到的所有经过自动扩缩的节点池的目标大小。
`scaleUp`	在集群自动扩缩器对集群纵向扩容时发生。
`scaleDown`	在集群自动扩缩器对集群纵向缩容时发生。
`eventResult`	当 ScaleUp 或 ScaleDown 事件成功或不成功完成时发生。
`nodePoolCreated`	当启用了节点自动预配功能的集群自动扩缩器创建新节点池时发生。
`nodePoolDeleted`	当启用了节点自动预配功能的集群自动扩缩器删除节点池时发生。
`noScaleUp`	当集群中有无法安排的 Pod，并且集群自动扩缩器无法对集群进行纵向扩容以容纳 Pod 时发生。
`noScaleDown`	当系统阻止节点被集群自动扩缩器删除时发生。

Status 事件

status 事件会定期发生，描述所有经过自动扩缩的节点池的大小以及集群自动扩缩器观察到的所有经过自动扩缩的节点池的目标大小。

示例

以下日志示例展示 status 事件：

{
  "status": {
    "autoscaledNodesCount": 4,
    "autoscaledNodesTarget": 4,
    "measureTime": "1582898536"
  }
}

ScaleUp 事件

当集群自动扩缩器对集群进行纵向扩容时，会发出 scaleUp 事件。自动扩缩器通过扩大节点池的底层代管实例组 (MIG) 来增加集群的节点池的大小。如需详细了解扩容的工作原理，请参阅 Kubernetes 集群自动扩缩器常见问题解答中的扩容工作原理。

该事件包含下列相关信息：哪些 MIG 纵向扩容、节点数量以及哪些无法安排的 Pod 触发了该事件。

触发 Pod 的列表被截断为 50 个任意条目。您可以在 triggeringPodsTotalCount 字段中查看触发 Pod 的实际数量。

示例

以下日志示例展示 scaleUp 事件：

{
  "decision": {
    "decideTime": "1582124907",
    "eventId": "ed5cb16d-b06f-457c-a46d-f75dcca1f1ee",
    "scaleUp": {
      "increasedMigs": [
        {
          "mig": {
            "name": "test-cluster-default-pool-a0c72690-grp",
            "nodepool": "default-pool",
            "zone": "us-central1-c"
          },
          "requestedNodes": 1
        }
      ],
      "triggeringPods": [
        {
          "controller": {
            "apiVersion": "apps/v1",
            "kind": "ReplicaSet",
            "name": "test-85958b848b"
          },
          "name": "test-85958b848b-ptc7n",
          "namespace": "default"
        }
      ],
      "triggeringPodsTotalCount": 1
    }
  }
}

ScaleDown 事件

当集群自动扩缩器对集群进行纵向缩容时，会发出 scaleDown 事件。如需详细了解缩容的工作原理，请参阅 Kubernetes 集群自动扩缩器常见问题解答中的缩容工作原理。

cpuRatio 和 memRatio 字段以百分比的形式描述节点的 CPU 和内存利用率。此利用率是 Pod 请求的总和除以可分配的节点数，而非实际利用率。

逐出 Pod 的列表被截断为 50 个任意条目。您可以在 evictedPodsTotalCount 字段中查看逐出 Pod 的实际数量。

使用以下查询验证集群自动扩缩器是否缩减了节点：

resource.type="k8s_cluster" \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
log_id("container.googleapis.com/cluster-autoscaler-visibility") \
( "decision" NOT "noDecisionStatus" )

替换以下内容：

CLUSTER_NAME：集群的名称。
COMPUTE_REGION：集群的 Compute Engine 区域，例如 us-central1。

示例

以下日志示例展示 scaleDown 事件：

{
  "decision": {
    "decideTime": "1580594665",
    "eventId": "340dac18-8152-46ff-b79a-747f70854c81",
    "scaleDown": {
      "nodesToBeRemoved": [
        {
          "evictedPods": [
            {
              "controller": {
                "apiVersion": "apps/v1",
                "kind": "ReplicaSet",
                "name": "kube-dns-5c44c7b6b6"
              },
              "name": "kube-dns-5c44c7b6b6-xvpbk"
            }
          ],
          "evictedPodsTotalCount": 1,
          "node": {
            "cpuRatio": 23,
            "memRatio": 5,
            "mig": {
              "name": "test-cluster-default-pool-c47ef39f-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-f"
            },
            "name": "test-cluster-default-pool-c47ef39f-p395"
          }
        }
      ]
    }
  }
}

您还可以在未运行工作负载（通常仅由 DaemonSet 创建的系统 Pod）的节点上查看 scale-down 事件。

使用以下查询可查看事件日志：

resource.type="k8s_cluster" \
resource.labels.project_id=PROJECT_ID \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
severity>=DEFAULT \
logName="projects/PROJECT_ID/logs/events" \
("Scale-down: removing empty node")

请替换以下内容：

PROJECT_ID：您的项目 ID。
CLUSTER_NAME：集群的名称。
COMPUTE_REGION：集群的 Compute Engine 区域，例如 us-central1。

EventResult 事件

当 ScaleUp 或 ScaleDown 事件成功或不成功完成时会发出eventResult 事件。此事件包含一系列事件 ID（来自 ScaleUp 或 ScaleDown 事件中的 eventId 字段）以及错误消息。错误消息为空表示活动已成功完成。results 字段中汇总了一系列 EventResult 事件。

如需诊断错误，请参阅 ScaleUp 错误和 ScaleDown 错误部分。

示例

以下日志示例展示 eventResult 事件：

{
  "resultInfo": {
    "measureTime": "1582878896",
    "results": [
      {
        "eventId": "2fca91cd-7345-47fc-9770-838e05e28b17"
      },
      {
        "errorMsg": {
          "messageId": "scale.down.error.failed.to.delete.node.min.size.reached",
          "parameters": [
            "test-cluster-default-pool-5c90f485-nk80"
          ]
        },
        "eventId": "ea2e964c-49b8-4cd7-8fa9-fefb0827f9a6"
      }
    ]
  }
}

NodePoolCreated 事件

当启用了节点自动预配功能的集群自动扩缩器创建新节点池时，会发出 nodePoolCreated 事件。此事件包含已创建的节点池的名称及其 MIG 列表。如果节点池是由于 ScaleUp 事件而创建的，则 triggeringScaleUpId 字段中会包含相应 ScaleUp 事件的 eventId。

示例

以下日志示例展示 nodePoolCreated 事件：

{
  "decision": {
    "decideTime": "1585838544",
    "eventId": "822d272c-f4f3-44cf-9326-9cad79c58718",
    "nodePoolCreated": {
      "nodePools": [
        {
          "migs": [
            {
              "name": "test-cluster-nap-n1-standard--b4fcc348-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-f"
            },
            {
              "name": "test-cluster-nap-n1-standard--jfla8215-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-c"
            }
          ],
          "name": "nap-n1-standard-1-1kwag2qv"
        }
      ],
      "triggeringScaleUpId": "d25e0e6e-25e3-4755-98eb-49b38e54a728"
    }
  }
}

NodePoolDeleted 事件

如果启用了节点自动预配功能的集群自动扩缩器删除节点池，则会发出 nodePoolDeleted 事件。

示例

以下日志示例展示 nodePoolDeleted 事件：

{
  "decision": {
    "decideTime": "1585830461",
    "eventId": "68b0d1c7-b684-4542-bc19-f030922fb820",
    "nodePoolDeleted": {
      "nodePoolNames": [
        "nap-n1-highcpu-8-ydj4ewil"
      ]
    }
  }
}

NoScaleUp 事件

当集群中有无法安排的 Pod 且集群自动扩缩器无法对集群进行纵向扩容以容纳 Pod 时，会定期发出 noScaleUp 事件。

noScaleUp 事件是尽力而为事件，即这些事件无法涵盖集群自动扩缩器无法纵向扩容的所有可能原因。
NoScaleUp 事件会受到限制，以限制生成的日志量。系统每隔几分钟就会发出一个持续存在的原因。
所有原因都可以在多个事件之间任意分配。例如，无法保证一个 Pod 组所有遭拒的 MIG 原因都会出现在同一事件中。
未处理 Pod 组的列表被截断为 50 个任意条目。未处理 Pod 组的实际数量可以在 unhandledPodGroupsTotalCount 字段中找到。

原因字段

以下字段有助于说明未发生纵向扩容的原因：

reason：提供全局原因，说明集群自动扩缩器为什么无法纵向扩容。如需了解详情，请参阅 NoScaleUp 顶级原因部分。
napFailureReason：提供阻止集群自动扩缩器预配其他节点池的全局原因（例如，节点自动预配功能已停用）。如需了解详情，请参阅 NoScaleUp 顶级节点自动预配原因部分。
skippedMigs[].reason：就为什么会跳过特定 MIG 提供相关信息。集群自动扩缩器会在尝试纵向扩容过程中跳过某些 MIG，从而不进行任何 Pod 考量（例如，添加其他节点会超出集群范围的资源限制）。如需了解详情，请参阅 NoScaleUp MIG 级原因部分。
unhandledPodGroups：包含有关下列方面的信息：某组无法安排的 Pod 为什么没有触发纵向扩容。Pod 按其直接控制器进行分组。没有控制器的 Pod 按其本身进行分组。每个 Pod 组都包含一个随机示例 Pod 和该组中 Pod 的数量，以及以下原因：
- napFailureReasons：集群自动扩缩器无法预配新节点池以容纳此 Pod 组的原因（例如，Pod 具有亲和性限制）。如需了解详情，请参阅 NoScaleUp Pod 级节点自动预配原因部分。
- rejectedMigs[].reason：按 MIG 原因，让您了解集群自动扩缩器为什么无法增加特定 MIG 的大小来容纳此 Pod 组（例如，MIG 的节点对于 Pod 来说太小）。如需了解详情，请参阅 NoScaleUp MIG 级原因部分。

示例

以下日志示例展示 noScaleUp 事件：

{
  "noDecisionStatus": {
    "measureTime": "1582523362",
    "noScaleUp": {
      "skippedMigs": [
        {
          "mig": {
            "name": "test-cluster-nap-n1-highmem-4-fbdca585-grp",
            "nodepool": "nap-n1-highmem-4-1cywzhvf",
            "zone": "us-central1-f"
          },
          "reason": {
            "messageId": "no.scale.up.mig.skipped",
            "parameters": [
              "max cluster cpu limit reached"
            ]
          }
        }
      ],
      "unhandledPodGroups": [
        {
          "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              "parameters": [
                "us-central1-f"
              ]
            }
          ],
          "podGroup": {
            "samplePod": {
              "controller": {
                "apiVersion": "v1",
                "kind": "ReplicationController",
                "name": "memory-reservation2"
              },
              "name": "memory-reservation2-6zg8m",
              "namespace": "autoscaling-1661"
            },
            "totalPodCount": 1
          },
          "rejectedMigs": [
            {
              "mig": {
                "name": "test-cluster-default-pool-b1808ff9-grp",
                "nodepool": "default-pool",
                "zone": "us-central1-f"
              },
              "reason": {
                "messageId": "no.scale.up.mig.failing.predicate",
                "parameters": [
                  "NodeResourcesFit",
                  "Insufficient memory"
                ]
              }
            }
          ]
        }
      ],
      "unhandledPodGroupsTotalCount": 1
    }
  }
}

NoScaleDown 事件

当系统阻止集群自动扩缩器删除节点时，会定期发出 noScaleDown 事件。

因为利用率较高而无法移除的节点不包含在 NoScaleDown 事件中。
NoScaleDown 事件是尽力而为事件，即这些事件无法涵盖集群自动扩缩器无法纵向缩容的所有可能原因。
NoScaleDown 事件会受到限制，以限制生成的日志量。系统每隔几分钟就会发出一个持续存在的原因。
节点列表被截断为 50 个任意条目。实际节点数可在 nodesTotalCount 字段中找到。

原因字段

以下字段有助于说明未发生纵向缩容的原因：

reason：提供全局原因，让您了解为什么会阻止集群自动扩缩器进行纵向缩容（例如最近纵向扩容后的退避期）。如需了解详情，请参阅 NoScaleDown 顶级原因部分。
nodes[].reason：提供按节点原因，让您了解为什么阻止集群自动扩缩器删除特定节点（例如，没有位置可以接纳节点中移出的 Pod）。如需了解详情，请参阅 NoScaleDown 节点级原因部分。

示例

以下日志示例展示 noScaleDown 事件：

{
  "noDecisionStatus": {
    "measureTime": "1582858723",
    "noScaleDown": {
      "nodes": [
        {
          "node": {
            "cpuRatio": 42,
            "mig": {
              "name": "test-cluster-default-pool-f74c1617-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-c"
            },
            "name": "test-cluster-default-pool-f74c1617-fbhk"
          },
          "reason": {
            "messageId": "no.scale.down.node.no.place.to.move.pods"
          }
        }
      ],
      "nodesTotalCount": 1,
      "reason": {
        "messageId": "no.scale.down.in.backoff"
      }
    }
  }
}

消息

集群自动扩缩器发出的事件使用参数化消息来提供事件说明。parameters 字段与 messageId 字段一起使用，例如 NoScaleUp 事件的示例日志。

本部分提供各种 messageId 的说明及其相应参数。但是，此部分并不包含所有可能的消息，并且可以随时进行扩展。

ScaleUp 错误

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

消息	详细信息	参数	应对措施
`"scale.up.error.out.of.resources"`	由于某项 Compute Engine 资源（如 GPU 或 CPU）当前不可用，当您尝试在无法容纳您的请求的可用区中请求新资源时，会发生资源错误。	失败 MIG ID。	按照 Compute Engine 文档中的资源可用性问题排查步骤进行操作。
`"scale.up.error.quota.exceeded"`	由于超出了 Compute Engine 配额，部分 MIG 无法增加，导致 scaleUp 事件失败。	失败 MIG ID。	检查 Google Cloud 控制台中 MIG 的错误标签页，查看超出的配额。了解超出的配额后，请按照说明申请增加配额。
`"scale.up.error.waiting.for.instances.timeout"`	由于超时，托管式实例组的扩容失败。	失败 MIG ID。	此消息应该是暂时性的。如果它持续存在，请与 Cloud Customer Care 团队联系以进行进一步调查。
`"scale.up.error.ip.space.exhausted"`	由于某些托管式实例组中的实例用尽了 IP，因此无法扩容。这意味着集群没有足够的未分配 IP 地址空间来用于添加新节点或 Pod。	失败 MIG ID。	请按照 Pod 没有足够的可用 IP 地址空间中的问题排查步骤进行操作。
`"scale.up.error.service.account.deleted"`	由于服务账号已被删除，因此无法扩容。	失败 MIG ID。	尝试恢复删除的服务账号。如果该过程未能成功，请与 Cloud Customer Care 团队联系以进行进一步调查。

noScaleUp 事件的原因

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

NoScaleUp 顶级原因

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

消息	详细信息	应对措施
`"no.scale.up.in.backoff"`	因为扩容处于退避期（暂时阻止），所以未进行扩容。此消息可能会在具有大量 Pod 的扩容事件期间发生。	此消息应该是暂时性的。请过几分钟后再检查此错误。如果此消息持续存在，请与 Cloud Customer Care 联系以进行进一步调查。

NoScaleUp 顶级节点自动预配原因

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

消息详细信息应对措施

消息	详细信息	应对措施
`"no.scale.up.nap.disabled"`	由于集群级未启用节点自动预配功能，因此节点自动预配功能无法扩容。如果停用节点自动预配功能，并且如果待处理 Pod 具有任何现有节点池无法满足的要求，则不会自动预配新节点。	查看集群配置，并考虑启用节点自动预配功能。

"no.scale.up.nap.disabled"

由于集群级未启用节点自动预配功能，因此节点自动预配功能无法扩容。

如果停用节点自动预配功能，并且如果待处理 Pod 具有任何现有节点池无法满足的要求，则不会自动预配新节点。

查看集群配置，并考虑启用节点自动预配功能。

NoScaleUp MIG 级原因

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

消息	详细信息	参数	应对措施
`"no.scale.up.mig.skipped"`	由于模拟过程中跳过了 MIG，所以无法对它进行扩容。	跳过 MIG 的原因（例如，缺少 Pod 要求）。	查看错误消息中包含的参数并解决跳过 MIG 的原因。
`"no.scale.up.mig.failing.predicate"`	由于待处理 Pod 的调度谓词失败，因此无法扩容节点池。	失败谓词的名称和失败原因。	查看 Pod 要求，例如亲和性规则、污点或容忍设置以及资源要求。

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

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

消息	详细信息	参数	应对措施
`"no.scale.up.nap.pod.gpu.no.limit.defined"`	节点自动预配无法预配任何节点组，因为待处理 Pod 具有 GPU 请求，但未在集群级定义 GPU 资源限制。	请求的 GPU 类型。	查看待处理 Pod 的 GPU 请求，并更新集群级节点自动预配 GPU 限制配置。
`"no.scale.up.nap.pod.gpu.type.not.supported"`	节点自动预配功能没有为 Pod 预配任何节点组，因为它具有未知 GPU 类型的请求。	请求的 GPU 类型。	在待处理 Pod 的配置中检查 GPU 类型，以确保其与受支持的 GPU 类型匹配。
`"no.scale.up.nap.pod.zonal.resources.exceeded"`	节点自动预配功能没有在此可用区中为 Pod 预配任何节点组，因为这样做会违反集群范围的资源上限、超出可用区中的可用资源或没有适合请求的机器类型。	所考虑的可用区的名称。	查看并更新集群范围的资源上限、Pod 资源请求或节点自动预配的可用区。
`"no.scale.up.nap.pod.zonal.failing.predicates"`	由于谓词失败，节点自动预配功能未在此可用区中为 Pod 预配任何节点组。	所考虑的可用区的名称，以及导致谓词失败的原因。	查看待处理 Pod 的要求，例如亲和性规则、污点、容忍或资源要求。

ScaleDown 错误

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

事件消息	详情	参数	应对措施
`"scale.down.error.failed.to.mark.to.be.deleted"`	无法将节点标记为待删除。	失败节点的名称。	此消息应该是暂时性的。如果它持续存在，请与 Cloud Customer Care 团队联系以进行进一步调查。
`"scale.down.error.failed.to.evict.pods"`	由于无法将某些 Pod 从节点中逐出，因此集群自动扩缩器无法缩容。	失败节点的名称。	查看 Pod 的 PodDisruptionBudget，并确保规则允许逐出应用副本（当可接受时）。如需了解详情，请参阅 Kubernetes 文档中的为应用指定中断预算。
`"scale.down.error.failed.to.delete.node.min.size.reached"`	集群自动扩缩器无法缩减规模，原因是由于集群已达到规模下限，因此无法删除节点。	失败节点的名称。	查看为节点池自动扩缩设置的最小值，并根据需要调整设置。如需了解详情，请参阅错误：集群中的节点已达到最小大小。

noScaleDown 事件的原因

当系统阻止集群自动扩缩器删除节点时，会定期发出 noScaleDown 事件。 noScaleDown 事件是尽力而为事件，无法涵盖所有可能的情况。

NoScaleDown 顶级原因

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

事件消息详情应对措施

事件消息	详情	应对措施
`"no.scale.down.in.backoff"`	由于纵向缩容处于退避期（暂时阻止），因此集群自动扩缩器无法进行纵向缩容。	此消息应该是暂时性的，并且会在最近发生纵向扩容事件时发生。如果此消息持续存在，请与 Cloud Customer Care 联系以进行进一步调查。
`"no.scale.down.in.progress"`	由于之前的纵向缩容仍在进行中，因此集群自动扩缩器无法进行缩容。	此消息应该是暂时性的，因为 Pod 最终会被移除。如果此消息频繁出现，请查看 Pod 阻止缩减的终止宽限期。为了加快解决速度，您还可以删除不再需要的 Pod。

"no.scale.down.in.backoff"

由于纵向缩容处于退避期（暂时阻止），因此集群自动扩缩器无法进行纵向缩容。

此消息应该是暂时性的，并且会在最近发生纵向扩容事件时发生。

如果此消息持续存在，请与 Cloud Customer Care 联系以进行进一步调查。

"no.scale.down.in.progress"

由于之前的纵向缩容仍在进行中，因此集群自动扩缩器无法进行缩容。

此消息应该是暂时性的，因为 Pod 最终会被移除。如果此消息频繁出现，请查看 Pod 阻止缩减的终止宽限期。为了加快解决速度，您还可以删除不再需要的 Pod。

NoScaleDown 节点级原因

noScaleDown 事件的节点级原因消息会显示在 noDecisionStatus.noScaleDown.nodes[].reason field 中。该消息包含集群自动扩缩器无法移除特定节点的原因。

事件消息	详情	参数	应对措施
`"no.scale.down.node.scale.down.disabled.annotation"`	集群自动扩缩器无法从节点池中移除节点，因为节点已添加了 `cluster-autoscaler.kubernetes.io/scale-down-disabled: true` 注解。	不适用	集群自动扩缩器会跳过带有此注解的节点，而不会考虑其利用率，并且无论节点的利用率因子如何，都会记录此消息。如果您希望集群自动扩缩器缩减这些节点，请移除注解。
`"no.scale.down.node.node.group.min.size.reached"`	当节点组大小超过大小限制下限时，集群自动扩缩器无法进行纵向缩容。出现这种情况是因为移除节点会违反节点自动预配设置中定义的集群级最低资源限制。	不适用	查看为节点池自动扩缩设置的最小值。如果您希望集群自动扩缩器缩减此节点，请调整最小值。
`"no.scale.down.node.minimal.resource.limits.exceeded"`	由于会违反集群级最低资源限制，因此集群自动扩缩器无法缩减节点。这些是针对节点自动预配设置的资源限制。	不适用	查看内存和 vCPU 的限制，如果您希望集群自动扩缩器缩减此节点，请提高限制。
`"no.scale.down.node.no.place.to.move.pods"`	由于没有位置可以移动 Pod，因此集群自动扩缩器无法缩容。	不适用	如果您希望重新调度 Pod，请查看未充分利用的节点上的 Pod 的调度要求，以确定它们是否可以移动到集群中的其他节点。如需了解详情，请参阅错误：没有可移动 Pod 的位置。
`"no.scale.down.node.pod.not.backed.by.controller"`	pod 由于不受控制器支持而阻止了缩容。具体而言，由于 Pod 缺少已识别的控制器，集群自动扩缩器无法缩减未充分利用的节点。允许的控制器包括 ReplicationController、DaemonSet、Job、StatefulSet 或 ReplicaSet。	阻止 Pod 的名称。	为 Pod 设置注解 `"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"` 或定义可接受的控制器。
`"no.scale.down.node.pod.has.local.storage"`	Pod 由于具有本地存储空间而阻止纵向缩容。	阻止 Pod 的名称。	如果 Pod 的本地存储空间中的数据不重要，请为 Pod 设置注解 `"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"`。只有使用 1.22 版之前的版本的集群才会出现此错误。
`"no.scale.down.node.pod.not.safe.to.evict.annotation"`	节点上的 Pod 具有 `safe-to-evict=false` 注解。	阻止 Pod 的名称。	如果可以安全地逐出 Pod，请修改 Pod 的清单并将注解更新为 `"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"`。
`"no.scale.down.node.pod.kube.system.unmovable"`	Pod 阻止纵向缩容，因为它是 `kube-system` 命名空间中不含 PodDisruptionBudget 的非 DaemonSet、非镜像 Pod。	阻止 Pod 的名称。	默认情况下，集群自动扩缩器不会移除 `kube-system` 命名空间中的 Pod。如需解决此问题，请为 `kube-system` Pod 添加 PodDisruptionBudget，或者结合使用节点池污点和容忍设置来分隔 `kube-system` Pod 与应用 Pod。如需了解详情，请参阅错误：kube-system Pod 不可移动。
`"no.scale.down.node.pod.not.enough.pdb"`	Pod 没有足够的 PodDisruptionBudget，因此会阻止纵向缩容。	阻止 Pod 的名称。	查看 Pod 的 PodDisruptionBudget，并考虑降低其限制。如需了解详情，请参阅错误：PodDisruptionBudget 不足。
`"no.scale.down.node.pod.controller.not.found"`	Pod 会阻止纵向缩容，因为找不到它的控制器（例如 Deployment 或 ReplicaSet）。	不适用	如需确定在 Pod 的控制器被移除后执行了哪些操作，请查看日志。如需解决此问题，请手动删除 Pod。
`"no.scale.down.node.pod.unexpected.error"`	Pod 由于意外错误而阻止了缩容。	不适用	此错误的根本原因不明。与 Cloud Customer Care 团队联系以进行进一步调查。

查看集群自动扩缩器事件。

要求

查看事件

查看可见性事件日志

查看可见性事件通知

事件类型

Status 事件

示例

ScaleUp 事件

示例

ScaleDown 事件

示例

EventResult 事件

示例

NodePoolCreated 事件

示例

NodePoolDeleted 事件

示例

NoScaleUp 事件

原因字段

示例

NoScaleDown 事件

原因字段

示例

消息

ScaleUp 错误

noScaleUp 事件的原因

NoScaleUp 顶级原因

NoScaleUp 顶级节点自动预配原因

NoScaleUp MIG 级原因

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

ScaleDown 错误

noScaleDown 事件的原因

NoScaleDown 顶级原因

NoScaleDown 节点级原因

后续步骤