election

README

Date: 01/20/17

This package is imported from Kubernetes 1.5 branch .

client-go doesn’t have leader election package imported at the time of writing.
We are trying our best to communicate with upstream and get that package imported to client-go.

Meanwhile, that process is slow, and even complicated due to a few aspects:

- The importing work seems to be happening on 2.0/master but not 1.5 that we are using.
- We are using client-go 1.5 which is k8s 1.4, and we need to pull packages from k8s 1.5 due to some concern.
  This is mixing versions, which gets things more complicated.
- This might introduce new API to client-go 1.5, which might get things more complicated.
- There are still concerns on upstream on “write to endpoints”. This is the most complicated.

The situation is complicated, and we need to expedite our work.
Thus, we fork "pkg/client/leaderelection" from Kubernetes 1.5 branch to our repo.

Nonetheless, we should try our best to push the changes to upstream and communicate with community members to resolve the problem.
After that we should replace it to client-go again.

Documentation

Overview

Package election 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.

Index

• Constants
• func RunOrDie(lec LeaderElectionConfig)
• type LeaderCallbacks
• type LeaderElectionConfig
• type LeaderElector
  • func NewLeaderElector(lec LeaderElectionConfig) (*LeaderElector, error)
  • func (le *LeaderElector) GetLeader() string
  • func (le *LeaderElector) IsLeader() bool
  • func (le *LeaderElector) Run()

Constants

const (
	JitterFactor         = 1.2
	DefaultLeaseDuration = 15 * time.Second
	DefaultRenewDeadline = 10 * time.Second
	DefaultRetryPeriod   = 2 * time.Second
)

Functions

func RunOrDie

func RunOrDie(lec LeaderElectionConfig)

RunOrDie starts a client with the provided config or panics if the config fails to validate.

Types

type LeaderCallbacks

type LeaderCallbacks struct {
	// OnStartedLeading is called when a LeaderElector client starts leading
	OnStartedLeading func(stop <-chan struct{})
	// OnStoppedLeading is called when a LeaderElector client stops leading
	OnStoppedLeading func()
	// OnNewLeader is called when the client observes a leader that is
	// not the previously observed leader. This includes the first observed
	// leader when the client starts.
	OnNewLeader func(identity string)
}

LeaderCallbacks are callbacks that are triggered during certain lifecycle events of the LeaderElector. These are invoked asynchronously.

possible future callbacks:

• OnChallenge()

type LeaderElectionConfig

type LeaderElectionConfig struct {
	// Lock is the resource that will be used for locking
	Lock rl.Interface

	// LeaseDuration is the duration that non-leader candidates will
	// wait to force acquire leadership. This is measured against time of
	// last observed ack.
	LeaseDuration time.Duration
	// RenewDeadline is the duration that the acting master will retry
	// refreshing leadership before giving up.
	RenewDeadline time.Duration
	// RetryPeriod is the duration the LeaderElector clients should wait
	// between tries of actions.
	RetryPeriod time.Duration

	// Callbacks are callbacks that are triggered during certain lifecycle
	// events of the LeaderElector
	Callbacks LeaderCallbacks
}

type LeaderElector

type LeaderElector struct {
	// contains filtered or unexported fields
}

LeaderElector is a leader election client.

possible future methods:

• (le *LeaderElector) IsLeader()
• (le *LeaderElector) GetLeader()

func NewLeaderElector

func NewLeaderElector(lec LeaderElectionConfig) (*LeaderElector, error)

NewLeadereElector creates a LeaderElector from a LeaderElecitionConfig

func (*LeaderElector) GetLeader

func (le *LeaderElector) GetLeader() string

GetLeader returns the identity of the last observed leader or returns the empty string if no leader has yet been observed.

func (*LeaderElector) IsLeader

func (le *LeaderElector) IsLeader() bool

IsLeader returns true if the last observed leader was this client else returns false.

func (*LeaderElector) Run

func (le *LeaderElector) Run()

Run starts the leader election loop