协同领导者选举

Kubernetes 1.36 包含一个 beta 特性，允许 控制平面 组件通过 协调式领导者选举（coordinated leader election） 确定性地选择领导者。这对于满足集群升级期间的 Kubernetes 版本偏差约束非常有用。目前，唯一内置的选择策略是 OldestEmulationVersion，即优先选择具有最低模拟版本的领导者，其次是二进制版本，再次是创建时间戳。

启用协调式领导者选举

在启动 API Server 时，请确保启用了 CoordinatedLeaderElection 特性门控，并且启用了 coordination.k8s.io/v1beta1 API 组。

可以通过设置标志 --feature-gates="CoordinatedLeaderElection=true" 和 --runtime-config="coordination.k8s.io/v1beta1=true" 来完成此操作。

组件配置

前提是你已经启用了 CoordinatedLeaderElection 特性门控 并且
启用了 coordination.k8s.io/v1beta1 API 组，兼容的控制平面
组件将自动使用 LeaseCandidate 和 Lease API 来选举领导者
（根据需要）。

对于 Kubernetes 1.36，当启用了该特性门控和 API 组时，
两个控制平面组件（kube-controller-manager 和 kube-scheduler）
会自动使用协调式领导者选举。

Kubernetes 组件的领导者选择

Kubernetes 使用 Lease API 在高可用集群中执行相同控制平面组件的多个实例之间的领导者选举，例如 kube-controller-manager 或 kube-scheduler。

一个 Lease 充当轻量级分布式锁，由 Kubernetes API server 存储。组件的所有运行实例都会观察或定期读取相关的 Lease 对象，以确定当前哪个实例作为领导者运行。

Lease API 定义了以下字段：

holderIdentity

当前领导者的标识（例如：Pod 名称或基于主机名的字符串）。

acquireTime

获得领导权的时间戳。

renewTime

领导者最近一次续约的时间戳。

leaseDurationSeconds

租约的有效期（候选者应在尝试获取过期租约之前等待这段时间加上较小的宽限期）。

leaseTransitions

领导权易手次数的计数器。

这些字段指明了哪个实例拥有领导权以及该领导权在多长时间内保持有效。

当 Lease 不存在或已过期（当前时间 > renewTime + leaseDurationSeconds）时，候选实例会尝试用自己的标识更新 Lease。Kubernetes 依靠对象 resourceVersion 实现 乐观并发控制：由于并发尝试时版本不匹配，只有一个更新会成功。更新被接受的实例成为 领导者。

Kubernetes 使用 LeaseCandidate API 来管理领导者选举。kube-controller-manager 和 kube-scheduler 等控制平面组件通过创建 LeaseCandidate 对象来注册其候选角色，这些对象追踪所有竞争领导权的实例，并携带包含候选者标识、二进制版本和模拟版本等元数据。

在选举期间，候选者通过共享的 Lease 进行协调。Kubernetes 控制平面保证只有一个候选者能成功获得 Lease 并承担 领导者 角色，而所有其他候选者保持为跟随者。如果当前的 领导者 未能在选定的超时周期内续约 Lease，剩余的候选者将竞争获取领导权并选举出新的 领导者。

一旦当选，领导者会定期通过更新 renewTime 字段来续约其租约

（例如，每 leaseDurationSeconds ÷ 2 执行一次续约，以避免在 Lease 即将过期时产生冲突）。只要在租约过期前发生续约，当前的领导者实例就会保持领导地位。如果领导者崩溃、变得不可达或停止续约 Lease，该 Lease 就会过期。其他健康的实例会检测到已过期的 Lease 并尝试进行新的选举。

这种机制确保了即使为了稳定性和恢复运行着组件的多个副本，同一时间也只有一个实例主动执行控制任务，而其他实例则保持待命状态，观察 Lease 并准备在需要时快速接管。