Allow Ingress Url Path based routing

[mattalberts]

The ingress controller does not support url based routing (the IngressPath attribute Path)

spec:
  rules:
  - host: echo.mydomain.com
    http:
      paths:
      - backend:
      - path: any_path_is_treated_as_slash
          serviceName: echo
          servicePort: http

[mattalberts]

This is the remainder of the issue reported by #10

[easel]

As an aside, it appears as if the presence of any path statement (in v0.6.0) prevents the tunnel from getting provisioned properly.

[easel]

Confirmed. To reproduce, just follow the instructions from https://developers.cloudflare.com/argo-tunnel/reference/kubernetes/ but replace this:

  - host: echo.mydomain.com
    http:
      paths:
      - backend:
          serviceName: echo
          servicePort: http

with

  - host: echo.mydomain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: echo
          servicePort: http

The host will never be added in Cloudflare. Scrub out the path: / and re-apply and it pops up.

[mattalberts]

That’s correct, path based routing isn’t supported. Rather that ignoring the path and establishing a tunnel base on host:port, in the 0.6.x line I decided to explicitly error on t tunnel creation. You’ll see a corresponding error log stating that path based routing is not supported .... that said I should have eased that restriction to empty string and “/“, .... I’ll update

…

Sent from my iPhone

On Dec 7, 2018, at 7:47 PM, Erik LaBianca ***@***.***> wrote: Confirmed. To reproduce, just follow the instructions from https://developers.cloudflare.com/argo-tunnel/reference/kubernetes/ but replace this: - host: echo.mydomain.com http: paths: - backend: serviceName: echo servicePort: http with - host: echo.mydomain.com http: paths: - path: / backend: serviceName: echo servicePort: http The host will never be added in Cloudflare. Scrub out the path: / and re-apply and it pops up. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[easel]

@mattalberts that would help, I ran into two helm charts back to back that wouldn't quite work with Cloudflare since it wasn't allowing path: "/". Thanks!

[nathanwaters]

If the current version supports multiple rules (not paths), how do you add multiple tls hostnames?

This doesn't work (Cloudflare DNS backend doesn't add the CNAME's).

*Edit: solved lol, the trick oddly is to have named servicePorts rather than port numbers.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: argo-tunnel
  labels:
    ingress: argo-tunnel
  name: ingress-argo
spec:
  tls:
  - hosts:
    - one.example.com
    secretName: example.com
  - hosts:
    - two.example.com
    secretName: example.com    
  rules:
  - host: one.example.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: servicePort1
  - host: two.example.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: servicePort2

[tanner-bruce]

Are there plans to support this? This is a blocker for us at the moment

[mattalberts]

@tanner-bruce Your best option to get both the behavior you need, is use cloudflared as a side-car to a proxy that supports path based routing.

For example:

• ingress-nginx (nginx) + cloudflared as a sidecar
• contour (envoy) + cloudflared as a sidecar

In these examples, you would stand up a vanilla ingress controller to watch Ingress resources, setting up path based routes. The cloudflared sidecar (a container that references the ingress controller on local host), bridges the ingress controller to argo-tunnels.

If you don't need the level of dynamic reconfiguration provided by the ingress controller, you can reduce the solution to either nginx or envoy as the proxy and cloudflared as a sidecar to setup tunnels.

[alahijani]

@mattalberts
This sounds very interesting. Is there an example with yaml files that demonstrates how to do that?

[tanner-bruce]

Thanks @mattalberts, that is what we discussed doing after finding this issue. Thanks for confirming, we'll give that a shot.

[bmcustodio]

@mattalberts do you have an idea of what it would take to implement this? Does this happen because of the underlying technology or just because it hasn't been implemented yet?

[HofmannZ]

@mattalberts Anyone currently working on this?

[acrogenesis]

@HofmannZ #172 (comment)