Package leaderelection implements leader election of a set of endpoints. It uses an annotation in the endpoints object to store the record of the election state.
This implementation does not guarantee that only one client is acting as a leader (a.k.a. fencing). A client observes timestamps captured locally to infer the state of the leader election. Thus the implementation is tolerant to arbitrary clock skew, but is not tolerant to arbitrary clock skew rate.
However the level of tolerance to skew rate can be configured by setting RenewDeadline and LeaseDuration appropriately. The tolerance expressed as a maximum tolerated ratio of time passed on the fastest node to time passed on the slowest node can be approximately achieved with a configuration that sets the same ratio of LeaseDuration to RenewDeadline. For example if a user wanted to tolerate some nodes progressing forward in time twice as fast as other nodes, the user could set LeaseDuration to 60 seconds and RenewDeadline to 30 seconds.
While not required, some method of clock synchronization between nodes in the cluster is highly recommended. It's important to keep in mind when configuring this client that the tolerance to skew rate varies inversely to master availability.
Larger clusters often have a more lenient SLA for API latency. This should be taken into account when configuring the client. The rate of leader transitions should be monitored and RetryPeriod and LeaseDuration should be increased until the rate is stable and acceptably low. It's important to keep in mind when configuring this client that the tolerance to API latency varies inversely to master availability.
DISCLAIMER: this is an alpha API. This library will likely change significantly or even be removed entirely in subsequent releases. Depend on this API at your own risk.