KEP-4355: Coordinated Leader Election

[jpbetz]

trafficstars

• One-line PR description: Coordinated Leader Election KEP

• Issue link: https://github.com/kubernetes/enhancements/issues/4355

• Other comments:
  • Prototype: https://github.com/jpbetz/kubernetes/tree/leader-election-controller/demo

[k8s-ci-robot]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jpbetz

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:

• ~~keps/sig-api-machinery/OWNERS~~ [jpbetz]

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

[jpbetz]

@logicalhan

[pacoxu]

/cc @neolit123

[jpbetz]

cc @Jefftree

[jpbetz]

/assign @sttts

[warmchang]

/test pull-enhancements-verify

[Jefftree]

I would definitely like to see more extensibility here - I can definitely imagine cases where we control compatibility story and can guarantee forward compatibility, but we want to limit the number of reelections (e.g. don't have 3 reelections during upgrade, but immediately change to the newest one) because e.g. initialization is very slow or sth like that. [The current example where this may be the case is cluster-autoscaler]. So yes - can we please add a user-story along those lines and add Beta criteria to reevaluate extensibility?

ack, added a user story. We haven't really thought about advanced cases like limiting number of reelections, but will definitely support things like immediately switching to the latest version via the Strategy configuration option in a Lease. This field and available strategies will be re-evaluated for beta, but for alpha we will offer only OldestCompatibilityVersion

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: Jefftree / name: Jeffrey Ying (50641e837a74bf51624871798e82304916f2d0f8, 5b1ebace0f79110dc7a3d06fa4328c2497880285, 1176c9528961900dfd72689b80089d153a26c749, dbd726ba52e13776b804d316ecdbfe77f30974be, 1732f4a6566ba889bdb03fe84318a3f3c2f1afa0, 2984c452a0440e3402664228c3a618347adc2d9d)
• :white_check_mark: login: jpbetz / name: Joe Betz (529c9d675c5e2214a9320f80a1dbbdcb77f1a288, e61905fc005ccdb87d46b5eb6987cb3457201c43, 28e2e7514e9ee36e8cbd88f8d554a79ce45686a3, 3e9f6a8c263d27a158d922804d7ad735d3d8d799, 8b0d0c7137ca150bd8b6e72d5e25e1a9dc37b8eb, 22772990e95b6fc2c9f78f6218ae9a1e00cd4aeb, f653f8e00a30d72afe1275bff2fa5dd223b7fbc1, 88de5196e823f6391b8823c9ed8b36682b39248b)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jpbetz

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:

• ~~keps/prod-readiness/OWNERS~~ [jpbetz]
• ~~keps/sig-api-machinery/OWNERS~~ [jpbetz]

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

[Jefftree]

This is missing the PRR doc in https://github.com/kubernetes/enhancements/tree/master/keps/prod-readiness/sig-api-machinery Drop my name there :)

Thanks, added!

[jpbetz]

My main concerns with the strategy have been addressed. I'll leave LGTM to @sttts since he's done a TON of review on this one (huge thanks!)

[sttts]

Same. For alpha we are good here I think. Some details around API design will be discussed during API review (the bool comes to mind).

/lgtm

[Jefftree]

Thanks for the review Stefan!

I didn't expect this to merge, it looks like Joe is also a prod-readiness approver so this got automatically merged. @soltysh, for prod readiness would it be fine if you commented here and I can open a follow up PR to address any concerns? Thanks!

[soltysh]

I didn't expect this to merge, it looks like Joe is also a prod-readiness approver so this got automatically merged. @soltysh, for prod readiness would it be fine if you commented here and I can open a follow up PR to address any concerns? Thanks!

Joe is PRR approver, so I guess that's how it auto-approved. I went through the doc, and in general it's ok. The two missing bits (non-blocking) are:

1. At least beta requirements, I've noticed Stefan requested adding additional strategies during that phase, so it would be nice to call it out, so it doesn't get forgotten. Ideally, it would be also call out stable graduation requirements.
2. Optional, but highly useful would be to add metrics, especially that I'm guessing you'll be building on the existing (leader election metrics)[https://github.com/kubernetes/client-go/blob/master/tools/leaderelection/metrics.go], are you planning to add more?