[WIP] In-memory Channels without Istio sidecar

[adamharwayne]

Proposed Changes

• Expose in-memory channels by letting them be reached through the exposed Knative Ingress Gateway.
• in-memory Channels can be used by pods without an Istio sidecar.

Release Note

in-memory Channels are exposed via a cluster-wide Ingress Gateway.

[vaikas]

/lgtm

leaving for @scothis to approve since he had questions.

[knative-prow-robot]

New changes are detected. LGTM label has been removed.

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: adamharwayne
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: vaikas-google

If they are not already assigned, you can assign the PR to them by writing /assign @vaikas-google in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[scothis]

Can we setup a new, internal Gateway before this is merged rather than using serving's public gateway? Besides the security benefits, I'm not sure it's worth introducing a hard dependency on serving's runtime.

[n3wscott]

It's generally not a good thing for channels to be exposed via Ingress. Do you have thoughts on how to prevent external access to channels with this model?

This is true and we have the thought that it is a future problem that is easy to solve later.

[adamharwayne]

/cc @tcnghia
Thanks @tcnghia for help understanding Istio.

I've tested this and it seems to work correctly, but I am hesitant to copy the entirety of 202-gateway.yaml, which this currently does. Unless people really want this soon, I'll let this sit in WIP until I find a better solution or find there isn't one.

[bbrowning]

Coming back to this - we now have a cluster-local gateway that would allow us to expose in-memory channels to the cluster without also exposing them to the internet. So perhaps worth an update and getting this in?

[Harwayne]

Coming back to this - we now have a cluster-local gateway that would allow us to expose in-memory channels to the cluster without also exposing them to the internet. So perhaps worth an update and getting this in?

I talked with @tcnghia about how Serving is doing, and it sounds like Istio is (or soon will be) optional over there. Right now Eventing depends on the VirtualService routing properties of Istio and I haven't investigated to find out if other solutions have the same capability.

This PR is about being able to use Istio lean, which should be easily doable if we have a cluster-local Gateway. Which one can we use?

[evankanderson]

The current cluster-local rules in Serving rely on the mesh mode to provide the service only within "the cluster" (actually, within the mesh).

[tcnghia]

@evankanderson @adamharwayne we offer a setting in config-istio to configure what we will use for local gateway. The default when nothing is specified is mesh, but user could point to something like this one that we also include in istio.yaml and istio-lean.yaml https://github.com/knative/serving/blob/master/third_party/istio-1.0.6/download-istio.sh#L13

[matzew]

@Harwayne I think this is obsolete w/ the other istio removal work ?

[Harwayne]

This is no longer needed. #1044 removed the Istio requirements for in-memory Channels.

[Harwayne]

/close

[knative-prow-robot]

@Harwayne: Closed this PR.

Details

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.