Kubernetes v1.20无法通过endpoints查询controller manager与scheduler选举信息

关于v1.20+版本取消Endpoints选举信息的说明 #

是的，Kubernetes v1.20及以上版本确实将kube-controller-manager、kube-scheduler的默认领导选举存储资源从Endpoints正式切换为了Lease资源。
Lease是Kubernetes v1.14版本引入的专门用于节点心跳、服务领导选举场景的轻量API资源，相比Endpoints更适配选举场景，能有效降低apiserver的负载压力。v1.19及更早版本两个组件会同时维护Endpoints和Lease两类选举资源，v1.20开始默认仅使用Lease资源，因此直接查询kube-system命名空间下的Endpoints就看不到对应资源了，属于版本正常变更。

基础组件选举状态查询方法 #

• 查询Lease资源（最直接方法）
  直接执行命令：

  kubectl get lease -n kube-system
  

  返回结果中HOLDER列对应的节点就是当前当选的leader节点，也可以用kubectl describe lease <lease名称> -n kube-system查看更详细的选举时间、续租信息。
• 查看组件运行日志
  登录kube-controller-manager、kube-scheduler部署的节点，查看组件运行日志：
  当选leader的组件会输出类似successfully acquired lease kube-system/kube-controller-manager的日志；
  处于follower状态的组件会输出类似failed to acquire lease kube-system/kube-scheduler: leases.coordination.k8s.io "kube-scheduler" is already owned的日志。
• 通过组件Metrics查询
  如果已经开启了kube-controller-manager、kube-scheduler的metrics接口采集，可以通过指标kube_leader_election_status判断，指标值为1的实例就是当前leader。

补充说明：如果需要恢复v1.19及更早版本的Endpoints选举逻辑，可以在两个组件的启动参数中添加--leader-elect-resource-type=endpoints即可，但不推荐该操作，Lease资源是官方当前主推的选举实现，性能和稳定性更优。

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