如何让同一Pod内两个容器的Leader选举结果同步至同一Pod实例？

你当前的两个容器各自使用独立的Leader选举锁资源，选举过程完全互不感知，所以会出现Leader副本落在不同Pod的情况：

• 自定义调度器使用ns命名空间下名为my-scheduler的锁资源
• kube-builder实现的extender默认使用独立的锁资源，和调度器的锁完全无关

方案1：共享同一套Leader选举锁（改造成本低） #

两个组件复用同一把分布式锁，利用同一个Pod内容器hostname一致的特性实现选举状态同步，操作步骤如下：

• 统一锁配置：
  1. 在调度器的config.yaml中显式指定锁类型，避免版本默认值差异：

  leaderElection:
    leaderElect: true
    resourceName: my-scheduler
    resourceNamespace: ns
    resourceLock: leases # 显式指定锁类型为Lease，和kube-builder默认值对齐
  

  2. 修改extender的Leader选举参数，完全复用调度器的锁配置：锁名称设置为my-scheduler、命名空间为ns、锁类型为leases，同时给extender的ServiceAccount授予对应Lease资源的操作权限。
• 选举标识对齐：kube-scheduler和kube-builder的默认选举标识都是Pod的hostname，同一个Pod内两个容器的hostname完全一致，只要该Pod抢到锁，两个容器都会识别到自己是Leader，自动同步状态。

注意：两个组件的选举超时、重试周期配置尽量保持一致，避免出现短暂的状态差。

方案2：单组件选举+同Pod状态共享（稳定性更高，推荐） #

只保留一个组件的选举逻辑，状态同步给同Pod的另一个组件，不会出现状态不一致的问题，操作步骤如下：

1. 关闭extender的独立Leader选举，把启动参数--enable-leader-election=true改为false
2. 给Pod新增一个emptyDir类型的共享卷，挂载到两个容器的相同路径，比如/var/run/leader-status
3. 给调度器容器增加状态同步逻辑：定期检测调度器的Leader状态，将结果写入共享卷的状态文件（例如is_leader，内容为true/false）
4. 修改extender的逻辑：定期读取共享卷中的状态文件，只有状态为true时才运行核心业务逻辑，否则处于空闲等待状态，不处理任何请求。

两种方案都建议配置对应的就绪探针：只有Pod内两个组件都处于正常的Leader/非Leader状态时，才将Pod加入服务端点，避免异常请求转发。

内容的提问来源于stack exchange，提问作者user1365697