背景
Kubernetes 高可用集群的控制面组件里，除了 kube-apiserver 是多副本负载均衡同时提供服务之外，还有两个组件： kube-scheduler 和 kube-controller-manager ，它们虽然在3个 master 中均部署了3份副本，但是实际上只有一个在真正工作。
3个组件如何在集群中相互协调决定哪一个真正工作，其背后原理是 leader election，使用了 client-go 中的 tools/leaderelection 包完成选举的行为。
k8s 核心组件，其中 apiserver 只用于接收 api 请求，不会主动进行各种动作，所以他们在每个节点都运行并且都可以接收请求，不会造成异常；kube-proxy 也是一样，只用于做端口转发，不会主动进行动作执行。
但是 scheduler, controller-manager 不同，他们参与了 Pod 的调度及具体的各种资源的管控，如果同时有多个 controller-manager 来对 Pod 资源进行调度，结果太美不敢看，那么 k8s 是如何做到正确运转的呢？
在kubernetes的世界中，很多组件仅仅需要一个实例在运行，比如controller-manager或第三方的controller，但是为了高可用性，需要组件有多个副本，在发生故障的时候需要自动切换。
因此，需要利用leader election的机制多副本部署，单实例运行的模式。
kubernetes API 提供了一中选举机制，只要运行在集群内的容器，都是可以实现选举功能的。
Kubernetes API通过提供了两个属性来完成选举动作的
- ResourceVersions：每个API对象唯一一个ResourceVersion
- Annotations：每个API对象都可以对这些key进行注释
注：这种选举会增加APIServer的压力，也就对etcd会产生影响。
在Kubernetes中所有启用了leader选举的服务都会生成一个 EndPoint ，在这个 EndPoint 中会有上面提到的label（Annotations）来标识谁是leader。
基本概念
多个成员参与 leader election 的行为中，成为分为两类：
- leader
- candidate
其中 leader 为真正工作的成员，其他成员为 candidate ，它们并没有在执行工作而是随时等待成为 leader 并开始工作。在它们运行之初都是 candidate，初始化时都会去获取一个唯一的锁，谁抢到谁就成为 leader 并开始工作，在 client-go 中这个锁就是 apiserver 中的一个资源，资源类型一般是 CoordinationV1() 资源组中的 Lease 资源。
在 leader 被选举成功之后，leader 为了保住自己的位置，需要定时去更新这个 Lease 资源的状态，即一个时间戳信息，表明自己有在一直工作没有出现故障，这一操作称为续约。其他 candidate 也不是完全闲着，而是也会定期尝试获取这个资源，检查资源的信息，时间戳有没有太久没更新，否则认为原来的 leader 故障失联无法正常工作，并更新此资源的 holder 为自己，成为 leader 开始工作并同时定期续约。
3个时间参数：
- leaseDuration leader 续约一次的有效期
- RenewDeadline 续租超时时间，leader 每次续租执行时间超过此时间认为失败，将 lease 释放
- RetryPeriod leader 续约周期，candidate 循环获取锁的周期
查询
# kubectl get ep -n kube-system
NAME ENDPOINTS AGE
kube-controller-manager <none> 3d4h
kube-dns 3d4h
kube-scheduler <none> 3d4h
# kubectl describe ep kube-controller-manager -n kube-system
Name: kube-controller-manager
Namespace: kube-system
Labels: <none>
Annotations: control-plane.alpha.kubernetes.io/leader:
{"holderIdentity":"master-machine_06730140-a503-487d-850b-1fe1619f1fe1","leaseDurationSeconds":15,"acquireTime":"2022-06-27T15:30:46Z","re...
Subsets:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal LeaderElection 2d22h kube-controller-manager master-machine_76aabcb5-49ff-45ff-bd18-4afa61fbc5af became leader
Normal LeaderElection 9m kube-controller-manager master-machine_06730140-a503-487d-850b-1fe1619f1fe1 became leader
# kubectl get leases -n kube-system
NAME HOLDER AGE
kube-controller-manager k8s-master02_7a9bfa6b-fde8-4f08-aab0-377c686cc9c9 441d
kube-scheduler k8s-master02_216f9c60-02b5-4e8c-ada1-e4a4f307fc94 441d
可以看出 Annotations: control-plane.alpha.kubernetes.io/leader: 标出了哪个node是leader。
参考
从零开始入门 K8s | 手把手带你理解 etcd
https://kb.cnblogs.com/page/653528/
Kubernetes 控制面组件高可用原理之 Leader Election
https://ruofeng.me/2020/07/07/k8s-leader-election/
深入解析kubernetes中的选举机制
https://dev.to/cylon/shen-ru-jie-xi-kuberneteszhong-de-xuan-ju-ji-zhi-5hbe
Kubernetes 实战-Leader 选举
https://zdyxry.github.io/2019/09/12/Kubernetes-%E5%AE%9E%E6%88%98-Leader-%E9%80%89%E4%B8%BE/
