LeaderElector.canBecomeLeader should read the leaseDuration from the Kube Lease object and not from local configuration

[zoliszel]

Describe the bug

Hi there,

to decide if the current process can become leader, io.fabric8.kubernetes.client.extended.leaderelection.LeaderElector infers expiry of a lease using its local lease duration configuration:

  protected final boolean canBecomeLeader(LeaderElectionRecord leaderElectionRecord) {
    return Utils.isNullOrEmpty(leaderElectionRecord.getHolderIdentity())
        || now().isAfter(leaderElectionRecord.getRenewTime().plus(leaderElectionConfig.getLeaseDuration()));
  }

This is incorrect, applications within the same cluster can/will use different KubeAPI clients and even then different applications can decide to acquire the lease for their own duration of choice.

The duration of the lease is maintained in the lease.spec.leaseDurationSeconds field inside of the LeaderElectionRecord object which should be used to source how long the lease is held by the current owner.

This can lead to be premature loss of lease if 2 clients using different leaseDurations are deployed into the same cluster.

Fabric8 Kubernetes Client version

SNAPSHOT

Steps to reproduce

• Prepare 2 LeaderElector,
  • LE1: LeaseDuration of 10s, retry period 1s (LE1),
  • LE2: LeaseDuration of 30s, retry period, 20s(LE2)
• Start LE2 first , let it acquire the lease, then start LE1

Expected behavior

LE2 should keep hold of the lease until its shut down, but LE1 will take over instead.

Runtime

Kubernetes (vanilla)

Kubernetes API Server version

1.33

Environment

Linux

Fabric8 Kubernetes Client Logs

Additional context

No response

[shawkins]

I believe this is one of several things that changed in the go client after the initial port to the fabric8 client, but has never been implemented on the fabric8 side.

https://github.com/kubernetes/client-go/blob/3a4ad9c658b1bd280b1ddf397669c9876b05fdba/tools/leaderelection/leaderelection.go#L360