优先用 client-go 的 leaderelection 包——它稳定、轻量、深度集成 Kubernetes 生态，规避网络分区、时钟漂移、脑裂等陷阱；自研 Bully/Raft 易因超时不准、消息不可靠、状态机复杂等问题引发严重故障。
直接上结论：别自己手撸 Raft 或 Bully，优先用 client-go 的 leaderelection 包——它稳定、轻量、已深度集成 Kubernetes 生态，且规避了网络分区、时钟漂移、脑裂等绝大多数分布式陷阱。
为什么不用自己实现 Bully / Raft？
自己写选举逻辑看似可控，实际踩坑成本远超预期：
-
Bully依赖节点 ID 全局有序 + 精确超时 + 可靠广播，但 Go 的net.Conn不保证消息送达，time.After在 GC 或系统负载高时可能延迟数百毫秒，导致误判 leader 失效 -
Raft需要完整实现日志复制、快照、任期（term）跃迁、安全性检查（Safety），哪怕只做最小可用版，也要处理至少 7 类消息和 5 种状态转换，RequestVote和AppendEntries的幂等性极易出错 - 所有自研方案都绕不开「租约续期」问题：没心跳 ≠ 宕机，可能是 GC STW、网络抖动或 kubelet 驱逐中 —— 而
leaderelection的LeaseDuration和RenewDeadline是经生产验证的保守值
client-go leaderelection 怎么快速接入？
核心就三步：建锁、配参数、启选举。不依赖外部中间件，纯走 Kubernetes API Server。
- 锁类型选
LeasesResourceLock（K8s 1.14+ 默认）：比ConfigMapsResourceLock更轻量，更新原子性强，TTL 由 server 端强制保障 - 必须显式传入唯一
identity（不能用随机字符串）：建议用 Pod UID（os.Getenv("POD_UID")）或启动时生成的 stable UUID，否则重启后旧 lease 残留，新实例抢不到锁 -
LeaseDuration建议 ≥ 15s，RenewDeadline设为 10s，RetryPeriod设为 2s —— 这组值在多数集群网络 RTT - 回调函数里别阻塞：
OnStartedLeading中启动 goroutine 执行业务逻辑，否则会卡住 lease 续期，触发主动让位
lock := &resourcelock.LeaseLock{
LeaseMeta: metav1.ObjectMeta{
Name: "my-app-leader-lock",
Namespace: "default",
},
Client: clientset.CoordinationV1(),
LockConfig: resourcelock.ResourceLockConfig{
Identity: os.Getenv("POD_UID"), // 关键！不可重复
},
}
config := leaderelection.LeaderElectionConfig{
Lock: lock,
LeaseDuration: 15 * time.Second,
RenewDeadline: 10 * time.Second,
RetryPeriod: 2 * time.Second,
Callbacks: leaderelection.LeaderCallbacks{
OnStartedLeading: func(ctx context.Context) {
go runBusinessLoop(ctx) // 必须异步
},
OnStoppedLeading: func() {
log.Println("leader lost, shutting down")
},
},
}
leaderelection.RunOrDie(ctx, config)
常见错误：lease 没释放 / 抢不到锁 / 频繁切换
这些问题基本都指向配置或环境误用：
立即学习“go语言免费学习笔记（深入）”；
- Pod 权限不足：ServiceAccount 缺少
leases的create/update/patch权限，报错类似error retrieving resource lock default/my-app-leader-lock: leases.coordination.k8s.io "my-app-leader-lock" is forbidden - Namespace 错误：
LeaseMeta.Namespace写成"kube-system"但 RBAC 绑定在"default"，或反之 - 多个 Pod 共用同一
identity：比如硬编码"my-app"，导致所有副本竞争同一个 lease，永远只有一个能赢，其余无限重试 - ctx 被提前 cancel：在
OnStartedLeading启动的 goroutine 里用了外层ctx，而主 goroutine 已退出，lease 自动释放
真需要脱离 K8s 时，怎么安全降级？
如果部署环境不含 Kubernetes（如裸机集群或边缘设备），leaderelection 包无法使用，此时才考虑外部协调服务：
- 优先选
etcd+go.etcd.io/etcd/client/v3/concurrency：利用Session和LeaderElector，比 ZooKeeper 更轻，且原生支持 TLS 和鉴权 - 避免用 MySQL 实现：行锁
SELECT ... FOR UPDATE在主从延迟场景下易脑裂；乐观锁需频繁轮询，增加 DB 压力 - 绝对不要用 Redis
SETNX+ 过期时间：Redis 单点故障时锁失效，且没有租约续期机制，无法区分「真宕机」和「GC 暂停」
真正难的从来不是“怎么选 leader”，而是“怎么定义 leader 还活着”。Kubernetes 的 lease 机制把这个问题交给了 etcd Raft 层和 apiserver 的 watch 保活逻辑 —— 别重复造轮子。
