Skip to content

LeaderElector calculates when the lease is expired incorrectly #1599

Closed as not planned
@gdemeter-kx

Description

@gdemeter-kx

Describe the bug
In case a Lease does not currently have a Leader who would renew the lease and it is already expired, the new Leader can't
immediately acquire it.

During leader election observedTime is set to observedTime = DateTimeOffset.Now which makes the calculation whether the Lease is expired incorrect. Eventually it will become the leader, but for config.LeaseDuration the Lease may not have a leader.

I created the following change on my fork, which seems to solve the issue:

  • observedTime should be the RenewTime of the observedRecord
  • Checking whether a Lease is expired should be calculated based on the observedRecord RenewTime and it's config. Not ours.

image

Kubernetes C# SDK Client Version
e.g. 9.0.1

Server Kubernetes Version
e.g. 1.22.3

Dotnet Runtime Version
e.g. net6

To Reproduce
Steps to reproduce the behavior:

  • Create a LeaderElector and dispose it. Wait for the Lease to be expired. Create another one for the same Lease. It will take config.LeaseDuration time to acquire the Lease even though it is expired.

Expected behavior
Considering the scenario explained in the To Reproduce part, I would expect the second Leader to immediately get the Lease.

KubeConfig
If applicable, add a KubeConfig file with secrets redacted.

Where do you run your app with Kubernetes SDK (please complete the following information):

  • OS: [e.g. Linux]
  • Environment [e.g. container]
  • Cloud [e.g. Azure]

Additional context
Add any other context about the problem here.

Metadata

Metadata

Assignees

Labels

lifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions