4

Is there an order to Ingress rule specification i.e. will the first qualifying rule be honored?

The intention of following spec is to route all requests that do not have headers Host: foo.com and Host: bar.com and route them to service3. I am not sure if the spec is syntactically correct and more so, if it will serve the desired purpose?

spec:
  rules:
  - host: foo.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: http
        path: /
  - host: bar.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: http
        path: /a/b/c
  - http:
      paths:
        - path: /a/b/c
          backend:
              serviceName: service3
              servicePort: http

Don't think it matters, but I am using the Contour Ingress controller.

siberiancrane
  • 586
  • 1
  • 6
  • 20

2 Answers2

0

I am not familar with Contour, I just quickly browse the doc.

How Contour works with Ingress rule is not clear from its document. I think Contour perfer using its CRD IngressRoute to specify how request rule works.

So I infer your Ingress behavior from offical kubernetes ingress rule:

  • Request with host: foo.com will route to service1 or service3
  • Request with host: bar.com will route to service2 or service3
  • Other request will route to service3
menya
  • 1,459
  • 7
  • 8
  • Thanks for replying. But the access logs continue to give _404 NR_ (implying no route could be found), for a subset of requests, which should have hit service3. I don't think there's an issue with service3, because it doesn't work even with service1. – siberiancrane Jul 04 '19 at 09:56
  • Can you try `IngressRoute`? – menya Jul 04 '19 at 11:34
  • Didn't help. The only other noticeable thing is that the request contains `X-Forwarded-Port: 443` and `X-Forwarded-Proto: https` and I wonder if that's causing issues. – siberiancrane Jul 04 '19 at 20:13
  • Do you config your Contour `Service` with https port? If not, probably your cluster is behind a LoadBalance. – menya Jul 05 '19 at 05:12
0

What you have created in syntactically correct and should route http://*/a/b/c and http://*/a/b/c/* to service3 in most ingress controllers.

An Ingress definition is just data that is supplied to an ingress controller though. The implementation of converting that data into config is ingress controller specific.

Code

Contours route config looks to be rooted by a "virtualhost" name. In the route.go code I can't see any handling of the "no virtualhost" case.

From the route.go tests it looks like a virtualhost of * is how the default host is handled.

This sorting of virtualhosts would hopefully always put * in the right place for contour to default as you describe but then I think there is also an interface for this config to be applied to envoy, the actual proxy process.

So it would appear (without testing) that no matter what order you put the Ingress definition in, contour will sort out the default host routes for you as '*'

This kind of makes sense when you consider contour also supports a custom resource definition of IngressRoute which only allows one virtualhost per definition. These CRDs as a group have no specific ordering so the sort is required.

Matt
  • 68,711
  • 7
  • 155
  • 158