Expanding KIngress Visibility Setting

[andrew-su]

/area networking

In the current design of Knative routing, traffic enters the cluster through a public Load Balancer that perform traffic splitting to public KServices. Traffic within the cluster needs to go through a private LoadBalancer to perform traffic splitting to private KServices.

While the meaning of cluster-internal traffic is relatively clear, the meaning of ‘external traffic’ has much less clarity. So far in Knative we have equated that to traffic coming from the Internet. While that has been sufficient for some users, there are users who want to choose to expose the public KServices to different external LoadBalancer visible to completely different external networks.

[andrew-su]

Proposal

[andrew-su]

/cc @tcnghia
/cc @shashwathi

[ilackarms]

Similar to istio, Gloo has a Gateway CRD which is used to configure bind addresses, TLS configuration, and other options. In the case of Istio, the requirements and assumptions on the Gateway layer (as well as other control plane configuration such as corev1/service for the proxy instances).

Knative makes a few assumptions about this layer which are not well-documented. It would be helpful if part of this effort included some guidance for kingress implementers on what is expected from the gateway layer (i.e how to set up the proxies for the user).

[ilackarms]

Something I'll add about the current implementation: outside of Knative, Gloo does not assume/hard-code references to specific proxies. Because of the assumption of the existence of an external/internal gateway in knative (reflected by the visibility setting on the Kingress CRD), Gloo is implement this assumption, though it limits the possible reference architectures for a Gloo-knative setup.

Consider a case where a each namespace in a cluster has its own internal gateway (we have seen this in a multi-tenant scenario). It would be useful if the knative visibility setting allowed selection of proxy instances by some mechanism. Perhaps selecting proxy pods or services by their labels?

Thanks to @tcnghia for tagging me on this

[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

[andrew-su]

/remove-lifecycle stale

[tcnghia]

Progress is tracked here https://github.com/knative/serving/projects/43

[mattmoor]

@tcnghia should we track this in networking? We can transfer issues there 😎

[github-actions]

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.