Kubernetes controller-manager Leader Election 机制来实现故障转移（Fail Over）_综合

重学k8s: 04.Kubernetes集群高可用解析 - 架构小白|青蛙小白|关注程序开发、互联网技术、云原生向 Kubernetes 学习 - Controller manager 的高可用实现方式 - 人间指南向 Kubernetes 学习 - Controller manager 的高可用实现方式这不是一系列入门级别的文章，也不是按部就班而来的，而是我看到哪里，发现有些代码写的精妙的地方，都值得我们学习下，顺手记录下来，一方面是让自己将来可以有迹可循，另外对大家应该也会有所帮助。 …http://liubin.org/blog/2018/04/28/how-to-build-controller-manager-high-available

https://blog.heptio.com/leader-election-in-kubernetes-control-plane-heptioprotip-1ed9fb0f3e6dhttps://blog.heptio.com/leader-election-in-kubernetes-control-plane-heptioprotip-1ed9fb0f3e6d

--leader-elect=true：集群运行模式，启用选举功能；被选为 leader 的节点负责处理工作，其它节点为阻塞状态；

Controller Manager

控制器是Kubernetes 集群的自动化管理控制中心，里面包含30 多个控制器，有Pod管理的（Replication 控制器、Deployment 控制器等）、有网络管理的（Endpoints 控制器、Service 控制器等）、有存储相关的（Attachdetach 控制器等），等等。在1.2.5 节的例子中，我们已经见识到部分控制器是如何工作的。大多数控制器的工作模式雷同，都是通过API Server 监听其相应的资源对象，根据对象的状态来决定接下来的动作，使其达到预期的状态。

很多场景都需要多个控制器协同工作，比如某个节点宕机，kubelet 将会停止汇报状态到Node 对象。NodeLifecycle 控制器会发现节点状态没有按时更新，超过一段时间（可通过参数--pod-eviction-timeout 来指定）后，它将驱逐节点上的Pod。如果这个Pod 属于某个Deployment 对象，那么Deployment 对象所需的副本数量将减少，这时Deployment 控制器将会补齐Pod 副本数量，替换掉因为宕机而被删除的Pod。

控制器采用主备模式和Leader Election 机制来实现故障转移（Fail Over），如图所示，也就是说允许多个副本处于运行状态，但是只有一个副本作为领导者在工作，其他副本作为竞争者则不断尝试获取锁，试图通过竞争成为领导者。一旦领导者无法继续工作，其他竞争者就能立刻竞争上岗，而无须等待较长的创建时间。

在Kubernetes 中，锁就是一个资源对象，目前支持的资源是 Endpoint 和 Configmap。控制器的锁在 kube-system Namespace 下名为kube-controller-manager 的Endpoint 对象中。

Kubernetes controller-manager Leader Election 机制来实现故障转移（Fail Over）

图1-12 Leader Election 的工作机制

Leader Election 有三个与时间相关的参数：leaseDuration、renewDeadline 和retryPeriod。

第一个参数leaseDuration 是指资源锁定后的租约时间，竞争者在该时间间隔内不能锁定资源，如果领导者在这段时间间隔后没有更新锁时间，则竞争者可以认为领导者已经挂掉，不能正常工作了，将重新选举领导者。

第二个参数renewDeadline 是指，领导者主动放弃锁，当它在renewDeadline 内没有成功地更新锁，它将释放锁。当然如果更新锁无法成功地执行，那么释放锁大概率也无法成功地执行，所以在Kubernetes 中这种情况很少见。

第三个参数retryPeriod 是指竞争者获取锁和领导者更新锁的时间间隔。这种Leader Election 机制保证了集群组件的高可用性，如果领导者因为某种原因无法继续提供服务，则由其他竞争者副本竞争成为新的领导者，继续执行业务逻辑。

控制器高可用保证

Kubernetes 提供了Leader 选举机制，用以确保多个控制器的实例同时运行，并且只有Leader 实例提供真正的服务。其他实例处于准备就绪状态，如果Leader 出现故障，则取代Leader 以保证Pod 能被及时调度。此机制以占用更多资源为代价，提升了Kubernetes控制器的可用性。

