Routing with Nginx Ingress

Issue Type:

• Bug report
• Feature request

What happened: This is not a bug or feature request. It’s purely a question and my lack of understanding on how to get linkerd to route correctly. I have an application that has a API path of /app1/api/v1/lookup/12345 which then looks up the value 12345 and returns a result. This will be just one of the microservices running under the same hostname https://services.example.com. So ultimately, my request URL looks like this https://services.example.com/app1/api/v1/lookup/12345. If I create an nginx ingress resource as https://services.example.com to svc/l5d on port 4140, when I try to request /app1/api/v1/lookup/12345 I get the following output.

No hosts are available for /svc/services.example.com, Dtab.base=[/srv=>/#/io.l5d.k8s/default/http;/host=>/srv;/svc=>/host;/host/world=>/srv/world-v1], Dtab.local=[]. Remote Info: Not Available

So it appears that linkerd service does not know it is bound to the hostname via ingress and tries to route to a svc with that name and fails.

I tried adding a value in the dtab to route /services.example.com => /svc but that doesn’t seem to work and yields the same error.

What you expected to happen: I’d like to linkerd to route incoming requests through ingress controller to my services.

How to reproduce it (as minimally and precisely as possible): As described above.

Anything else we need to know?:

Environment:

• linkerd/namerd version, config files: 1.3.6
• Platform, version, and config files (Kubernetes, DC/OS, etc): 1.9.3
• Cloud provider or hardware configuration: vSphere

[hawkw]

@eroji you’ll need to configure your application to use Linkerd as a proxy. Many (but not all) applications and frameworks support a http_proxy environment variable; otherwise, they’ll likely have their own method of configuring a HTTP proxy. See https://linkerd.io/getting-started/k8s/#configure-your-application for more information.

You might also be interested to note that, unlike Linkerd, the Conduit service mesh can be transparently injected into Kubernetes pods without requiring you to set it as a proxy; it will set iptables rules so that all outgoing requests are routed through Conduit automagically. However, it doesn’t currently support the kind of policy-based routing we discussed above, but this is on the roadmap.

[eroji]

Thank you. I think this answers all my questions.