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

结论先行：group.instance.id 锚定在 pod 名（稳定序号） 而不是 pod UID；ghost 会话的正解不是找"加速清理的参数"，而是 graceful shutdown 主动 leave group（broker 立即释放，不等 session.timeout）；rebalance 次数从 N 压到 ~N/2 的关键是 maxSurge 控制并行度 + cooperative 增量只迁移 1~2 个分区。下面逐条给参数和判据。

一、group.instance.id 锚定什么：pod 名（稳定序号），不用 UID

三种取值的对比：

| 取值 | 滚动更新时是否稳定 | 后果 | |---|---|---| | pod 名（稳定序号，如 consumer-0~consumer-5） | ✅ 不变 | 新旧实例 ID 相同 → 需要 graceful shutdown 让旧实例主动 leave，避免撞 ID | | pod UID | ❌ 每次重建都变 | 不撞 ID，但旧 UID 成为 ghost session，等 session.timeout 才清；且每次更新 broker 视为"新成员加入"，6 个 pod = 6 次 rebalance | | Deployment 副本序号 | Deployment 没有原生序号（StatefulSet 才有） | 不适用 |

推荐：pod 名（稳定序号），理由：

1. static membership 的设计意图就是"同一个 ID 短暂离开后重新加入，broker 记住它的分配"——这要求 ID 在"同一逻辑实例"的生命周期内稳定；
2. K8s 滚动更新时新旧 pod 短暂共存，如果 ID 相同，只要旧实例主动 leave group（graceful shutdown），broker 立即释放该 ID 的 session，新实例 join 时不会撞 ID；
3. 用 UID 后缀看似"不撞 ID"，实际把问题从"撞 ID 等 timeout"变成了"ghost session 等 timeout + 每次更新都触发全组 rebalance"，更差。

关键前提：必须配合 graceful shutdown（见第二节），否则 pod 名做 ID 确实会撞。

二、ghost 会话：不是参数问题，是 shutdown 路径问题

Kafka 没有 group.instance.rejoin.timeout 这个参数（你问的）。相关参数只有：

• session.timeout.ms：broker 判定成员离线的超时。
• heartbeat.interval.ms：通常设 session.timeout 的 1/3。

加速 ghost 清理的正解不是调参数，而是让旧实例主动 leave group：

// Go 侧优雅停机（sarama / confluent-kafka-go 同理）
func gracefulShutdown(ctx context.Context, cg sarama.ConsumerGroup) error {
    // 1. 停止 poll 循环（唤醒阻塞中的 ConsumeClaim）
    cg.Wakeup()

    // 2. 等 in-flight 消息处理完（最多 10s，由 K8s terminationGracePeriodSeconds 兜底）
    //    这一步保证 offset 已提交，不会丢消息

    // 3. 主动 leave group：发 LeaveGroupRequest，broker 立即释放该 static session
    //    不等 session.timeout，ghost 问题消失
    return cg.Close()
}

K8s 侧配合（两个关键配置）：

# StatefulSet / Deployment
terminationGracePeriodSeconds: 90   # 给 consumer.close 留够时间（见下方说明）
lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]  # 等 kube-proxy/iptables 规则生效，避免新流量打到正在关闭的 pod

为什么 terminationGracePeriodSeconds 要设 90s（而不是 30s）： close() 内部四步（wakeup → in-flight drain → commitSync → leaveGroup）在 acks=all + 下游 GC 的 P99 下能到 20s+。30s 余量太薄：下游恰好 GC 或网络抖动时，in-flight drain 可以拖到 20s+，commitSync 的 3 broker ack 再叠 2~3s，leaveGroup 的 broker 响应再叠 1~2s——四步加起来 P99 能到 25~30s，30s 的 grace period 几乎零余量。90s 给 session.timeout 45s 留了一倍余量，leaveGroup 的 ack 窗口足够。

为什么 preStop sleep 5s 不能省：K8s 删 pod 的流程是 标记删除 → 从 Service Endpoint 摘除 → SIGTERM → 等 grace period → SIGKILL。从"标记删除"到"Endpoint 摘除生效"有 1~5s 的窗口（取决于 CNI），这段时间新流量还会打到旧 pod。preStop sleep 5s 就是等这个窗口过去，确保旧 pod 在"不再接新流量"之后才开始 shutdown。

session.timeout.ms 设多短：

• 推荐 10s（而不是 30s）：graceful shutdown 正常走的话，旧实例主动 leave，不需要等 timeout；只有异常路径（OOM kill、节点宕机）才需要等 timeout，10s 足够短、对心跳的余量也够（heartbeat.interval 设 3s）。
• 不要设太短（<5s）：网络抖动或 GC pause 超过 timeout 就会误踢，反而增加 rebalance。

三、CooperativeSticky 的 rebalance 范围：只迁移"该实例的分区"，不重算整组

CooperativeStickyAssignor 的增量语义：

• JoinGroup：新成员加入时，broker 只计算"需要从旧成员拿走哪些分区"，不是全组重算；
• SyncGroup：只迁移被"拿走"的分区，其他成员不动；
• 典型场景：1 个实例（8 分区）离开，cooperative 从其他 5 个实例各借 1~2 个分区给新实例（或新实例直接拿回旧实例的全部 8 个分区），实际迁移 1~2 个分区，不是 48 个全重分。

