k8s选主机制应用

k8s leader election

k8s的client-go提供了选主的工具，方便应用可以利用k8s的能力，实现主从模型。函数路径在"k8s.io/client-go/tools/leaderelection"下。
选主示例代码：
https://github.com/kubernetes/client-go/tree/master/examples/leader-election
关于选主原理的讲解及使用，网上已经有很多讲解的文章。这里主要记录对于不同的故障下，主从关系的变化。
我们的代码中，使用如下参数：

LeaseDuration:   20 * time.Second,
RenewDeadline:   10 * time.Second,
RetryPeriod:     2 * time.Second,

三个节点分别运行：

main -kubeconfig=/etc/rancher/k3s/k3s.yaml -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=1
main -kubeconfig=/etc/rancher/k3s/k3s.yaml -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=2
main -kubeconfig=/etc/rancher/k3s/k3s.yaml -logtostderr=true -lease-lock-name=example -lease-lock-namespace=default -id=3

故障一：leader正常退出

主节点Ctrl + C 退出：可以看到节点3立马成为Leader节点。

go func() {
	<-ch
	klog.Info("Received termination, signaling shutdown")
	cancel()
}()

leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{}）

因为Ctrl + C 退出时，对ctx进行了cancel()，此时leaderelection.RunOrDie上下文也正常退出，此时主从切换可以按照正常的流程很快处理响应。

故障二：leader进程被kill

将Leader进程kill掉后，可以看到其他的slave进程并非是立马成为Leader，而是在24s后，节点2竞争成为Leader。这个时间长短和LeaseDuration的时间设置有关。

故障三：leader网路通信故障

将Leader节点的网络断开，此时Leader节点和k8s的网络通信中断。可以发现：
1）24s后，slave节点竞争成为Leader；
2）10s后，leader renew失败；再过15s，release Lock超时，失去Leader的地位。