-
Notifications
You must be signed in to change notification settings - Fork 269
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
Server entry created for root path even if not specified in ingress #157
Comments
Hi, this is how this ingress controller was designed - first match the hostname, and finding it match the /path. Following this design the load balancer need to include a behavior when the path isn't found, even the root path. The problem here is that your wildcard hostname has more priority than the concrete one. A fix to this behavior was made on #149 and was just deployed in the current snapshot version. The changelog has the known breaking changes between v0.4 and this tag. |
The other problem we have is that we may need to have two ingress with the same host element but defined a different sets of paths. In this case we observed two things that are problematic.
We observed that some time a catch all rule is attached. For example ingresses like these
and
Produce something like
The first like with catch all I believe shouldn't be there.
In this case I believe is by design, if you have two ingress you have one entry in the frontend for each one as @jsrolon explained but if both ingress have the same dns the routing will always be sent to the first rule |
The other problem we have is that we may need to have two ingress with the same host element but defined a different sets of paths. In this case we observed two things that are problematic. HTTP request,We observed that some time a catch all rule is attached. For example ingresses like these
Produce something like
The first like with catch all I believe shouldn't be there. HTTPS requestIn this case I believe is by design, if you have two ingress you have one entry in the frontend for each one as @jsrolon explained but if both ingress have the same dns the routing will always be sent to the first rule |
Hi, we have a fixed issue here: hosts order wasn't wrong. This was fixed in the current snapshot tag and should fix the behavior you pointed out above. We have also another issue: this controller was designed in such a way a host matches before, and after that a location matches. If a location doesn't match after a host being matched we send the request to the default backend. This is how standard webservers like apache and nginx work, I'm aware HAProxy doesn't need to follow this convention but there isn't a fast, clean and safe way to change this at this moment. I'll have a look into this in a future version. |
Hi, added |
We currently have an ingress resource that has a hostname with a wildcard,
*.example.com
. In this ingress, we specify 4 endpoints only, none of them which is root (/
). However, when we check the resulting haproxy config file, there is a server entry for this backend, for path/
, that directs to the default backend.The issue is that we define another ingress resource with a hostname like
concrete.example.com
and a root path, and we can never reach it because the wildcard resource takes precedence. Is there a way we can alter the order of the rendering of the server entries? Why is a default root server entry created for an ingress when we don't specify it in the ingress?We have seen this behavior in v0.4.
The text was updated successfully, but these errors were encountered: