背景
我管过一个 200+ 节点的 K8s 集群（1.28，EKS），去年做成本治理，把无状态服务的 NodePool 改成 70% spot + 30% on-demand 混部，配合 Karpenter 做节点替换。账面上每月省了约 40% 的节点成本，看起来是笔"必赢"的账。
但跑了一个季度后，我在 oncall 周报里加了一列"抢占事件"：一周平均 11 次 spot 回收，其中 3 次是同一时段、同一 AZ 的批量抢占（AWS 的 spot 池水位波动），一次批量抢占直接打穿了某个服务的 HPA——HPA 还没来得及扩容，Karpenter 又拉起了 4 个 replacement 节点，冷启动窗口里 P99 直接打到熔断线。
这件事让我开始怀疑：省下来的那 40% 成本，是不是真的被 oncall 的加班费、故障复盘的人力、以及"不敢在 spot 上跑核心链路"的架构妥协给吃回去了？
常见分歧 / 几种做法
我听过至少三种流派：
- "全 spot 派"：无状态服务就该全跑 spot，on-demand 只留给有状态和强 SLO 的服务。理由是 spot 的溢价（on-demand 价格的 1~3 倍）是纯浪费，省下来的钱可以投到监控和自动化上。
- "70/30 混部派"（我现在用的）：spot 和 on-demand 混跑，用 Karpenter / Cluster Autoscaler 做替换。好处是单节点抢占不会打穿容量，坏处是节点数会膨胀（replacement 节点 + on-demand 兜底节点同时存在），实际省的钱比理论值低 10~15%。
- "spot 不碰派"：spot 只用于离线批处理（Spark / 离线跑数），在线服务一律 on-demand 或 reserved。理由是 spot 的"5 分钟通知"在 K8s 里根本不够——节点 drain 需要 30s~2min（取决于 Pod 数量和 terminationGracePeriodSeconds），而且通知机制本身不可靠（我见过 5 分钟通知没到的 case）。
还有一种更激进的玩法：用 spot 做 HPA 的"弹性余量"，但永远不让 spot 承载 base capacity。也就是 minReplicas 全部跑在 on-demand 上，HPA 扩出来的那部分优先调度到 spot 节点。这个思路我还没在生产验证过，但直觉上比"70/30 混部"更可控。
我的倾向
我目前偏向 "spot 只做弹性余量，不承载 base capacity" 这个方向，理由有三：
- base capacity 是 SLO 的底线，它的稳定性直接决定 P99 能不能守住；弹性余量是"锦上添花"，丢了只影响峰值体验，不影响可用性。把 spot 放在弹性余量上，风险敞口最小。
- Karpenter 的节点替换机制对"弹性余量"场景更友好——扩容时拉起 spot，缩容时优先回收 spot，这个方向和 HPA 的 scaleUp/scaleDown 天然对齐。
- 成本节省的比例可能比 70/30 混部低（大概能省 20~25% 而不是 40%），但这部分省下来的钱是"确定的"，不依赖 oncall 团队每周去救火。
但我不确定的是：在 spot 价格波动剧烈的时候（比如 GPU 实例），"弹性余量"策略的成本优势是否还成立？ 以及 如果团队没有专职 SRE，纯开发团队自己管 K8s，spot 的运维复杂度是否已经超过了它的成本收益？
想听大家怎么选
几个具体问题，想收集不同规模、不同云厂商的实践：
- 你们线上有没有跑 spot？比例是多少？省了多少钱？oncall 周报里有没有"抢占事件"这一列？
- 你们用 Karpenter 还是 Cluster Autoscaler 做 spot 节点替换？spot 被回收时的 drain 流程是怎么设计的（PDB、terminationGracePeriodSeconds、preStop hook）？
- 有没有人尝试过"spot 只做弹性余量"这个方向？效果如何？
- 你们所在团队对 spot 的态度是怎么演变的？是从"全 spot"退到"混部"，还是从一开始就"不碰"？
不预设答案，想看看不同规模（10 节点 vs 200 节点）、不同云（AWS / GCP / 阿里云）下的真实取舍。