kube-scheduler主备模式需先确认是否部署多实例：若kubectl get pods仅显示一个scheduler Pod，则无主备；若多个Pod存在，再通过lease资源、日志、etcd健康、时间同步及apiserver压力等综合排查脑裂。
确认kube-scheduler是否处于主备模式
先查集群实际部署方式，很多托管K8s（如EKS、AKS、GKE）默认不启用多实例scheduler，压根不存在主备切换问题。运行 kubectl get pods -n kube-system -l component=scheduler，如果只看到一个Pod，后续所有主备排查步骤都不适用。
若返回多个Pod（如 kube-scheduler-node1、kube-scheduler-node2），说明启用了高可用调度器，继续下一步。
检查leader election锁状态
调度器主备靠etcd里的lease资源选举，核心路径是 /leases/kube-system/kube-scheduler。直接执行：kubectl get lease kube-scheduler -n kube-system -o wide
观察AGE列和HOLDER列：如果两个实例的AGE都极短（秒级刷新）、HOLDER字段来回跳变，说明选举频繁；如果HOLDER长期为空或反复出现不同节点名，就是脑裂信号。
【必须确认】 这个lease对象必须存在于kube-system命名空间，且名字严格为 kube-scheduler。自定义部署若改了lease名字，上述命令会查不到结果，导致误判。
定位脑裂发生的根本原因
第一步：登录当前显示为“leader”的节点，执行 journalctl -u kube-scheduler -n 100 --no-pager | grep -i "lost\|lease\|renew"。重点找 leader election lost 或 failed to renew lease 日志行。
第二步：在同一个节点上，检查etcd连接延迟：ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint health
第三步：若etcd健康但scheduler仍丢lease，立刻检查该节点时间同步状态：timedatectl status | grep "System clock synchronized"。输出为no即为致命问题——时钟漂移超500ms就会触发lease过期，造成假性脑裂。
第四步：若以上都正常，检查apiserver压力。在控制面节点执行：kubectl top pods -n kube-system | grep apiserver。CPU持续高于80%会导致scheduler无法及时上报心跳，被判定失联。
验证当前活跃leader行为
方法一：直接看scheduler日志里的声明
执行 kubectl logs -n kube-system <scheduler-pod-name> | grep -i "started as leader"</scheduler-pod-name>，只有一条输出才正常；若多个Pod日志里都有此句，证明同时认为自己是leader。
方法二：用curl直连scheduler健康端口
对每个scheduler Pod执行：kubectl exec -n kube-system <pod-name> -- curl -s http://127.0.0.1:10259/healthz</pod-name>。返回 ok 的才是真leader；返回 not leader 的是follower，但若多个都返回 ok，就是脑裂实锤。
注意：10259端口是scheduler默认健康检查端口，某些定制化部署可能改为10251，请先用 kubectl describe pod -n kube-system <pod-name></pod-name> 确认容器启动参数中的 --bind-address 和 --secure-port 值。
