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

Server entry created for root path even if not specified in ingress #157

Closed
jsrolon opened this issue May 14, 2018 · 5 comments
Closed

Server entry created for root path even if not specified in ingress #157

jsrolon opened this issue May 14, 2018 · 5 comments
Milestone

Comments

@jsrolon
Copy link

jsrolon commented May 14, 2018

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.

@jcmoraisjr
Copy link
Owner

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.

@lumeche
Copy link

lumeche commented May 16, 2018

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

  rules:
  - host: '*.midomainnet'
    http:
      paths:
      - backend:
          serviceName: gateway
          servicePort: 18911
        path: /A/
      - backend:
          serviceName: gateway
          servicePort: 18911
        path: /B/

and

rules:
  - host: ABC.mydomain.net
    http:
      paths:
      - backend:
          serviceName: othergateway
          servicePort: 9999
        path: /
  tls:

Produce something like

    use_backend ntg6-m5-0-ci-core-gateway-18911 if ishost-_.mydomain.net { path_beg /A/ }
    use_backend ntg6-m5-0-ci-core-gateway-18911 if ishost-_.mydomain.net { path_beg /B/ }
    use_backend upstream-default-backend if ishost-_.dev.nuancemobility.net { path_beg / }
    use_backend ntg6-m5-0-ci-core-othergateway-9999 if ishost-ntg6-m5-0-ci-core.dev.nuancemobility.net { path_beg / }
    default_backend upstream-default-backend

The first like with catch all I believe shouldn't be there.

#HTTPS request

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

@lumeche
Copy link

lumeche commented May 16, 2018

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

  rules:
  - host: '*.midomainnet'
    http:
      paths:
      - backend:
          serviceName: gateway
          servicePort: 18911
        path: /A/
      - backend:
          serviceName: gateway
          servicePort: 18911
        path: /B/
   
rules:
  - host: ABC.mydomain.net
    http:
      paths:
      - backend:
          serviceName: othergateway
          servicePort: 9999
        path: /
  tls:

Produce something like

    use_backend ntg6-m5-0-ci-core-gateway-18911 if ishost-_.mydomain.net { path_beg /A/ }
    use_backend ntg6-m5-0-ci-core-gateway-18911 if ishost-_.mydomain.net { path_beg /B/ }
    use_backend upstream-default-backend if ishost-_.dev.nuancemobility.net { path_beg / }
    use_backend ntg6-m5-0-ci-core-othergateway-9999 if ishost-ntg6-m5-0-ci-core.dev.nuancemobility.net { path_beg / }
    default_backend upstream-default-backend

The first like with catch all I believe shouldn't be there.

HTTPS request

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

@jcmoraisjr
Copy link
Owner

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.

@jcmoraisjr
Copy link
Owner

Hi, added strict-host configmap option in the current snapshot tag. Define as "false" if you want to try a wildcard match before moving to the default backend. Closing, just update this issue if you have any problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants