Skip to content
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

Improve leader election #5282

Open
danielnginx opened this issue Mar 20, 2024 · 1 comment
Open

Improve leader election #5282

danielnginx opened this issue Mar 20, 2024 · 1 comment
Assignees
Labels
backlog Pull requests/issues that are backlog items proposal An issue that proposes a feature request

Comments

@danielnginx
Copy link
Collaborator

danielnginx commented Mar 20, 2024

Is your feature request related to a problem? Please describe.
We should be able to scale NGINX Ingress Controller in a very large cluster with minimal Kubernetes API calls.
This particular problem comes from having multiple NIC deployments in a single cluster combined with the new K8s pattern of the leader API.

Describe the solution you'd like
Minimize impact on the K8s API to maintain leader for a NIC deployment.

Describe alternatives you've considered
Remove the historic configmap leader maintenance code

  • Releases 3.2 and 3.3 performed both configmap and leader API calls. It is believed this was left for compatibility at the time and no negative reports had been received.

Change the interval that the Kubernetes API is called to check the leader/during the leader election.

  • while exposing knobs to tune leader behavior is possible, at scale it is determined that to get the leader API activity low enough any benefits from leader being the single pod to report configuration state would be negated due to the reported state being potentially lost for an extended period of time if a leader is lost.

Consider an external data store

  • the project does not want to build any dependency on any additional or external component only for leader state maintenance. This not only adds complexity to the system but expands the potential for failure.

Invent our own solution which maintains reasonably accurate state for leader

  • while it is believed that K8s needs to provide a long term solution to this problem, we cannot wait for that solution to be delivered.

Additional context

This is a problem that is being discussed in the larger K8s community where it has also been identified:

### Tasks
- [ ] https://github.com/nginxinc/kubernetes-ingress/issues/5295
@danielnginx danielnginx added proposal An issue that proposes a feature request backlog Pull requests/issues that are backlog items labels Mar 20, 2024
@brianehlert brianehlert added this to the v3.6.0 milestone Mar 21, 2024
@brianehlert brianehlert changed the title Improve leader election Epic - Improve leader election Mar 21, 2024
@brianehlert brianehlert added the epic Issues that need to be broken into smaller issues label Mar 21, 2024
@brianehlert
Copy link
Collaborator

The design task is marked as completed. This should not be moving past that at this time.

@brianehlert brianehlert removed this from the v3.6.0 milestone Apr 24, 2024
@brianehlert brianehlert added this to the v3.7.0 milestone Jul 5, 2024
@shaun-nx shaun-nx changed the title Epic - Improve leader election Improve leader election Jul 12, 2024
@shaun-nx shaun-nx modified the milestones: v3.7.0, v3.8.0 Aug 15, 2024
@shaun-nx shaun-nx modified the milestones: v3.8.0, Candidates Sep 5, 2024
@shaun-nx shaun-nx removed the epic Issues that need to be broken into smaller issues label Oct 14, 2024
@lucacome lucacome moved this to Prioritized backlog in NGINX Ingress Controller Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Pull requests/issues that are backlog items proposal An issue that proposes a feature request
Projects
Status: Prioritized backlog
Development

No branches or pull requests

4 participants