Package leaderelection - 0 stars

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.