-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: migrate leaderelection lock to leases #8733
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -93,12 +93,24 @@ func setupLeaderElection(config *leaderElectionConfig) { | |
Host: hostname, | ||
}) | ||
|
||
lock := resourcelock.ConfigMapLock{ | ||
ConfigMapMeta: metav1.ObjectMeta{Namespace: k8s.IngressPodDetails.Namespace, Name: config.ElectionID}, | ||
Client: config.Client.CoreV1(), | ||
LockConfig: resourcelock.ResourceLockConfig{ | ||
Identity: k8s.IngressPodDetails.Name, | ||
EventRecorder: recorder, | ||
objectMeta := metav1.ObjectMeta{Namespace: k8s.IngressPodDetails.Namespace, Name: config.ElectionID} | ||
resourceLockConfig := resourcelock.ResourceLockConfig{ | ||
Identity: k8s.IngressPodDetails.Name, | ||
EventRecorder: recorder, | ||
} | ||
|
||
// TODO: If we upgrade client-go to v0.24 then we can only use LeaseLock. | ||
// MultiLock is used for lock's migration | ||
lock := resourcelock.MultiLock{ | ||
Primary: &resourcelock.ConfigMapLock{ | ||
ConfigMapMeta: objectMeta, | ||
Client: config.Client.CoreV1(), | ||
LockConfig: resourceLockConfig, | ||
}, | ||
Secondary: &resourcelock.LeaseLock{ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If this is primary instead, will this be used in v1.24 test? So we may know if this is working fine. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @tao12345666333 ping on this. Can we set LeaseLock as Primary and ConfigMapLock as secondary, and see how this behaves? Also, can we re-add v1.24 tests in CI? :D There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Setting ConfigMapLock as Primary here is to allow users to migrate smoothly. ref: ref: #8733 (comment) I can add tests for v1.24. |
||
LeaseMeta: objectMeta, | ||
Client: config.Client.CoordinationV1(), | ||
LockConfig: resourceLockConfig, | ||
}, | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When was LeaseLock created? If in v1.21, we can leave in the TODO here that part of the stabilization code will contain only LeaseLock and no ConfigMap anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rikatz Probably in v1.14.
The original intention of adding
MultiLock
here is to allow users who have installed ingress-nginx to migrate smoothly.E.g:
The user has already installed ingress-nginx , then when the user installs a new version of ingress-nginx controller containing the code in this PR, we will help it smoothly migrate from configmap to LeaseLock.
When we release ingress-nginx that only supports LeaseLock in the future, users can not be breaked.
If we only consider newly installed users, LeaseLock can be used directly here. (But I don't think it's appropriate)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And we may need to release at least two versions.
A release is the one that contains this PR code. (for lock migration)
One version is the one that contains only LeaseLock code (for full compatibility with Kubernetes v1.24, including the version that upgrades client-go to 1.24)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Let's move forward with this, and plan the new release after freeze without the MultiLock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rikatz So, I guess all I need to do is add tests for the v1.24 version of K8s, right?
In our upcoming release, I would like to set ConfigMapLock to Primary to allow smooth migration for existing users.