Karpenter 到底是 Cluster Autoscaler 的无痛替代，还是把复杂度从「集群」搬到了「你」？

背景

过去两年，几乎所有我接触的云原生团队都在评估 Karpenter，最常见的结论是：「比 CA 快、比 CA 灵活、直接换掉」。我自己在 3 个不同规模的集群（8 节点 / 40 节点 / 200+ 节点）里都做过 CA → Karpenter 的迁移，结论确实一致：纯性能层面 Karpenter 完胜——调度延迟从「分钟级」降到「秒级」，混合实例（Spot + OnDemand、多代 CPU、GPU）的利用率提升非常明显，尤其是对批处理 / 弹性推理这类负载，CA 的「一个 node group 一种规格」模型根本没法表达。

但我更想聊的是迁移之后大家容易低估的那部分成本，这才是我今天想引发讨论的核心分歧。

常见的几种做法与分歧

我观察到团队大致分三类：

1. 「无痛替换派」：直接删掉 node group，把 Karpenter 的 NodePool 写成「一个大的资源池 + 一堆 constraints」，CA 的 node group 概念被完全抛弃。这类团队普遍反映「前两个月很爽，第三个月开始被 node 漂移和标签缺失的 bug 追」。
2. 「双轨共存派」：CA 管在线业务、Karpenter 管批处理与突发，两者并行。看起来最稳，但实际上调度器看到的是同一个 cluster，谁先拿到 pod 谁就决定用哪种实例，边界非常模糊，故障时定位「这个 pod 为什么落在 CA 的 node 上」经常要花一下午。
3. 「全量 Karpenter + 自建 node group 语义派」：放弃 CA，但自己用 Karpenter 的 requirements + taints + node labels 把原来 node group 的语义「手工复刻」一遍，包括 Spot 中断策略、OnDemand 兜底、不同业务线的资源隔离。这条路最「对」，也最贵——本质上你是把云厂商的 node group 抽象用声明式 YAML 重新发明了一遍。

我的倾向与理由

我倾向于第三条路，但只在两类场景下值得：

• 你的实例需求是多维的（CPU 代次 / 架构 / GPU / 区域 / Spot 偏好），CA 的 node group 已经表达不了；
• 你的团队有 1 名以上愿意长期维护「节点生命周期」的工程师，而不是「用完就走」。

理由很朴素：Karpenter 把「节点生命周期」从云厂商手里交回给了你，这是它最大的价值，也是它最大的成本。CA 时代你出问题可以找云厂商的 runbook；Karpenter 时代你出问题只能翻自己的 requirements、taints、disruption 配置。这不是 bug，这是设计——但很多团队在选型 PPT 里只看到了前半句。

另一个我反复被问到的点：Karpenter 的 Spot 中断处理（eviction）到底能不能信任？ 我的经验是——能，但你要自己接住。它的 eviction 走的是 K8s 原生的 PodDisruptionBudget + 优雅驱逐，理论上没问题；但如果你没有 PDB、没有 terminationGracePeriodSeconds 调优、没有「驱逐后新节点起来之前旧节点还要撑住流量」的 readiness 策略，Spot 中断会直接变成 P0。CA 时代这些是「隐性由云厂商兜底」的，Karpenter 时代全部显性化到你头上。

想听大家聊什么

1. 你们生产上 Karpenter 的 NodePool 是一个大的还是按业务拆多个？拆的维度是什么（业务线 / 优先级 / 实例规格）？
2. Spot 中断你们有没有真的在生产里被坑过？被坑的团队是怎么恢复的——是靠 PDB 挡住了，还是靠「新节点先起、旧节点再走」的双写窗口？
3. 有没有人走过「Karpenter → 回滚 CA」的路？是什么场景下你们放弃的？
4. 对多集群 / 多区域的场景，Karpenter 的拓扑感知（topology spread constraints）你们觉得够用吗，还是又自己写了调度插件？

不用站队，把你团队里具体的配置片段、踩坑时间线、回滚原因贴出来最有价值。空谈「Karpenter 好 / Karpenter 差」的楼我会折叠（不是，我折叠不了，但我会优先回具体细节的）。