本页面介绍了 Google Kubernetes Engine (GKE) 集群自动扩缩器针对自动扩缩的决策。
GKE 集群自动扩缩器会发出可见性事件,这些事件在 Cloud Logging 中可作为日志条目使用。
本指南中介绍的事件与集群自动扩缩器生成的 Kubernetes 事件互不相关。
可用性要求
以下集群版本能够查看集群自动扩缩器的已记录事件:
事件类型 | 集群版本 |
---|---|
status 、scaleUp 、scaleDown 、eventResult |
1.15.4-gke.7 及更高版本 |
nodePoolCreated 、nodePoolDeleted 。 |
1.15.4-gke.18 及更高版本 |
noScaleUp |
1.16.6-gke.3 及更高版本 |
noScaleDown |
1.16.8-gke.2 及更高版本 |
要查看自动扩缩器事件,您必须在集群中启用 Cloud Logging。如果停用 Logging,则不会生成这些事件。
查看事件
集群自动扩缩器的可见性事件存储在 Cloud Logging 日志中,与 GKE 集群在同一项目中。 您还可以在 Google Cloud 控制台的 Google Kubernetes Engine 页面的通知中查看这些事件。
查看可见性事件日志
如需查看日志,请执行以下操作:
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
选择集群的名称以查看其集群详细信息页面。
在集群详细信息页面上,点击日志标签页。
在日志标签页上,点击自动扩缩器日志标签页以查看日志。
(可选)如需应用更高级的过滤条件来缩小结果范围,请点击页面右侧的按钮以在日志浏览器中查看日志。
查看可见性事件通知
如需在 Google Kubernetes Engine 页面上查看可见性事件通知,请执行以下操作:
转到 Google Cloud 控制台中的 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"
}
}
]
}
}
}
您还可以在没有运行工作负载的节点上查看 scale-down
事件(通常只有 DaemonSet 创建的系统 pod)。使用以下查询可查看事件日志:
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"
}
}
}
}
排查扩缩问题
本部分提供有关如何对扩缩事件进行问题排查的指南。
集群未纵向扩容
场景:我在集群中创建了一个 Pod,但它过去一小时中一直处于“待处理”状态。集群自动扩缩器未预配任何新节点来容纳该 Pod。
解决方案:
- 按照查看事件部分中的说明,在日志浏览器中找到集群自动扩缩器事件的日志记录详细信息。
搜索包含
triggeringPods
字段中所需 Pod 的scaleUp
事件。您可以过滤日志条目,包括按特定 JSON 字段值进行过滤。如需了解详情,请参阅高级日志查询。- 查找
eventId
与scaleUp
事件相同的EventResult
。 - 查看
errorMsg
字段并查阅可能出现的 ScaleUp 错误消息列表。
ScaleUp 错误示例:对于
scaleUp
事件,您发现错误为"scale.up.error.quota.exceeded"
,这表示“由于超出配额无法增加某些 MIG,ScaleUp 事件失败”。为了解决此问题,请检查您的配额设置,如发现某些设置即将被超出,则予以提升。集群自动扩缩器会添加新节点,并安排 Pod。- 查找
否则,请搜索
noScaleUp
事件并查看以下字段:unhandledPodGroups
:包含有关 Pod(或 Pod 的控制器)的信息。reason
:提供可能会阻止纵向扩容的全局原因。skippedMigs
:提供可能会跳过某些 MIG 的原因。
请参阅以下部分,了解可能导致
noScaleUp
事件的原因:NoScaleUp 示例:您找到了 Pod 的
noScaleUp
事件,同时rejectedMigs
字段中的所有 MIG 都具有相同的"no.scale.up.mig.failing.predicate"
原因信息 ID 以及下列两个参数:"NodeAffinity"
和"node(s) did not match node selector"
。参阅错误消息列表后,您发现“由于谓语失败,无法对 MIG 进行纵向扩容”;参数为失败的谓词的名称以及失败的原因。为了解决此问题,您查看 Pod 规范,并发现它有一个节点选择器与集群中的任何 MIG 都不匹配。您可以从 Pod 规范中删除选择器,然后重新创建 Pod。集群自动扩缩器会添加新节点,并安排 Pod。如果没有
noScaleUp
事件,请使用其他调试方法来解决该问题。
集群未纵向缩容
场景:我的集群中有一个节点过去几天仅利用了 10% 的 CPU 和内存。尽管利用率低,但集群自动扩缩器未按预期删除该节点。
解决方案:
- 按照查看事件部分中的说明,在日志浏览器中找到集群自动扩缩器事件的日志记录详细信息。
- 搜索包含
nodesToBeRemoved
字段中所需节点的scaleDown
事件。您可以过滤日志条目,包括按特定 JSON 字段值进行过滤。如需了解详情,请参阅高级日志查询。- 在
scaleDown
事件中,搜索包含关联eventId
的EventResult
事件。 - 查看
errorMsg
字段并查阅可能出现的 ScaleDown 错误消息列表。
- 在
- 否则,请搜索具有
nodes
字段中所需节点的noScaleDown
事件。查看reason
字段,了解指示纵向缩容可能会被阻止的所有全局原因。 请参阅以下部分,了解可能导致
noScaleDown
事件的原因:NoScaleDown 示例:您发现了一个
noScaleDown
事件,其中包含节点的按节点原因。消息 ID 为"no.scale.down.node.pod.has.local.storage"
且有一个参数:"test-single-pod"
。查看错误消息列表后,您会发现这表示“Pod 由于请求本地存储而阻止纵向缩容”。您可以参阅 Kubernetes 集群自动扩缩器常见问题解答,找到解决方案是向 Pod 添加"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"
注释。应用注释后,集群自动扩缩器会将集群正确缩容。如果没有
noScaleDown
事件,请使用其他调试方法来解决该问题。
消息
集群自动扩缩器发出的事件使用参数化消息来提供事件说明。parameters
字段与 messageId
字段一起使用,例如 NoScaleUp 事件的示例日志。
本部分提供各种 messageId
的说明及其相应参数。但是,此部分并不包含所有可能的消息,并且可以随时进行扩展。
ScaleUp 错误
scaleUp
事件的错误消息可在相应 eventResult
事件的 resultInfo.results[].errorMsg
字段中找到。
消息 | 说明 | 应对措施 |
---|---|---|
"scale.up.error.out.of.resources" |
由于资源不足,部分 MIG 无法增加,导致 scaleUp 事件失败。 参数:失败 MIG 的 ID。 |
按照资源可用性问题排查步骤进行操作。 |
"scale.up.error.quota.exceeded" |
由于超出了 Compute Engine 配额,部分 MIG 无法增加,导致 ScaleUp 事件失败。 参数:失败 MIG 的 ID。 |
检查 Google Cloud 控制台中 MIG 的错误标签页,查看超出的配额。按照说明申请增加配额。 |
"scale.up.error.waiting.for.instances.timeout" |
某些 MIG 未能及时出现,导致 ScaleUp 事件失败。 参数:失败 MIG 的 ID。 |
此消息是暂时性的。如果问题仍然存在,请联系 Google Cloud 支持团队进行进一步调查。 |
"scale.up.error.ip.space.exhausted" |
由于集群没有足够的未分配 IP 地址空间来用于添加新节点或 Pod,导致 ScaleUp 事件失败。 参数:失败 MIG 的 ID。 |
请参阅问题排查步骤,以解决节点或 Pod 缺少 IP 地址空间的问题。 |
"scale.up.error.service.account.deleted" |
由于集群自动扩缩器使用的服务账号已删除,导致 ScaleUp 事件失败。 参数:失败 MIG 的 ID。 |
联系 Google Cloud 支持团队进行进一步调查。 |
ScaleDown 错误
scaleDown
事件的错误消息可在相应 eventResult
事件的 resultInfo.results[].errorMsg
字段中找到。
消息 | 说明 | 应对措施 |
---|---|---|
"scale.down.error.failed.to.mark.to.be.deleted" |
无法标记节点以供删除,导致 ScaleDown 事件失败。 参数:失败节点的名称。 |
此消息是暂时性的。如果问题仍然存在,请联系 Google Cloud 支持团队进行进一步调查。 |
"scale.down.error.failed.to.evict.pods" |
某些 Pod 无法从节点中逐出,导致 ScaleDown 事件失败。 参数:失败节点的名称。 |
查看 Pod 中断预算的最佳做法,以确保规则允许逐出应用副本(当可接受时)。 |
"scale.down.error.failed.to.delete.node.min.size.reached" |
由于集群已达到最小规模,所以无法删除节点,导致 ScaleDown 事件失败。 参数:失败节点的名称。 |
查看为节点池自动扩缩设置的最小值,并根据需要调整设置。 |
NoScaleUp 事件的原因
NoScaleUp 顶级原因
noScaleUp
事件的顶级原因消息会显示在 noDecisionStatus.noScaleUp.reason
字段中。该消息包含导致集群自动扩缩器无法对集群进行纵向扩容的顶级原因。
消息 | 说明 | 应对措施 | |
---|---|---|---|
"no.scale.up.in.backoff" |
由于目前处于纵向扩容退避期(暂时阻止),所以发生了 NoScaleUp。此消息是暂时性的,可能会在具有大量 pod 的纵向扩容事件期间发生。 | 如果此消息持续存在,请与 Google Cloud 支持团队联系以进行进一步调查。 |
NoScaleUp 顶级节点自动预配原因
noScaleUp
事件的顶级节点自动预配原因消息会显示在 noDecisionStatus.noScaleUp.napFailureReason
字段中。该消息包含导致集群自动扩缩器无法预配新节点池的顶级原因。
消息 | 说明 | 应对措施 |
---|---|---|
"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" |
无法扩缩 MIG,因为它不符合待处理 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 的要求,例如亲和性规则、污点、容忍或资源要求。 |
NoScaleDown 事件的原因
NoScaleDown 顶级原因
noScaleDown
事件的顶级原因消息会显示在 noDecisionStatus.noScaleDown.reason
字段中。该消息包含集群自动扩缩器无法对集群进行纵向缩容的顶级原因。
消息 | 说明 | 应对措施 |
---|---|---|
"no.scale.down.in.backoff" |
由于目前处于纵向缩容退避期(暂时阻止),所以发生了 NoScaleDow 事件。此事件应该是暂时性的,并且会在最近发生纵向扩容事件时发生。 | 按照与无法纵向缩容的较低级别原因关联的缓解步骤操作。解决根本原因后,集群自动扩缩器将退出退避时间。如果消息在解决根本原因后仍然存在,请联系 Google Cloud 支持团队以进行进一步调查。 |
"no.scale.down.in.progress" |
由于目前处于缩减状态,因此前一个计划移除的节点被删除之前,发生了 noScaleDown 事件。 | 此事件应该是暂时性的,因为 Pod 最终会被强制移除。如果此消息频繁出现,您可以查看 Pod 阻止缩减的 gracefulTerminationPeriod 值。如果您希望加快解决速度,还可以强制删除不再需要的 Pod。 |
NoScaleDown 节点级原因
noScaleDown
事件的节点级原因消息会显示在 noDecisionStatus.noScaleDown.nodes[].reason
字段中。该消息包含集群自动扩缩器无法移除特定节点的原因。
消息 | 说明 | 应对措施 |
---|---|---|
"no.scale.down.node.scale.down.disabled.annotation" |
无法移除节点,因为它具有 scale-down-disabled 注解。 |
按照 Kubernetes 集群自动扩缩器常见问题解答中的说明,查看防止缩减的注解。 |
"no.scale.down.node.node.group.min.size.reached" |
无法移除节点,因为其节点组已达到其最小大小。 | 查看并调整为节点池自动扩缩设置的最小值。 |
"no.scale.down.node.minimal.resource.limits.exceeded" |
未充分利用的节点的纵向缩容会被阻止,因为它会违反为节点自动预配设置的集群范围资源下限。 | 查看集群范围的资源下限。 |
"no.scale.down.node.no.place.to.move.pods" |
未充分利用的节点的纵向缩容会被阻止,因为它正在运行的 Pod 无法移动到集群中的其他节点。 | 如果您希望重新调度 Pod,请查看未充分利用的节点上的 Pod 的调度要求,以确定它们是否可以移动到集群中的其他节点。如果您不希望 Pod 被重新调度,因为没有其他节点可以调度它,则预期会出现此消息。 |
"no.scale.down.node.pod.not.backed.by.controller" |
Pod 会阻止缩容未充分利用的节点,因为 Pod 没有 Kubernetes 集群自动扩缩器已知的控制器(ReplicationController、DaemonSet、Job、StatefulSet 或 ReplicaSet)。详细了解 Kubernetes 集群自动扩缩器常见问题解答,了解哪些类型的 Pod 可能会阻止集群自动扩缩器移除节点。 参数:阻止 Pod 的名称。 |
为 Pod 设置注解 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 或定义控制器(ReplicationController、DaemonSet、Job、StatefulSet 或 ReplicaSet)。 |
"no.scale.down.node.pod.has.local.storage" |
Pod 由于请求本地存储而阻止纵向缩容。详细了解 Kubernetes 集群自动扩缩器常见问题解答,了解哪些类型的 Pod 可能会阻止集群自动扩缩器移除节点。 参数:阻止 Pod 的名称。 |
如果 Pod 的本地存储空间中的数据不重要,请为 Pod 设置注解 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 。 |
"no.scale.down.node.pod.not.safe.to.evict.annotation" |
Pod 由于具有注释“无法安全逐出”而阻止纵向缩容。如需了解详情,请参阅 Kubernetes 集群自动扩缩器常见问题解答。
参数:阻止 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 的名称。 |
按照 Kubernetes 集群自动扩缩器常见问题解答中的说明设置 PodDisruptionBudget ,以允许集群自动扩缩器移动 kube-system 命名空间中的 Pod。 |
"no.scale.down.node.pod.not.enough.pdb" |
Pod 没有足够的 PodDisruptionBudget ,所以它会阻止纵向缩容。如需了解详情,请参阅 Kubernetes 集群自动扩缩器常见问题解答。参数:阻止 Pod 的名称。 |
查看 Pod 的 PodDisruptionBudget ,请参阅 PodDisruptionBudget 的最佳做法。如需解决该消息,您可以扩缩应用或更改 PodDisruptionBudget 以允许更多不可用的 Pod。 |
"no.scale.down.node.pod.controller.not.found" |
Pod 会阻止纵向缩容,因为找不到它的控制器(例如 Deployment 或 ReplicaSet)。 | 查看日志以确定在 Pod 的控制器被移除后执行了哪些操作。如需解决此问题,您可以手动删除 Pod。 |
"no.scale.down.node.pod.unexpected.error" |
未充分利用的节点的纵向缩减会被阻止,因为它有处于意外错误状态的 Pod。 | 与 GCP 支持团队联系以进行进一步调查。 |