Serving: Allow for a per Service URL to be specified

[duglin]

In what area(s)?

/area API
/area networking

/kind spec
/kind proposal

Describe the feature

It would be nice if there was a way to allow for a KnService to specify it's URL, rather than to have the system pick it via the domainTemplate config option (or the default value of name.ns.domain).

I think this is related to the notion of Revisions being allow to have a per-revision Name (and thus a per-revision URL) but if I'm correct, that allowed only for the "name" portion of the URL to be specified and not the entire URL. This issue isn't about extending this feature to that level, but it might be something to consider during this issue's design so that if we did want to extend this in the future the UX for both were consistent.

I couldn't find an issue covering this directly, but I know it has come up in chats so I thought I'd open it to force a discussion.... if it's a dup let me know and I'll close it.

[mattmoor]

I think we want the system-generated names here to be boring, which parallels the DNS for K8s services.

These boring names can then have 0-N interesting names associated with them on a separate lifecycle.

In Cloud Run we have a DomainMapping resource that effectively does this by creating an Istio VirtualService that rewrites the request to a vanity domain to the backing Route. We can certainly discuss it, but it has a few warts that I'd like to see addressed before we discuss upstreaming some form of it.

[markusthoemmes]

Is this a duplicate of https://github.com/knative/serving/issues/1185?

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[duglin]

/remove-lifecycle stale

@markusthoemmes I don't know if it's a duplicate of #1185 because I'm not sure what that one is asking for. The title sounds like it might be, but the description is kind of vague and the author never clarified based on Evan's question

[duglin]

Related to: https://github.com/knative/eventing/issues/2718

In KnEventing there's a push to optionally allow the eventing infrastructure to be moved out of the user's NS and into some other namespace - typically an eventing one. This might be done because of the desire to multi-tenant enable those components or to simply hide those components from the user because they are viewed as "infrastructure" that the user should not need to see, manage directly, or even know about.

An interesting example of this is the Github Event Source. When the user creates a CR for it, the Github controller will create a KnService to act as the receiver of the events generated by the Github webhook. Moving this KnService out of the user's namespace should be do-able, however, the URL associated with that KnService will now not be related to the user's original namespace. In particular, it might have an eventing namespace in the URL instead. This is problematic for environments where for DNS routing, auth or other purposes that KnService needs to be associated with the user's namespace.

There may be a way to solve this strictly within the Eventing space by having the Github controller create additional resources in the system to map a specialized URL with the original user's NS in it to the KnService. However, based on some off-line chats it seems like there is growing desire for people to have the ability to create "vanity" URLs for a variety of reasons so it might be better to solve this once in KnServing, and then KnEventing/Github could leverage that solution.

Some usecases I've heard:

• it would be nice if people could specify a domainTemplate on a per Revision basis
• it would be nice if there was a way to create an externally available URL for other components in the system, such as Brokers
• it would be nice if people could specify multiple URLs (instead of just one) for a resource

/cc @julz @lionelvillard @mattmoor

[thiagosantosleite]

Any plans for support multiple and custom domains for the same ksvc?

[ZhiminXiang]

@thiagosantosleite Yes. I think with @julz 's work for DomainMapping, multiple and custom domains will be supported.

[vagababov]

/assign @julz
Is this done with the URL work you did?

[julz]

we did some low-level work for this in KIngress, but the high-level user facing stuff still needs doing.

I have an early proposal draft for it here: https://docs.google.com/document/d/1yXSuKpQqZM5tczBFpPG8TGQoWSkvmoA17nPwDd1UxEI/edit# that I'm hoping to get in to a state to talk through at API WG (but it's not really ready yet, just thoughts on a page right now). I'll try to get it done by next week's meeting.

[mattmoor]

With the ability to compose kingress, I'm super excited about the possibilities for both this and other API-gateway-like capabilities we can build on top of the host/header/path-based routing capabilities we have in kingress 🤩

I think another thread of discussion is talking to Eventing Delivery about implementing the networking dataplane contract so that it can be fronted by kingress, which will be suuuuuper cool. 🤓

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[duglin]

/remove-lifecycle stale