Knative services URLs

Knative uses subdomains rather than URL paths because the underlying container could handle many different URLs, and might encode requests with absolute URLs (which might point to a different function depending on deployment) or relative URLs (which would point within the current application).

If you want to map multiple Knative services under a single domain name, you can use an Ingress implementation or API server like Kong, Istio, or many others. You will need an HTTP router which can rewrite the Host header to point to the Knative Service's hostname in question; the default Kubernetes Ingress resource doesn't expose this capability.

If you choose to set this up, you'll also need to decide on a policy for mapping the URL paths: you could either strip the URL paths off when passing them to the Knative Service, or leave them present. It probably makes more sense to strip the URL paths off, since otherwise you'll end up needing to have a dependency between your application code and the namespace and name that you have chosen to deploy it at.

Other gotchas to watch out for:

• Since all the Knative Services are behind a single hostname, they'll share the same cookie domain, and could inadvertently stomp or poison each others cookies.
• Absolute vs relative URL references, as I mentioned above. It's likely that your HTTP router doesn't have the ability to re-add the stripped URL prefix on outbound paths; doubly so if you have URLs which are being constructed in HTML or Javascript, rather than simply in URL headers.
• Automatically programming your HTTP router as new Services are created is not automated -- you'd need to do this yourself. You could also write a Knative Service to do this routing and use a DomainMapping to map that one Knative Service to your desired domain name. The Knative Service could then automatically do the URL rewriting, and you could do the reverse rewriting on the outbound if you wanted.