GKE ComputeClass 优先级与回退机制遍历逻辑、priorityScore 同分裁决与冷却回退设计【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文基于 skills 仓库中gke-compute-classes技能包的优先级参考文档 compute-class-prioritization.md系统讲解 GKE ComputeClass 的priorities[]优先级遍历顺序、priorityScore同分裁决规则、5 分钟固定冷却与回退fallback机制以及人工节点池、DWS FlexStart、min-nodes等场景下的常见陷阱。读完后你可以掌握如何为推理、训练、批处理、延迟敏感型等不同工作负载设计正确的优先级梯级如何规避冷却级联导致的回退失效并理解 GKE 各版本1.35.2、1.36、1.36.3在冷却域与容量获取判断上的行为差异。优先级遍历顺序求值与冷却ComputeClass 的priorities[]数组是 Cluster Autoscaler 扩容决策的梯级rung。核心遍历规则如下顺序求值Sequential规则从上到下逐条评估。某个无法获取unobtainable的机型形状进入5 分钟冷却。优先级列表应保持紧凑建议控制在6–8 级以内。无分数时的平局裁决Tie-break, No Score当未使用priorityScore时最高条目胜出若多条规则匹配同一求值条件单位成本最低者胜出。priorityScore裁决GKE 1.35.2取值为 1–1000 的整数分数越高优先级越高。关键约束有三条若其中一条规则设置了priorityScore则所有规则都必须设置同一个分数最多允许3 条规则同分规则被放在一起评估以最低单位成本胜出。同分区规则的轮询均衡Round-Robin由于 GKE 预留reservations是分区zonal的若要在多个可用区如us-central1-a、b、c之间实现均衡扩容可以为每个可用区单独定义一条优先级规则并赋予它们完全相同的priorityScore。GKE 会把这些同分规则放在一起评估执行轮询选择round-robin selection从而在多个可用区间实现大致均衡的节点分布。注意该方式要求为每个可用区使用独立的预留名称reservation name per zone。这一机制在 SKILL.md 中也有对应的硬性约束同一个priorityScore最多覆盖 3 条优先级绝不应输出超过 3 条同分规则当用户要求更多例如5 个机型全部按最便宜的时应截断到 3 条并解释原因。值得对照的完整示例是 equal-priority-tiebreak-compute-class.yaml无状态 Web 层要求 GKE 1.35.2-gke.1842000顶层 Score 100 分组了三个可互换的 Gen-4 机型族c4d / c4 / n4中间层 Score 50 是两个 Gen-2 回退族n2 / n2d底层 Score 10 是覆盖最多可用区的 e2 兜底。注释明确指出Same-score rules are evaluated together, not strictly sequentially — tie-break is by lowest unit cost同分规则被一起评估而非严格顺序执行裁决依据为最低单位成本。配合priorityDefaults.location声明的可用区列表与locationPolicy: ANY以及末尾的whenUnsatisfiable: ScaleUpAnyway构成了一个可复制的同分裁决模板。若集群版本低于 1.35.2无priorityScore支持balanced-reserved-zonal-compute-class.yaml 给出了替代路径用单个优先级条目命名所有分区预留reservations.specific[]内每个可用区一条namezones并设置location.locationPolicy: BALANCED。该模板注释特别强调不要把分区拆成多条优先级per-zone priorities are sequential and drain zone-a before zone-b顺序求值会先耗尽 zone-a同时location.zones不能与affinity: Specific组合会报 location config with specific reservations enabled 错误分区范围只能来自reservations.specific[].zones。冷却与回退机制的实际行为这是优先级设计中影响扩容成功率的核心部分原文档给出了六条机制级事实1. 5 分钟固定冷却5-Minute Fixed Cooldown当扩容因缺货scale.up.error.out.of.resources/ZONE_RESOURCE_POOL_EXHAUSTED失败时Cluster Autoscaler 会对该优先级规则施加 5 分钟冷却。与标准节点池 MIG 的指数退避不同这个冷却是固定的fixed不做指数递增。2. 跨梯级的冷却延长Cooldown Prolongation Across Rungs当缺货沿优先级梯级逐级向下发生时每次失败都会重置该 ComputeClass 中所有此前失败梯级的 5 分钟冷却计时器。其效果是把 Cluster Autoscaler 向前推——尽快推进到第一个可获取的优先级而不是在各级 MIG 退避到期后立刻从顶端重新开始。3. 回退兜底的安全保证Fallback Floor Safety Guaranteepriorities[]的最后一条优先级规则以及隐式的ScaleUpAnyway规则永远不会被ComputeClass 冷却退避从而保证始终存在一个活跃的回退兜底层。4. 分区冷却域 vs 区域冷却域Zonal vs Regional Cooldown Scope旧版行为GKE 1.36.3-gke.1244000声明式规则上单个可用区的缺货会触发该优先级层级在整个区域所有可用区上的约 5 分钟区域级regional冷却新版行为GKE ≥ 1.36.3-gke.1244000缺货冷却严格限定为分区级zonal——只有失败的可用区进入冷却健康可用区继续为该优先级层级供货。配额错误QUOTA_EXHAUSTED在所有版本中仍保持区域级。5. 分区冷却级联Cascades及其缓解根因无分区约束的 Pod 配合locationPolicy: BALANCED本身不会触发性级联autoscaler 会把扩容倾斜到健康可用区。级联到底层兜底发生在分区受限工作负载绑定分区 PersistentVolume 的 Pod或带有刚性分区nodeSelector/affinity 的 Pod在缺货可用区索要容量时——这迫使求值向后续回退梯级推进。缓解 1中间梯级在梯级中插入中间机型族如c4→c3→n4→n2d避免从稀缺硬件直接跌落到基线e2/n2d缓解 2有状态负载隔离将有状态、分区受限的工作负载隔离到独立的 ComputeClass与无状态集群fleet分离缓解 3dynamic-rwoStorageClass为有状态负载使用dynamic-rwotype: dynamicuse-allowed-disk-topology: true实现磁盘拓扑感知的扩容。该仓库中的 dynamic-rwo-storageclass.yaml 对这一机制做了源码级注释type: dynamic让一个 StorageClass 可以同时支撑 Persistent DiskGen 2或 HyperdiskGen 4use-allowed-disk-topology: true使 Cluster Autoscaler 读取负载的磁盘需求后只为磁盘兼容的节点选项扩容跳过代际不兼容的优先级而不是先建节点再让 PV 挂载失败。该内置 StorageClass 要求 GKE 1.35.3-gke.1290000控制面与节点池且volumeBindingMode: WaitForFirstConsumer保证磁盘在所选节点的可用区内创建。6. 同步容量获取判断GKE 1.36 Synchronous Obtainability自 GKE 1.36 起Cluster Autoscaler 在发起 VM 创建调用之前会在内存中同步查询内部容量获取服务capacity obtainability service从而直接跳过当前已耗尽的机型族——不产生 GCE API 错误也不触发 5 分钟冷却。这从实现层面削弱了缺货退避对梯级推进的干扰。手工节点池、FlexStart 与 min-nodes 三大陷阱原文档还指出三个会直接破坏优先级语义的陷阱这里逐条展开手工nodepools优先级的陷阱ManualnodepoolsPriority Traps通过priorities[].nodepools引用现存手工节点池的规则不享受ComputeClass 冷却延长机制只能依赖标准的 5 分钟 GCE MIG 退避当手工池列表膨胀例如跨多个可用区 10 个池时上层的 MIG 退避会在求值到达低层之前就已过期导致 Cluster Autoscaler 不断回到优先级列表顶端循环永远到不了低层最佳实践优先使用声明式machineFamily规则并开启nodePoolAutoCreation.enabled: true若必须使用手工池将手工池总数控制在6–8 个以内。仓库中的 manual-pole-tiebreak-compute-class.yamlpinned-pools-tiebreak演示了正确的手工池用法第一级引用三个每区一个的预建 On-Demand n4 池同池条目为等价候选按单位成本/可用性挑选第二级是两个 Spot 池第三级是machineFamily: n4的自动创建兜底。注释还明确了绑定约束——每个手工池必须同时携带cloud.google.com/compute-classpinned-pools-tiebreak的label 和 taint才能绑定到 ComputeClass且该模式仅限 Standard 集群Autopilot 不支持nodepools:引用。flexStart排序规则Ordering RuleDWS Flex Start 优先级使用排队容量供应返回缺货信号需要 3–15 分钟以上。如果把它放在priorities[]的高位或中段队列等待期间高优先级的退避会全部过期把 Cluster Autoscaler 重置回梯级顶端。最佳实践flexStart: true永远放在priorities[]的最末尾。min-nodes与调度器的交互Scheduler Bypasskube-scheduler会在 Cluster Autoscaler 评估 ComputeClass 优先级之前就把新 Pod 放到已有空闲容量由min-nodes保持热身的节点上。如果低优先级手工池因高min-nodes存在空闲容量Pod 会立即调度到这些低优先级节点上完全绕过优先 ComputeClass 层级。最佳实践手工池设置min-nodes: 0用CapacityBufferbuffer.x-k8s.io或即将推出的spec.minimumCapacity.targetNodeCount提供热余量。回退模式目录Fallback Patterns原文档按工作负载类型总结了五类标准回退模式这是整篇文档最具实战价值的部分模式优先级顺序设计理由对应资产推理InferenceRes → OD → DWS → Spot加速器节点启动慢延迟敏感的在线服务应规避 Spot 抢占风险genai-inference-g4-compute-class.yaml生产训练Prod TrainingRes → DWS → OD → Spot等待 DWS 可接受Spot 抢占破坏训练。DWS 排在 Spot 之前Flex 放在不可抢占层级的最底部tpu-v5e-training-compute-class.yaml开发训练Dev TrainingSpot → ODSpot 省成本OD 兜底保证开发不阻塞—成本批处理Cost BatchSpot → OD用priorityScore挑选最便宜的 Spot 机型族spot-cost-tiebreak-compute-class.yaml延迟混合Latency HybridManual → Auto-creation命中预热池以跳过自动创建延迟手工池限制在 ≤6–8 个manual-pool-tiebreak-compute-class.yaml推理模式Res → OD → DWS → Spot落地示例genai-inference-g4-compute-class.yaml 为 G4NVIDIA RTX PRO 6000 Blackwell推理服务定义了四级梯级全部machineType: g4-standard-48priorities: # 1. Specific reservation — paid, no queue, no preemption - gpu: count: 1 type: nvidia-rtx-pro-6000 driverVersion: default machineType: g4-standard-48 spot: false reservations: affinity: Specific specific: - name: g4-inference-reservation zones: [us-central1-a] # 分区范围在此声明而非 priorityDefaults.location # 2. On-Demand floor — 延迟敏感服务的优选回退三区 # 3. DWS FlexStart — On-Demand 耗尽后接受约 3 分钟排队 - flexStart: enabled: true capacityCheckWaitTimeSeconds: 1800 # ... # 4. Spot — 绝对最后手段接受抢占靠副本掩盖注意模板中的两处注释flexStart条目设置了capacityCheckWaitTimeSeconds: 180030 分钟容量检查窗口且置于倒数第一层spot: true的条目位于最底层。同时注释解释了为何不设置priorityDefaults.location——它会与第一级的 Specific 预留冲突分区范围应放在reservations.specific[].zones与各非预留优先级的location.zones中。训练模式示例tpu-v5e-training-compute-class.yaml 针对 TPU v5etpu-v5-lite-podslice8 chipstopology: 2x4实现 Reservation → On-Demand → Spot 三级。注释解释了关键取舍Spot sitsbelowOn-Demand because mid-step preemption forces a checkpoint restart, which is more disruptive for training than a slightly longer waitSpot 排在 On-Demand 之下因为步中抢占会强制从检查点重启对训练比多等一会儿更具破坏性——Spot 层仅在配备高频检查点时才安全。由于 TPU 预留是分区资源所有条目均显式锁定us-central1-a。成本批处理模式spot-cost-tiebreak-compute-class.yaml 展示了priorityScore的典型价值——三条 Spot 规则e2 / n2d / n4Intel Gen 1、AMD Gen 2、Intel Gen 4 的厂商与代际分散共用 Score 100让 ComputeClass 按当前最便宜且可获取自动选择机型族而不必把会随 Spot 价格波动而过时的机型排序硬编码进 YAMLScore 10 的 e2 On-Demand 兜底保证执行。模板注释还给出了按工作负载类型调参的提醒activeMigration.optimizeRulePriority: true适合无状态服务层配合 PDB 限制并发扰动长时间运行的批处理应删除该配置块否则漂移drift会强制任务中途重启whenUnsatisfiable: ScaleUpAnyway作为最后保障。关键设计规则Key Rules清单原文档最后归纳了七条必须遵守的设计规则这里完整继承并结合仓库示例加以说明不重复No repetition重复的梯级不能改善可获取性。变换维度Vary dimensions在可用区、机型族、容量类型Spot/OD、机器尺寸核数四个维度上做差异化。大规格形状的可获取性Size obtainability32 vCPU的形状来自更薄的容量池out.of.resources缺货远多于 ≤32 核的形状。一个只钉在大机型上的 ComputeClass没有逃生通道会Pending。如果工作负载允许应加入更小核数的回退优先级——但要以 Pod requests 为准做判断节点自动创建按 Podrequests定容单个请求 32 vCPU 的 Pod无法落到更小节点上只有可水平扩展大量小 Pod 装箱的工作负载才能受益。对真正的大单体 Pod应变换可用区/机型族而非核数。永远包含兜底Always include a floor以高可用 OD如 N4/E2收尾防止Pending。有状态代际隔离Stateful Gen IsolationPV 工作负载不要在priorities[]中混用硬件代际要么全 Gen 4要么全 Gen 2——混用会导致 Hyperdisk 与 PD 的挂载失败。例外GKE 1.35.3-gke.1290000使用内置dynamic-rwoStorageClasstype: dynamicuse-allowed-disk-topology: true后autoscaler 只扩容磁盘兼容的节点自动跳过不兼容代际的优先级而非让挂载失败此时混用代际是安全的参见 dynamic-rwo-storageclass.yaml 的前言注释。混合架构Mixed Architectures可以在priorities[]中混排 ARMn4a与 x86n4autoscaler 会依据 Pod 约束跳过不兼容形状。前提是必须使用多平台镜像构建。Spot 可用性差异Spot AvailabilityCPU 场景下如果 OD 缺货Spot 通常也缺货加速器场景则相反——OD 无容量时 Spot 往往仍有容量。这解释了推理模式为何把 Spot 放在 OD 之后CPU 部分逻辑而加速器训练/推理仍保留 Spot 层级。容量获取信号advice.capacity的启发式局限原文档特别澄清了一个常见误解gcloud beta compute advice capacityCLI 只返回离散的 Spot/Flex 概率桶0.1、0.5、0.9Google没有公开实时的 on-demand 可获取性 API。因此正确的心智模型是在 ComputeClass 中声明偏好顺序由 Cluster Autoscaler 在运行时仲裁可获取性——这也正是 GKE 1.36 同步获取判断机制前文第 6 条的产品化落地。小结设计一个 ComputeClass 优先级的检查清单结合 SKILL.md 的 CRITICAL RULES 与本文的参考文档一份可交付的priorities[]设计应满足梯级数 ≤6–8且每条规则在至少一个维度区/族/容量类型/尺寸上与邻级不同使用priorityScore时全员设分、同分 ≤3 条、分数 1–1000flexStart: true永远垫底Spot 层级根据负载类型CPU 或加速器决定位置手工nodepools总数 ≤6–8且每个池携带 compute-class 的 label taint兜底层为高可用 OD 族N4/E2且min-nodes: 0CapacityBuffer代替热节点机型族选择与现有 CUDs/Reservations 对齐模板中保留# IMPORTANT: Align machineFamily with your existing CUDs/Reservations注释是仓库的硬性 YAML 规范所有示例资产头部均标注EXAMPLE TEMPLATE - DO NOT DEPLOY实际部署前需按自身区域/可用区与 CUD 情况替换占位符并确认集群 GKE 版本满足各特性的版本门槛1.35.2 的priorityScore、1.35.3 的dynamic-rwo、1.36 的同步获取判断、1.36.3 的分区冷却域。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考