K8s 滚动更新里 group.instance.id 复用 pod 名导致新旧实例撞 ID：该拿 pod UID 当后缀，还是干脆别开 static membership？

【背景】 Kafka 3.5（3 broker KRaft），topic 48 分区，消费组 6 实例（K8s Deployment，每实例 8 分区），峰值约 1.2 万 msg/s。消费逻辑单条 P99 ≈ 350ms（含一次下游 RPC + 落库），SLA 要求 rebalance 期间不能整组停摆，所以参考了站内《Kafka 消费组扩容即停摆》的做法，把分配器从 eager 切到 CooperativeStickyAssignor，并打开了 static membership（session.timeout.ms=30s，max.poll.interval.ms=120s）。

【现象】 上线后滚动更新反而比之前更糟：

• 第一次滚动更新，6 个 pod 逐个重启，每次都有 1 个实例卡 30s 左右才加入组，broker 日志显示是新旧实例 group.instance.id 相同（都用 pod 名做静态 ID），新实例被 broker 判为「重复实例」，要等旧实例的 session 在 broker 侧真正过期才放行；
• 我们改成「pod 名 + pod UID 短哈希」做静态 ID，更新时不再撞 ID，但又出现 ghost 会话：旧实例被 KILL 后 heartbeat 立即断，broker 侧要等满 30s 才把旧实例当离线清掉，期间组内成员数虚高、分区分配反复抖动。

【已尝试的排查与结果】

1. 关掉 static membership，只留 cooperative-sticky：更新时不再撞 ID、也无 ghost 残留，但每次滚动更新每个实例都要走一轮增量 rebalance，6 个 pod 串行重启时整组在 90s 内发生 6 次 rebalance，消费停顿累计约 40s，回到了「扩容即停摆」的老问题；
2. 开 static membership + pod 名做 ID：撞 ID 问题如上，单实例更新延迟被 session.timeout 主导；
3. 开 static membership + pod 名 + UID 后缀：不撞 ID，但 ghost 会话要等 session.timeout 才清，滚动更新窗口里成员数虚高，CooperativeSticky 出现 2 次跨实例的分区迁移（每实例 8 分区，迁移 1~2 个）。

【期望得到的答案形态】

1. static membership 场景下，group.instance.id 的「稳定」到底应该锚定在 pod 名、pod UID 还是 Deployment 副本序号？K8s 环境有没有推荐取值，以及为什么；
2. 如果用 UID 后缀，ghost 会话等满 session.timeout 是预期行为还是有参数能加速清理（比如 group.instance.rejoin.timeout 之类的），代价是什么；
3. 如果撞 ID 不可避免，CooperativeSticky 下的 rebalance 是只迁移「撞掉的那几个分区」还是整组重算，有没有办法把更新窗口里的 rebalance 次数从 N（实例数）压到 1~2 次；
4. 给一个 48 分区 / 6 实例 / 滚动更新的具体参数组合（assignor + static ID 取值 + session.timeout + max.poll.interval）和预期效果（更新窗口内的最大消费停顿、分区迁移次数）。

参考：@《Kafka 消费组扩容即停摆：从 eager 全停再均衡切到 cooperative 增量 + static membership，把 rebalance 中断从 40s 压到 0》(id=968)、@《K8s 滚动更新时 Kafka Consumer 优雅停机，in-flight 消息与 offset 提交竞态如何消除》(id=760)。