Leader 选举的核心是利用 Configmap 、 Endpoints 或 Lease 对象实现分布式资源锁。当多个实例同时启动后，在运行任何业务逻辑之前，都会尝试读取该资源锁。

以 Lease 对象为例，在首次抢占过程中，该对象无任何 Leader 信息，第一个尝试占有锁的实例会更新该对象的acquireTime 和 holderIdentity ，并以 leaseDurationSeconds 为周期不断更新renewTime 。

控制器的判断逻辑是：只有当 holderIdentity 与当前实例的 Pod 名称完全匹配时，控制器的程序执行才继续，否则等待获取锁。如果Leader 能保证在固定周期内及时更新renewTime ，则该锁始终被 Leader 占有，任何其他实例周期性地尝试更新 holderIdentity 以成为新的 Leader 。该机制保证 Leader 实例出现故障或网络断开时，其Leader租约会到期，其他实例可抢占资源锁迅速成为新Leader。 Lease 对象的示例代码如下：

[root@master ~]# kubectl describe lease kube-controller-manager -n kube-system   | grep "Renew Time"Renew Time:              2022-01-07T10:22:35.179300Z
[root@master ~]# kubectl describe lease kube-controller-manager -n kube-system   | grep "Renew Time"Renew Time:              2022-01-07T10:25:20.077266Z
[root@master ~]# kubectl describe lease kube-controller-manager -n kube-system   | grep "Renew Time"Renew Time:              2022-01-07T10:35:55.490311Z

Spec:Acquire Time:            2022-01-07T09:45:11.131059ZHolder Identity:         master_9b5e459c-e7a9-4501-973c-6ece3ca60b14Lease Duration Seconds:  15Lease Transitions:       2Renew Time:              2022-01-07T10:18:33.966038Z

Kubernetes controller-manager Leader Election 机制来实现故障转移（Fail Over）资源锁可保存在Configmap、Endpoints 和Lease 三种对象中。推荐使用Lease，因为Lease 对象本身就是用来协调租约对象的，其Spec 定义与Leader 选举机制需要操控的属性是一致的。使用Configmap 和Endpoints 对象更多是为了向后兼容，伴随着一定的负面影响。

以Endpoints 为例，Leader 每隔固定周期就要续约，这使得Endpoints 对象处于不断的变化中。Endpoints 对象会被每个节点的kube-proxy 等监听，任何Endpoints 对象的变更都会推送给所有节点的kube-proxy，这为集群引入了不必要的网络流量。

任何集群控制器均可基于 Leader 选举机制进行开发部署。调度器是一个 “ 特殊 ” 的控

制器，它基于 Leader 选举机制，用于保证服务高可用。

[root@master ~]# kubectl get lease -n kube-system
NAME                      HOLDER                                        AGE
kube-controller-manager   master_9b5e459c-e7a9-4501-973c-6ece3ca60b14   3d2h
kube-scheduler            master_6d0957aa-fed5-45d4-8d10-d4bb9d84cb33   3d2h[root@master ~]# kubectl describe lease kube-controller-manager -n kube-system
Name:         kube-controller-manager
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  coordination.k8s.io/v1
Kind:         Lease
Metadata:Creation Timestamp:  2022-01-04T07:55:07ZManaged Fields:API Version:  coordination.k8s.io/v1Fields Type:  FieldsV1fieldsV1:f:spec:f:acquireTime:f:holderIdentity:f:leaseDurationSeconds:f:leaseTransitions:f:renewTime:Manager:         kube-controller-managerOperation:       UpdateTime:            2022-01-04T07:55:07ZResource Version:  38242UID:               4ff687c3-ed7f-46eb-8899-cdf6eca7e874
Spec:Acquire Time:            2022-01-07T09:45:11.131059ZHolder Identity:         master_9b5e459c-e7a9-4501-973c-6ece3ca60b14Lease Duration Seconds:  15Lease Transitions:       2Renew Time:              2022-01-07T10:18:33.966038Z
Events:Type    Reason          Age   From                     Message----    ------          ----  ----                     -------Normal  LeaderElection  33m   kube-controller-manager  master_9b5e459c-e7a9-4501-973c-6ece3ca60b14 became leader