Cluster-wide, opt-in path-based routing (single shared host)

[johnbuluba]

/area networking
/area API
/kind feature

Describe the feature

We'd like an opt-in, cluster-wide path-based routing mode for Knative
Serving. When an operator turns it on, every external-visibility Knative Service
becomes reachable at a single shared host under a templated path, e.g.:

https://apps.example.com/<namespace>/<name>/...

instead of its own external hostname (<name>.<ns>.<domain>). It's set once by
the operator and applies cluster-wide — no per-service or per-route config.
Cluster-local addressing is unchanged, and requests still land on the same
backend; only the external URL scheme changes.

We're actively prototyping this to test feasibility and want to drive it to
something landable — but we're opening this to get direction before committing
to a design (see "Approach" below).

Motivation

Today every ksvc gets its own external hostname, which assumes wildcard DNS and
per-host certs. Platforms hosting many small ksvcs behind a single ingress +
single cert currently fall back to net-istio-specific workarounds — a per-ksvc
VirtualService, a hand-maintained shared VirtualService, or a Lua
EnvoyFilter deriving the upstream authority from the first path segment. All
three live outside the Knative API and none keeps Route status in sync with how
the ksvc is actually reachable.

We'd like path-based addressing to be a first-class, ingress-implementation-
agnostic option driven by Knative itself.

How this differs from prior requests

This is not the per-route Dispatcher/path-map model from #11997 (where a
developer authors /search → svc-a, /login → svc-b). That model needs a new
CRD, ClusterDomainClaim collision handling, and the cross-namespace question
flagged as intentionally unsupported in KIngress.

Ours is the narrower, complementary case: swap the cluster's external
addressing scheme from per-host to per-path, set once by the operator. The two
could coexist.

Related: #11997 (per-route composition, open), #12588 (closed as question),
#15729 (Gateway API direction), #540 (original header/URI routing ask).

Approach (open — seeking direction)

We're keeping the implementation deliberately vague at this stage; the repo
where we're prototyping is a feasibility test and we expect to fine-tune later.
Our hope is this can be done without new CRDs or Route/Service API changes by
leaning on the path + host-rewrite semantics the ingress contract already
carries, but we haven't settled on the right mechanism and would value the WG's
steer on:

• where the switch + its parameters should live (feature flag + network config,
  a small new resource, …),
• how Route/Service .status.URL should reflect the path-based URL,
• how it should relate to the Gateway API direction (Proposal: Replace Heavyweight Network Layer with Kubernetes Gateway API for Path-Based Routing and Lightweight Deployment #15729) so it stays
  net-impl-agnostic and slots under a future HTTPRoute backend,
• known constraints to design around up front: cross-namespace exposure,
  shared-host TLS, and traffic tags.

Commitment

We're prototyping this now and intend to take it to completion — write up a
proposal, bring it to a Serving WG call, and do the implementation + any net-*
follow-ups. Looking for a thumbs-up on direction and guidance on the right shape
before we lock a design.

[dprotaso]

I can't think of this change being something simple.

First there's the case of having multiple top level domains and how do services attach to that. We could copy the model where an admin creates a cluster level resource and opts namespaces into allowing attaching service to it.

Secondly we generate a bunch of networking resources with the host name only since we have an assumption there isn't a conflict in the same namespace. This would require changing that logic across various net-* repositories.

Third, we detect that network traffic has rolled out properly by probing and we do that using host names. We'd have to include path here.

Then you have autoTLS etc.

I don't think there are easy answers to this and we probably should write out what you're thinking about.

We have a process for feature tracks outlined here:
https://github.com/knative/community/blob/main/mechanics/FEATURE-TRACKS.md

[johnbuluba]

@dprotaso Thanks! Capturing the constraints before committing to a design is what we
opened the issue for. Recording your points as we read them:

• Multiple top level domains and how services attach, possibly via an admin
  authored cluster level resource that namespaces opt into.
• Networking resources are generated using only the host name, on the
  assumption that there is no conflict within a namespace. That logic would
  need to change across the net-* repositories.
• Status probing identifies routes by host name and would need to include
  the path.
• autoTLS interaction.

If there are other concerns you would want us to fold in, please share them.
We will work through these and come back via the Feature Tracks process when
we have something coherent.

[dprotaso]

Networking resources are generated using only the host name, on the
assumption that there is no conflict within a namespace. That logic would
need to change across the net-* repositories.

Changing that logic would break existing deployments on upgrade - again I don't think this is straight forward