K8s HPA 自动扩缩容反复触发 Kafka consumer group rebalance：弹性响应与消费连续性到底怎么兼得？

【背景】 K8s 1.28（4 节点，16C64G），Kafka 3.5（3 broker，KRaft），topic risk-eval-result 48 分区，消费组 8 实例（K8s Deployment，每实例 6 分区）。消费逻辑：poll() → 调外部风控引擎 RPC（P50=80ms，P99=1.2s）→ 写 MySQL 8.0。峰值约 8000 msg/s，日均约 5000 万条。

HPA 配置：minReplicas=6, maxReplicas=14, target CPU=70%, scaleUpStabilizationWindow=60s, scaleDownStabilizationWindow=300s。

【现象】 业务流量有明显波峰波谷（早 9 点到晚 11 点高峰，凌晨低谷）。HPA 在流量爬坡期频繁 scaleUp（10 分钟内 6→10→12），每次 scaleUp 新 Pod 加入 consumer group 触发 eager rebalance，rebalance 期间全组暂停消费约 8–15s。更糟的是形成正反馈：

rebalance 暂停 → 消息积压 → 新 Pod 起来后一次性拉取大量消息 → CPU 飙升 → HPA 继续 scaleUp → 再次 rebalance。

最严重的一次 20 分钟内 rebalance 了 7 次，消费端 P99 延迟从 200ms 飙到 45s，下游风控引擎被突发流量打了一波 503。

【已尝试的排查与结果】

1. scaleUpStabilizationWindow 调到 300s：rebalance 次数降到 2–3 次，但业务侧要求弹性响应 < 90s，300s 不满足。
2. 切换 CooperativeStickyAssignor（参考了社区里 @江知远-915 的 <article id=968>）：rebalance 从"全停"变为"增量迁移"，单轮中断从 15s 降到 2s 左右，但 HPA 频繁扩缩时仍触发多轮 partition 迁移，消费端 CPU 因反复 reassign 而持续抖动，P99 没有根本改善。
3. 开启 static membership（group.instance.id）：Pod 原地重启不再触发 rebalance（instance.id 不变），但 HPA scaleDown 后 Pod 被杀、scaleUp 后新 Pod 分配新 instance.id，仍然触发 rebalance——static membership 只解决了"同 Pod 重启"，没解决"Pod 数量变化"。
4. HPA 指标从 CPU 换成自定义指标（Kafka consumer lag）：思路对了（lag 驱动扩缩比 CPU 驱动更贴近消费语义），但 Prometheus Adapter 拉 consumer lag 的 scrape 间隔 30s + HPA 决策周期 15s，总滞后约 45s，在流量突增时反而反应更慢，lag 峰值比 CPU 指标时更高。

【期望得到的答案形态】

• 有没有人在 HPA + Kafka consumer group 的组合下跑过生产环境？具体参数怎么配的？（我关心的不是"该不该用 HPA"，而是"用了之后怎么把正反馈环路打断"）
• 如果必须用 HPA，有没有办法让"扩缩容触发的 rebalance"和"消费连续性"兼得？比如：HPA 先 scaleUp 但新 Pod 不立即加入 consumer group（用 sidecar 或 init 逻辑延迟 join），等 lag 消化到阈值后再加入？
• 或者更激进的架构解耦：HPA 只管计算弹性，消费端用固定实例数 + 分区内并行线程？这样 Pod 数量变化不影响 consumer group，但分区内并行又引入顺序性/资源竞争问题——你们怎么权衡的？
• 如果以上都不行，你们是怎么取舍的？接受偶尔的 rebalance 风暴（配幂等兜底），还是牺牲弹性换稳定性（固定实例数 + 分区内线程池）？

引用了社区里两篇直接相关的内容作为排查参考：

• <article id=968>（CooperativeStickyAssignor + static membership 把 rebalance 中断从 40s 压到 0）——我试了 cooperative 但 HPA 场景下仍然反复触发

• <article id=62>（rebalance 风暴导致 200 万重复消息）——我的正反馈环路本质上是 HPA 放大了这个模式