为了执行leader选举，Kubernetes文档建议在候选pod集合中部署sidecar。
https://kubernetes.io/blog/2016/01/simple-leader-election-with-kubernetes/
这个sidecar遵循以下步骤来选举一个领导者。
1.如果不存在有效的leader，每个sidecar都会尝试原子地更新Kubernetes端点对象。只有一个sidecar可以成功更新端点对象。
1.更新端点的sidecar将在指定的时间段内担任leader。
1.当前领导者将再次更新端点以延长持续时间，从而保留领导者。
1.当存在有效的引线时，其他sidecar将不会再次尝试更新端点。
1.如果当前leader在该时间段内没有更新端点，则其他sidecar将认为该leader被撤销。所有sidecar将转到步骤1。
这种方法有几个问题。
1.可以在短时间内同时运行两个引线。

示例：

如果当前leader挂起并且无法及时更新端点，则其他sidecar之一将获得leader。但前任领导人需要一段时间才能意识到他们的领导地位被撤销。在这段短暂的时间内，现有的2个leader可以破坏共享资源/数据。
这一点在源代码中也有提及。

This implementation does not guarantee that only one client is acting as a leader (a.k.a. fencing).

1.此Sidecar的源代码已退休/存档。因此，它并没有积极发展。https://github.com/kubernetes-retired/contrib/tree/master/election
那么，用Kubernetes选举领导者的正确方法是什么？