Kubernetes Cluster Autoscaler 集群状态注册表Cluster State Registry设计解析从不可用即停摆到带病容错的演进【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler导读本文基于 autoscaler 仓库中 Kubernetes Cluster AutoscalerCA的官方设计提案 clusterstate.md系统讲解 CA 如何通过集群状态注册表Cluster State Registry应对节点不可用unready场景。提案针对早期版本 CA云端节点数与 K8s Ready 节点数不一致就整体停摆的缺陷设计了一套从集群健康度评估、节点组健康度评估、预期到达节点记账、缺失节点时长追踪四个维度出发的自愈式主循环算法。读完本文你将掌握 8 类不可用节点场景UC1~UC8的判别特征与处置动作、状态注册表提供的 4 类关键信息S1~S4、9 步主循环算法的执行顺序以及在当前仓库源码与命令行参数中的落地方式。一、背景为什么 CA 曾经一遇到不可用节点就停摆在 Kubernetes Cluster Autoscaler 的第一个版本中只要云端如云厂商的 MIG / ASG 一侧观测到的节点数量与 Kubernetes 侧 Ready 节点的数量不一致CA 就会停止一切伸缩操作。这一设计初衷是防止 CA 在已经出问题的集群上越帮越忙、扩大故障。然而社区的客户端反馈表明这种行为在许多场景下是次优的甚至让运维人员感到困惑一次正常的扩容操作会瞬间破坏两侧数量一致的前提导致 CA 自己把正常扩容冻结节点启动慢、注册慢、云配额不足等常见情况被一视同仁地当作集群故障处理运维人员无法区分节点正在路上节点启动失败节点彻底失联等截然不同的状况。本提案由 Cluster Autoscaler 团队撰写定稿于 K8s 后续版本发布前正是要废除数量不一致即停摆的简单策略改为让 CA 精确感知每个节点的状态与因果从而在大部分场景下继续安全操作仅在真正全局性故障时才暂停。二、8 类不可用节点使用场景Use Cases提案将Ready 节点数与云端节点数不一致分解为 8 个相互独立、可判别的场景每个场景都给出了判别特征Indicating factors与建议动作Suggested action。UC1节点已扩容、尚未注册扩容进行中节点组规模已增大但新节点尚未在云侧创建 / 启动 / 注册到 K8s在 GCP 上通常需要几分钟。判别特征过去几分钟内发生过扩容缺失节点数不超过本次扩容的规模。建议动作继续运行但在所有扩容计算中把即将到达的节点计入资源占用。UC2节点已注册、尚未 Ready注册后初始化中节点已在集群中注册但尚未切换为 Ready 状态通常几秒内即可恢复。判别特征不可用节点是新节点CreateTime 在最近几分钟内。建议动作同 UC1继续运行并把即将 Ready 的节点纳入扩容考量。UC3节点启动超时注册成功但无法完成启动节点已注册到 K8s但在合理时间内未能完全启动短期内大概率无法恢复。判别特征节点处于 unready且 CreateTime 等于 unready NodeCondition 的 LastTransitionTime即从创建起就一直未 Ready。建议动作继续运行但不要扩展该节点池该节点大概率会在闲置足够久后被缩容清理见 UC5 / UC6。UC4云侧无法供给节点配额或技术问题云侧在合理时间内无法供给节点常见原因是配额不足或技术故障。判别特征云侧目标节点数持续超过几分钟大于 K8s 内节点数且差值不再变化在云侧列举节点时看不到任何新增节点。建议动作将该问题节点组的目标规模缩减到当前实际规模即把虚标的容量修正回来。UC5节点供给成功但注册失败云侧已创建节点但节点始终没有注册进 K8s。判别特征云侧存在长时间未出现在 K8s 中的新节点。建议动作逐个删除这些未注册节点。UC6节点长期不可用20 分钟以上节点进入不可用状态超过 20 分钟且集群中不可用/未出现节点总数占比很低低于 XX%通常是节点上发生无法自愈的崩溃。判别特征节点 condition 为 unready 且 LastTransitionTime 距今 ≥ 20 分钟K8s 中总节点数等于云侧目标节点数。建议动作将该节点纳入缩容候选但使用更大的可配置的非必需unneeded时长并且仅在节点控制器已将其上所有 Pod 驱逐完毕后执行。UC7CA 主动删除的节点节点正被 Cluster Autoscaler 移除。判别特征节点 unready 且带有ToBeRemovedtaint。建议动作继续运行节点很快会被删除。UC8大面积非合理不可用网络分区或全局故障与扩容、缩容无关的不可用节点占比超过 XX%说明集群可能遭遇网络分区或通用性故障。判别特征超过 XX% 的节点 unready。建议动作暂停所有操作并告警系统管理员。其中 UC1~UC5 聚焦数量不足侧的节点到达问题UC6~UC8 聚焦存量节点失联侧的稳定性问题二者共同构成状态注册表设计的输入全集。三、提案方案集群状态注册表Cluster State Registry提案的核心是引入一个集群状态注册表Cluster State Registry对外提供 4 类关键信息S1~S4作为 CA 主循环决策的依据编号提供的信息含义与用途S1集群整体是否足够健康以允许 CA 运行若大部分节点处于 Ready、且非合理与伸缩无关的不可用节点数量受限则集群健康。集群不健康时 CA 应暂停操作并告警系统管理员对应 UC8S2给定节点组是否足够健康以允许 CA 对其操作若某节点组中不可用非因当前伸缩引起或完全未出现云侧尚未启动的节点数量受限则该组健康。CA 应对不健康节点组格外小心在其状况改善前不再继续扩容对应 UC3S3哪些节点即将到达集群供估算器estimator将其计入资源占用避免为已被这些节点覆盖的 Pod 重复申请资源同时估算器无需再等待节点真正出现在集群中对应 UC1、UC2S4节点组缺失节点持续了多久若固定数量的节点长时间缺失可能暗示配额问题应将此类节点组缩容到实际规模对应 UC4在此基础上CA 将在集群中可能存在不可用节点的前提下照常工作这类节点会被缩容逻辑选中因为 Kubernetes 的 controller-manager 最终会从不可用节点上驱逐所有 Pod因此若这些节点不能恢复健康在不可用足够久之后都会被移除并可能被新节点替换。四、主循环算法9 步迭代流程提案给出重构后的 CA 主循环算法其核心思想是每一步都只处理一类明确界定的问题且多数情况下继续前进而非整体停摆获取全部节点从集群中拉取所有节点列表。集群健康度检查用 S1对应 UC8若集群整体不健康大部分节点未 Ready则告警用户、跳过本轮迭代并等待 10 秒同时清空第 8、9 步维护的 unneeded 统计防止把故障期误算成闲置期。清理注册失败的节点对应 UC5检查各节点组是否存在注册失败的节点若存在则逐个删除。修正长期缺失节点的节点组用 S4对应 UC4若节点组存在长期缺失节点则将节点组规模按缺失数缩减然后跳过本轮的剩余步骤。检查待调度 Podpending pods先剔除那些可以被当前 Ready 节点不包括即将被删除的节点见 UC7调度的 Pod。筛选可扩容节点组用 S2对应 UC3对仍无法调度的 Pod找出可扩容的节点组跳过不健康的节点组含大量不可用节点或启动失败节点。估算所需节点数并扩容用 S3对应 UC1、UC2估算所需节点数时扣除即将到达的节点然后按需扩容选中的节点组。计算全集群 unneeded 节点对应 UC6包括不可用节点在内统计非必需节点这些节点必须在每轮迭代中被持续监控以确保它们已非必需足够长时间而不是某一瞬的误判。尝试删除 unneeded 节点若近期没有扩容且节点非必需超过 10 分钟则尝试删除不可用节点使用更高的延迟阈值即 UC6 所述的可配置更长 unneeded 时间。算法的节奏是边操作边观察第 2 步的 10 秒等待、第 9 步的 10 分钟延迟、第 8 步的持续监控共同保证 CA 不会在节点短暂异常时做出不可逆的破坏性动作。五、在仓库源码与参数中的落地印证该提案虽然描述的是设计蓝图但当前仓库的 Cluster Autoscaler 实现已经将其核心思想落地为可配置的行为以下证据可以帮助你把提案与实际运行行为对应起来。5.1 不可用节点容忍度集群健康门槛对应 S1 / UC8提案中的集群健康阈值 XX%在实现中体现为两个 flag见 FAQ.md 的 flag 列表与CA 如何处理不可用节点一节--max-total-unready-percentage集群中不可用节点的最大百分比超过后 CA 停止所有操作默认 45--ok-total-unready-count允许的不可用节点绝对数量不受百分比限制的兜底默认 3。FAQ 中明确说明早期 CA 1.2.1 及更早版本默认容忍 33% 或最多 3 个不可用节点取较大者此后改为由上述两个 flag 配置当不可用节点超过阈值时CA 停止一切操作直到情况好转。这正是提案 S1集群不健康则 halt 告警UC8的工程化实现。在 Helm 部署中这两个参数同样可通过 charts/cluster-autoscaler/values.yaml 配置。5.2 未注册节点与缺失节点的清理对应 UC4 / UC5--max-node-provision-time节点从创建到出现在集群中的最大等待时间超时后 CA 停止在扩容模拟中考虑这些节点并可能触发补扩超过该时间仍未注册的节点会被处理见 FAQ.md 中未注册节点相关章节。--force-delete-unregistered-nodes是否强制删除长期未注册节点无论它们所属节点组的最小规模min size是多少。这对应提案 UC5逐个删除未注册节点的建议动作且提供了突破节点组 min size 限制的开关。5.3 不可用节点的缩容策略对应 UC6 / UC7--scale-down-unready-enabled是否允许 CA 缩容不可用节点默认 true--scale-down-unready-time不可用节点在被判定为非必需后需等待多久才具备缩容资格默认 20m0s。这两个 flag 精确对应提案 UC6对不可用节点使用更大可配置的 unneeded 时间以及仅在节点控制器已驱逐其全部 Pod 后缩容。而 UC7 中提到的ToBeRemovedtaint 在实现中同样被各云厂商缓存与节点状态追踪所识别例如 gce/cache.go 中维护的 MIG 实例状态计数缓存migInstancesStateCountCache以及 azure、tencentcloud 等提供商的缓存实现确保被 CA 标记删除的节点不会在步骤 5 中被当作可用调度资源。5.4 从源码结构看状态感知的实现形态从源码结构看提案中注册表所需的两类原始数据——K8s 侧节点状态与云侧节点供给状态——在实现中由两层协同提供云侧缓存层以 gce/cache.go 为代表的GceCache维护 MIG 列表、实例列表、MIG 与实例的映射、目标规模migTargetSizeCache、实例状态计数migInstancesStateCountCache等并用互斥锁保证并发安全从而支撑 UC4/UC5 所需的云侧目标规模 vs 实际实例对比K8s 节点状态层CA 主循环从集群 API 获取节点与 NodeConditionReady / unready / LastTransitionTime配合 taint如ToBeRemoved与节点创建时间即可完成 UC1~UC3、UC6~UC8 的判别特征匹配。可以推断提案中统一抽象的Cluster State Registry最终演化为分布在核心主循环与各云提供商缓存中的一系列状态采集与健康判定逻辑其对外可见的形态就是上述一组可调参数与主循环中的健康检查步骤。六、参数速查表以下汇总提案相关行为在 FAQ.md 中列出的核心 flag默认值以当前仓库为准Flag作用默认值--max-total-unready-percentage集群不可用节点最大百分比超过则 CA 暂停操作45--ok-total-unready-count允许的不可用节点绝对数量不受百分比限制3--scale-down-unready-enabled是否允许缩容不可用节点true--scale-down-unready-time不可用节点满足非必需后等待多久才可被缩容20m0s--max-node-provision-time节点创建后等待其出现在集群中的最大时长超时后停止在模拟中考虑并可能补扩15m0s见 FAQ 说明--force-delete-unregistered-nodes是否强制删除长期未注册节点无视节点组 min sizefalse说明以上 flag 均可在 CA 部署的启动参数如 Helm values 中的extraArgs或部署清单中的 command 参数中配置不同云提供商的部署清单示例可参见各 provider 的examples/目录如 gce 部署相关文档 与 charts/cluster-autoscaler/values.yaml。七、设计要点总结从全有或全无到分级容错旧策略因数量不一致就整体停摆新设计将不一致细分为 8 类场景绝大多数场景下 CA 继续运行只有全局性故障UC8才暂停。预期到达节点参与资源记账S3估算器把即将到达的节点算作已占用资源避免重复扩容也无需等待节点真正出现缩短扩容决策延迟。健康门槛分级S1/S2集群级健康门槛负责全局安全阀节点组级健康门槛负责局部免疫不健康节点组不再被继续扩容UC3。对虚标容量主动纠偏S4/UC4长期缺失节点的节点组会被缩容到实际规模避免 CA 永远朝着一个永远无法满足的目标扩容。不可用节点进入缩容管线UC6不可用节点只是更晚、更谨慎地被缩容而不是永远无人处理--scale-down-unready-time提供了可配置的延迟配合 controller-manager 的 Pod 驱逐行为完成闭环。该设计提案为后续 Cluster Autoscaler 的带病工作能力奠定了基础其思想——把抽象的数量不一致细化为可判别的具体场景、为每个场景分配明确的判别特征与动作——至今仍是分析 CA 行为与排障例如通过 FAQ.md 中集群健康状态检查指引的重要心智模型。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes Cluster Autoscaler 集群状态注册表（Cluster State Registry）设计解析：从“不可用即停摆“到“带病容错“的演进
Kubernetes Cluster Autoscaler 集群状态注册表Cluster State Registry设计解析从不可用即停摆到带病容错的演进【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler导读本文基于 autoscaler 仓库中 Kubernetes Cluster AutoscalerCA的官方设计提案 clusterstate.md系统讲解 CA 如何通过集群状态注册表Cluster State Registry应对节点不可用unready场景。提案针对早期版本 CA云端节点数与 K8s Ready 节点数不一致就整体停摆的缺陷设计了一套从集群健康度评估、节点组健康度评估、预期到达节点记账、缺失节点时长追踪四个维度出发的自愈式主循环算法。读完本文你将掌握 8 类不可用节点场景UC1~UC8的判别特征与处置动作、状态注册表提供的 4 类关键信息S1~S4、9 步主循环算法的执行顺序以及在当前仓库源码与命令行参数中的落地方式。一、背景为什么 CA 曾经一遇到不可用节点就停摆在 Kubernetes Cluster Autoscaler 的第一个版本中只要云端如云厂商的 MIG / ASG 一侧观测到的节点数量与 Kubernetes 侧 Ready 节点的数量不一致CA 就会停止一切伸缩操作。这一设计初衷是防止 CA 在已经出问题的集群上越帮越忙、扩大故障。然而社区的客户端反馈表明这种行为在许多场景下是次优的甚至让运维人员感到困惑一次正常的扩容操作会瞬间破坏两侧数量一致的前提导致 CA 自己把正常扩容冻结节点启动慢、注册慢、云配额不足等常见情况被一视同仁地当作集群故障处理运维人员无法区分节点正在路上节点启动失败节点彻底失联等截然不同的状况。本提案由 Cluster Autoscaler 团队撰写定稿于 K8s 后续版本发布前正是要废除数量不一致即停摆的简单策略改为让 CA 精确感知每个节点的状态与因果从而在大部分场景下继续安全操作仅在真正全局性故障时才暂停。二、8 类不可用节点使用场景Use Cases提案将Ready 节点数与云端节点数不一致分解为 8 个相互独立、可判别的场景每个场景都给出了判别特征Indicating factors与建议动作Suggested action。UC1节点已扩容、尚未注册扩容进行中节点组规模已增大但新节点尚未在云侧创建 / 启动 / 注册到 K8s在 GCP 上通常需要几分钟。判别特征过去几分钟内发生过扩容缺失节点数不超过本次扩容的规模。建议动作继续运行但在所有扩容计算中把即将到达的节点计入资源占用。UC2节点已注册、尚未 Ready注册后初始化中节点已在集群中注册但尚未切换为 Ready 状态通常几秒内即可恢复。判别特征不可用节点是新节点CreateTime 在最近几分钟内。建议动作同 UC1继续运行并把即将 Ready 的节点纳入扩容考量。UC3节点启动超时注册成功但无法完成启动节点已注册到 K8s但在合理时间内未能完全启动短期内大概率无法恢复。判别特征节点处于 unready且 CreateTime 等于 unready NodeCondition 的 LastTransitionTime即从创建起就一直未 Ready。建议动作继续运行但不要扩展该节点池该节点大概率会在闲置足够久后被缩容清理见 UC5 / UC6。UC4云侧无法供给节点配额或技术问题云侧在合理时间内无法供给节点常见原因是配额不足或技术故障。判别特征云侧目标节点数持续超过几分钟大于 K8s 内节点数且差值不再变化在云侧列举节点时看不到任何新增节点。建议动作将该问题节点组的目标规模缩减到当前实际规模即把虚标的容量修正回来。UC5节点供给成功但注册失败云侧已创建节点但节点始终没有注册进 K8s。判别特征云侧存在长时间未出现在 K8s 中的新节点。建议动作逐个删除这些未注册节点。UC6节点长期不可用20 分钟以上节点进入不可用状态超过 20 分钟且集群中不可用/未出现节点总数占比很低低于 XX%通常是节点上发生无法自愈的崩溃。判别特征节点 condition 为 unready 且 LastTransitionTime 距今 ≥ 20 分钟K8s 中总节点数等于云侧目标节点数。建议动作将该节点纳入缩容候选但使用更大的可配置的非必需unneeded时长并且仅在节点控制器已将其上所有 Pod 驱逐完毕后执行。UC7CA 主动删除的节点节点正被 Cluster Autoscaler 移除。判别特征节点 unready 且带有ToBeRemovedtaint。建议动作继续运行节点很快会被删除。UC8大面积非合理不可用网络分区或全局故障与扩容、缩容无关的不可用节点占比超过 XX%说明集群可能遭遇网络分区或通用性故障。判别特征超过 XX% 的节点 unready。建议动作暂停所有操作并告警系统管理员。其中 UC1~UC5 聚焦数量不足侧的节点到达问题UC6~UC8 聚焦存量节点失联侧的稳定性问题二者共同构成状态注册表设计的输入全集。三、提案方案集群状态注册表Cluster State Registry提案的核心是引入一个集群状态注册表Cluster State Registry对外提供 4 类关键信息S1~S4作为 CA 主循环决策的依据编号提供的信息含义与用途S1集群整体是否足够健康以允许 CA 运行若大部分节点处于 Ready、且非合理与伸缩无关的不可用节点数量受限则集群健康。集群不健康时 CA 应暂停操作并告警系统管理员对应 UC8S2给定节点组是否足够健康以允许 CA 对其操作若某节点组中不可用非因当前伸缩引起或完全未出现云侧尚未启动的节点数量受限则该组健康。CA 应对不健康节点组格外小心在其状况改善前不再继续扩容对应 UC3S3哪些节点即将到达集群供估算器estimator将其计入资源占用避免为已被这些节点覆盖的 Pod 重复申请资源同时估算器无需再等待节点真正出现在集群中对应 UC1、UC2S4节点组缺失节点持续了多久若固定数量的节点长时间缺失可能暗示配额问题应将此类节点组缩容到实际规模对应 UC4在此基础上CA 将在集群中可能存在不可用节点的前提下照常工作这类节点会被缩容逻辑选中因为 Kubernetes 的 controller-manager 最终会从不可用节点上驱逐所有 Pod因此若这些节点不能恢复健康在不可用足够久之后都会被移除并可能被新节点替换。四、主循环算法9 步迭代流程提案给出重构后的 CA 主循环算法其核心思想是每一步都只处理一类明确界定的问题且多数情况下继续前进而非整体停摆获取全部节点从集群中拉取所有节点列表。集群健康度检查用 S1对应 UC8若集群整体不健康大部分节点未 Ready则告警用户、跳过本轮迭代并等待 10 秒同时清空第 8、9 步维护的 unneeded 统计防止把故障期误算成闲置期。清理注册失败的节点对应 UC5检查各节点组是否存在注册失败的节点若存在则逐个删除。修正长期缺失节点的节点组用 S4对应 UC4若节点组存在长期缺失节点则将节点组规模按缺失数缩减然后跳过本轮的剩余步骤。检查待调度 Podpending pods先剔除那些可以被当前 Ready 节点不包括即将被删除的节点见 UC7调度的 Pod。筛选可扩容节点组用 S2对应 UC3对仍无法调度的 Pod找出可扩容的节点组跳过不健康的节点组含大量不可用节点或启动失败节点。估算所需节点数并扩容用 S3对应 UC1、UC2估算所需节点数时扣除即将到达的节点然后按需扩容选中的节点组。计算全集群 unneeded 节点对应 UC6包括不可用节点在内统计非必需节点这些节点必须在每轮迭代中被持续监控以确保它们已非必需足够长时间而不是某一瞬的误判。尝试删除 unneeded 节点若近期没有扩容且节点非必需超过 10 分钟则尝试删除不可用节点使用更高的延迟阈值即 UC6 所述的可配置更长 unneeded 时间。算法的节奏是边操作边观察第 2 步的 10 秒等待、第 9 步的 10 分钟延迟、第 8 步的持续监控共同保证 CA 不会在节点短暂异常时做出不可逆的破坏性动作。五、在仓库源码与参数中的落地印证该提案虽然描述的是设计蓝图但当前仓库的 Cluster Autoscaler 实现已经将其核心思想落地为可配置的行为以下证据可以帮助你把提案与实际运行行为对应起来。5.1 不可用节点容忍度集群健康门槛对应 S1 / UC8提案中的集群健康阈值 XX%在实现中体现为两个 flag见 FAQ.md 的 flag 列表与CA 如何处理不可用节点一节--max-total-unready-percentage集群中不可用节点的最大百分比超过后 CA 停止所有操作默认 45--ok-total-unready-count允许的不可用节点绝对数量不受百分比限制的兜底默认 3。FAQ 中明确说明早期 CA 1.2.1 及更早版本默认容忍 33% 或最多 3 个不可用节点取较大者此后改为由上述两个 flag 配置当不可用节点超过阈值时CA 停止一切操作直到情况好转。这正是提案 S1集群不健康则 halt 告警UC8的工程化实现。在 Helm 部署中这两个参数同样可通过 charts/cluster-autoscaler/values.yaml 配置。5.2 未注册节点与缺失节点的清理对应 UC4 / UC5--max-node-provision-time节点从创建到出现在集群中的最大等待时间超时后 CA 停止在扩容模拟中考虑这些节点并可能触发补扩超过该时间仍未注册的节点会被处理见 FAQ.md 中未注册节点相关章节。--force-delete-unregistered-nodes是否强制删除长期未注册节点无论它们所属节点组的最小规模min size是多少。这对应提案 UC5逐个删除未注册节点的建议动作且提供了突破节点组 min size 限制的开关。5.3 不可用节点的缩容策略对应 UC6 / UC7--scale-down-unready-enabled是否允许 CA 缩容不可用节点默认 true--scale-down-unready-time不可用节点在被判定为非必需后需等待多久才具备缩容资格默认 20m0s。这两个 flag 精确对应提案 UC6对不可用节点使用更大可配置的 unneeded 时间以及仅在节点控制器已驱逐其全部 Pod 后缩容。而 UC7 中提到的ToBeRemovedtaint 在实现中同样被各云厂商缓存与节点状态追踪所识别例如 gce/cache.go 中维护的 MIG 实例状态计数缓存migInstancesStateCountCache以及 azure、tencentcloud 等提供商的缓存实现确保被 CA 标记删除的节点不会在步骤 5 中被当作可用调度资源。5.4 从源码结构看状态感知的实现形态从源码结构看提案中注册表所需的两类原始数据——K8s 侧节点状态与云侧节点供给状态——在实现中由两层协同提供云侧缓存层以 gce/cache.go 为代表的GceCache维护 MIG 列表、实例列表、MIG 与实例的映射、目标规模migTargetSizeCache、实例状态计数migInstancesStateCountCache等并用互斥锁保证并发安全从而支撑 UC4/UC5 所需的云侧目标规模 vs 实际实例对比K8s 节点状态层CA 主循环从集群 API 获取节点与 NodeConditionReady / unready / LastTransitionTime配合 taint如ToBeRemoved与节点创建时间即可完成 UC1~UC3、UC6~UC8 的判别特征匹配。可以推断提案中统一抽象的Cluster State Registry最终演化为分布在核心主循环与各云提供商缓存中的一系列状态采集与健康判定逻辑其对外可见的形态就是上述一组可调参数与主循环中的健康检查步骤。六、参数速查表以下汇总提案相关行为在 FAQ.md 中列出的核心 flag默认值以当前仓库为准Flag作用默认值--max-total-unready-percentage集群不可用节点最大百分比超过则 CA 暂停操作45--ok-total-unready-count允许的不可用节点绝对数量不受百分比限制3--scale-down-unready-enabled是否允许缩容不可用节点true--scale-down-unready-time不可用节点满足非必需后等待多久才可被缩容20m0s--max-node-provision-time节点创建后等待其出现在集群中的最大时长超时后停止在模拟中考虑并可能补扩15m0s见 FAQ 说明--force-delete-unregistered-nodes是否强制删除长期未注册节点无视节点组 min sizefalse说明以上 flag 均可在 CA 部署的启动参数如 Helm values 中的extraArgs或部署清单中的 command 参数中配置不同云提供商的部署清单示例可参见各 provider 的examples/目录如 gce 部署相关文档 与 charts/cluster-autoscaler/values.yaml。七、设计要点总结从全有或全无到分级容错旧策略因数量不一致就整体停摆新设计将不一致细分为 8 类场景绝大多数场景下 CA 继续运行只有全局性故障UC8才暂停。预期到达节点参与资源记账S3估算器把即将到达的节点算作已占用资源避免重复扩容也无需等待节点真正出现缩短扩容决策延迟。健康门槛分级S1/S2集群级健康门槛负责全局安全阀节点组级健康门槛负责局部免疫不健康节点组不再被继续扩容UC3。对虚标容量主动纠偏S4/UC4长期缺失节点的节点组会被缩容到实际规模避免 CA 永远朝着一个永远无法满足的目标扩容。不可用节点进入缩容管线UC6不可用节点只是更晚、更谨慎地被缩容而不是永远无人处理--scale-down-unready-time提供了可配置的延迟配合 controller-manager 的 Pod 驱逐行为完成闭环。该设计提案为后续 Cluster Autoscaler 的带病工作能力奠定了基础其思想——把抽象的数量不一致细化为可判别的具体场景、为每个场景分配明确的判别特征与动作——至今仍是分析 CA 行为与排障例如通过 FAQ.md 中集群健康状态检查指引的重要心智模型。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考