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

[Bug]: Multiple NGINX Ingress Controllers doesn't work well #6891

Open
hanyouqing opened this issue Dec 3, 2024 · 5 comments · May be fixed by #6893
Open

[Bug]: Multiple NGINX Ingress Controllers doesn't work well #6891

hanyouqing opened this issue Dec 3, 2024 · 5 comments · May be fixed by #6893
Labels
proposal An issue that proposes a feature request

Comments

@hanyouqing
Copy link
Contributor

hanyouqing commented Dec 3, 2024

Version

3.6.1

What Kubernetes platforms are you running on?

Rancher

Steps to reproduce

Step 1: Deploy Default Nginx-Ingress
Deploy the default nginx-ingress controller with the default ingressClass set to nginx.

Step 2: Deploy Namespace-Specific Nginx-Ingress
Deploy a namespace-specific nginx-ingress controller with the ingressClass set to nginx-team-c.

Step 3: Create VirtualServer Resources
Create three VirtualServer resources with the following configurations:

  • VirtualServer A: No ingressClassName specified.
  • VirtualServer B: ingressClassName set to nginx.
  • VirtualServer C: ingressClassName set to nginx-team-c.

Expected Behavior
The expected behavior is that
- VirtualServer A and B are handled by the default nginx ingress controller,
- VirtualServer C is handled by the nginx-team-c ingress controller.

Observed Behavior
However, it has been observed that VirtualServer A is being handled by both the nginx and nginx-team-c ingress controllers, which is not the expected behavior.

If VirtualServer A includes some customized configurations that depend on third-party plugin (for example include a GeoIP file) only integrated with nginx-team-c and the ingressClassName was missed by somebody, then the current behavior will break the default nginx ingress.

@hanyouqing hanyouqing added bug An issue reporting a potential bug needs triage An issue that needs to be triaged labels Dec 3, 2024
Copy link

github-actions bot commented Dec 3, 2024

Hi @hanyouqing thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

@hanyouqing
Copy link
Contributor Author

This can be fixed in #6893

@vepatel
Copy link
Contributor

vepatel commented Dec 3, 2024

Hi @hanyouqing this is expected behaviour as of now, see #3 in https://docs.nginx.com/nginx-ingress-controller/installation/run-multiple-ingress-controllers/#ingress-class and point 2 in the note below

@vepatel vepatel added proposal An issue that proposes a feature request and removed bug An issue reporting a potential bug needs triage An issue that needs to be triaged labels Dec 3, 2024
@hanyouqing
Copy link
Contributor Author

Hi @hanyouqing this is expected behaviour as of now, see #3 in https://docs.nginx.com/nginx-ingress-controller/installation/run-multiple-ingress-controllers/#ingress-class and point 2 in the note below

Thank you @vepatel; I have read this documentation before creating this issue.

I have two questions:

  1. More than one ingress controller will handle the same virtualserver without ingressClassName, is this by design? This is really weird.

  2. In my case, some of the vs configurations depend on third-party NGINX plugins that are not included in the default ingress, which will cause an issue for the global ingress. I couldn't find a better way than adding a default value to the virtualserver CRD. Do you have any suggestions?

Thanks again for your attention and patience!

@hanyouqing
Copy link
Contributor Author

One more thing I observed below

When I added the default: nginx to the virutalserver CRD.

If a virtualserver with a non-existent ingressClassName was created, it will be handled by the default ingress without warning and invalid info.

Is this the expected behavior?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal An issue that proposes a feature request
Projects
Status: Todo ☑
Development

Successfully merging a pull request may close this issue.

2 participants