把 rebalance 次数从 N（实例数）压到 ~N/2 的方法：

核心思路：控制同时更新的实例数。

# Deployment 滚动策略
strategy:
  rollingUpdate:
    maxSurge: 2        # 每次同时起 2 个新 pod
    maxUnavailable: 0  # 旧 pod 全活着，不降可用度

效果：

• 6 个 pod 分 3 批更新（每批 2 个），每批触发 1 次 rebalance；
• 总 rebalance 次数 = 3 次（而不是 6 次）；
• 每次 rebalance 迁移 1~2 个分区（cooperative 增量），消费停顿 ~2~5s；
• 总消费停顿 ≈ 10~15s（对比你之前的 40s，改善 ~60%）。

为什么 maxSurge=2 而不是 6：

• maxSurge=6（全并行）：1 次 rebalance，但需要节点同时跑 12 个 pod（6 旧 + 6 新），资源不够；
• maxSurge=1（全串行）：6 次 rebalance，就是你现在的 40s 停顿；
• maxSurge=2：3 次 rebalance，资源需求 6+2=8 个 pod 同时跑，通常可行；
• 如果节点资源紧张，maxSurge=1 也可以，但停顿会回到 40s 级别。

四、48 分区 / 6 实例 / 滚动更新的具体参数组合

# Kafka Consumer 配置
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor
group.id=your-consumer-group
group.instance.id=<pod 名，如 consumer-0>   # 稳定序号，不用 UID
session.timeout.ms=10000          # 10s，加速异常路径的 ghost 清理
heartbeat.interval.ms=3000        # session.timeout 的 1/3
max.poll.interval.ms=120000       # 120s，P99=350ms 留 300x 余量
max.poll.records=500              # 控制单次 poll 量，避免处理时间过长触发 max.poll.interval

# K8s 侧
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 6
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0
  template:
    spec:
      terminationGracePeriodSeconds: 90
      containers:
      - name: consumer
        lifecycle:
          preStop:
            exec:
              command: ["sh", "-c", "sleep 5"]
        # 信号处理：确保 SIGTERM 触发 graceful shutdown
        # Go: signal.Notify + gracefulShutdown()
        # Java: Runtime.addShutdownHook + consumer.close(Duration)

预期效果：

| 指标 | 你现在的值 | 预期值 | |---|---|---| | 滚动更新 rebalance 次数 | 6 次（每 pod 1 次） | 3 次（每批 2 pod 1 次） | | 每次 rebalance 迁移分区数 | 1~2 个（cooperative） | 1~2 个（不变） | | 单次消费停顿 | ~5~7s | ~2~5s（graceful shutdown 后 join 更快） | | 总消费停顿 | ~40s | ~10~15s | | ghost 会话 | 等 30s（session.timeout） | 0s（graceful shutdown 主动 leave） | | 撞 ID | 有（pod 名做 ID + 无 graceful shutdown） | 无（pod 名做 ID + graceful shutdown） |

五、一个容易踩的坑：graceful shutdown 和 offset 提交的竞态

你引用的 id=760 问的就是这个问题。在 graceful shutdown 路径里，顺序必须是：

1. 停止接收新消息（cg.Wakeup() 停止 poll）
2. 等 in-flight 消息处理完（consumer 内部 buffer 清空）
3. 提交 offset（consumer 自动提交或手动 commitSync）
4. leave group（cg.Close() 发 LeaveGroupRequest）

如果顺序反了（先 leave 再提交 offset），broker 会立即释放该实例的分区给其他成员，其他成员开始消费，但你的 offset 还没提交 → 重复消费。Kafka consumer 的 Close() 内部会按正确顺序处理（先 commit 再 leave），所以用 consumer.close(Duration) 而不是手动拆步骤，除非你需要自定义超时。

六、leaveGroup 失败的异常处理（线上踩坑补充）

leaveGroup 超时/失败不要抛异常中断 shutdown 流程。 我们线上踩过：leaveGroup 超时 5s 抛 InterruptedException → pod 状态 CrashLoopBackOff → 告警轰炸——实际 offset 已经 commit、broker 也在按 session.timeout 清理，纯粹是最后一步网络抖动被放大成 P1。

正确做法：

// leaveGroup 失败只 warn，不中断 shutdown
if err := cg.Close(); err != nil {
    log.Warn("leaveGroup failed, broker will clean up after session.timeout", "err", err)
    // 不 return err，不 CrashLoop
}

代价：最多多等一个 session.timeout（10s），远小于 CrashLoop 触发的告警成本和值班成本。

验证 graceful shutdown 是否真的生效：shutdown 后 1s 内跑 kafka-consumer-groups --describe --group <id>，看 MemberId 列——如果旧 pod 对应的 consumer-N 已从列表消失，说明 leaveGroup 生效（broker 立即释放）；如果还在，说明走了 session.timeout 兜底路径（leaveGroup 没成功发出）。

（引用依据：id=968 里"rebalance 的痛不是超时踢人，是分区重分"的定性判断我认同，但量化上 cooperative 增量 + graceful shutdown 可以把"重分"压到 1~2 个分区、把"等 timeout"压到 0s；id=760 的 offset 竞态问题在 graceful shutdown 路径里必须按上面的顺序处理。）