Default LeaderElectionResourceLock to leases

[CecileRobertMichon]

What type of PR is this?

What this PR does / why we need it: Controller runtime sets by default leader-election-resource-lock to ConfigMapsLeasesResourceLock so consumers can do smooth transitions.
This PR default our controller to leases.

This mitigates overwhelming the apiserver in a large management cluster and avoids additional rbac.

refer to kubernetes-sigs/cluster-api#5388 and https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/book/src/developer/providers/v1alpha4-to-v1beta1.md#warning-leaderelectionresourcelock-change-warning

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1761

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

TODOs:

• squashed commits
• includes documentation
• adds unit tests

Release note:

Default LeaderElectionResource to v1.Lease

[CecileRobertMichon]

/assign @enxebre @shysank @devigned

[shysank]

We are using controller runtime v0.5.14 in capz v0.4.15. Will this be a problem when users upgrade from 0.4.15?

[CecileRobertMichon]

@shysank why do you say that? @enxebre do you know if there is a problem with upgrading from controller runtime v0.5.14? If there is, it would be the same for CAPA as their latest alpha3 release v0.6.8 is also using controller runtime v0.5.14 https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/v0.6.8/go.mod kubernetes-sigs/cluster-api-provider-aws#2822

[shysank]

@shysank why do you say that?

My understanding is controller-runtime prior to v0.7 defaulted lock resource to configmaps, and then v0.7 changed it to multi lock with configmaps + leases so that it doesn't break when we switch to only leases. That's why I was wondering what would happen if we switched directly from configmaps to leases.

[enxebre]

There's a risk for users going from "configmaps" -> "leases". My understanding is that upgrades through clusterctl stop the old controllers before running the new ones during an upgrade, if that's the case we are all good.

Users relying on custom upgrades procedures should either ensure a migration to multilock "configmapsleases" first, which will acquire a leader lock on both resources and then proceed to "leases" or ensure the old controllers are stopped before running the new ones with the new lock mechanism. Otherwise, the controller might end up with multiple running instances that each acquired leadership through different resource locks during upgrades and thus act on the same resources concurrently. https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/book/src/developer/providers/v1alpha4-to-v1beta1.md#warning-leaderelectionresourcelock-change-warning

tldr if old controllers are stopped before running the new ones all good.

[shysank]

/lgtm since old controllers are going to be removed first before the new ones are installed. One thing we should perhaps confirm is to check if there are no dangling config maps that were created for acquiring locks. I'm guessing they will be garbage collected.

[devigned]

/lgtm

[CecileRobertMichon]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CecileRobertMichon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [CecileRobertMichon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment