Remove Istio as a dependency

[mattmoor]

I believe that Channel's usage of a Kubernetes VirtualService could just be a Kubernetes Ingress resource (possibly implemented by Istio, possible not).

I'm talking about here:

eventing/pkg/controller/channel/controller.go

Line 511 in 904f403

func newVirtualService(channel *channelsv1alpha1.Channel) *istiov1alpha3.VirtualService {

[evankanderson]

+1 Is there any particular reason to require a `VirtualService` in the control? It would be nice if the implementation could potentially use a `VirtualService` to collect tracing information at the appropriate points, but hopefully that could be done transparently by the Istio injection, rather than explicitly in our controller.

…

On Mon, Jul 30, 2018 at 7:06 AM Matt Moore ***@***.***> wrote: I believe that Channel's usage of a Kubernetes VirtualService could just be a Kubernetes Ingress resource (possibly implemented by Istio, possible not). I'm talking about here: https://github.com/knative/eventing/blob/904f40365958491641f1326da4bbaf52a329c457/pkg/controller/channel/controller.go#L511 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#294>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlyN9VKunz_Dpf6Ol6YZKrzAiFasMtnks5uLxLxgaJpZM4Vmei1> .

-- Evan Anderson <argent@google.com>

[scothis]

The VirtualService is used to forward traffic for a specific Channel to the Bus. It also sets the HTTP Host header with a canonical value that the bus uses to know which channel the incoming request is for.

All of this traffic is originating from inside the cluster and generally should not be exposed outside of the cluster. Although there may be cases where we would want a channel to opt-in to being exposed externally.

[scothis]

Note: in this context, service is always a k8s service and not a knative serving service.

There are two key attributes of the current behavior that are worth trying to preserve:

1. an event can be sent to a Channel by making a request to the Service for that Channel
2. the Bus can receive requests for multiple channels and distinguish the channel from the event

We can remove the VirtualService (and the Istio requirement for eventing) if we:

1. rename the Channel's Service to make it unique within the cluster. Updating .status.domainInternal with the new name
2. apply the label selector from the Bus's Service to each Channel's Service for that Bus
3. remove the Service created for the Bus
4. create a lookup in the bus monitor from the Channel's Service name (or domain internal name) to the Channel resource
5. resolve the Channel resource by its Service name rather than the Channel's name from the request's Host header.

By making each Channel's Service name unique in the cluster, we can continue to support either short DNS name or fully qualified names as the host. Strictly speaking, only a ClusterBus could have a name collision between namespaces.

If Istio is installed on the cluster, the Bus/Channels can still benefit from it's capabilities, we are simply not requiring Istio in order to use a Bus.

/assign @scothis

[evankanderson]

Question re: item 1 in your changes. Isn't the Channel's Service already unique within the cluster? Or are you concerned about receiving a Host header with only the namespace-local name and not being able to resolve it uniquely across the entire cluster? How does VirtualService help with this (if at all)?

I haven't experimented with it, but it's possible that the destination IP can be used to distinguish between different services pointed at the same set of labels. (I might get a chance to try this out tomorrow.)

[scothis]

Isn't the Channel's Service already unique within the cluster?

Channel's are unique within a namespace, and the service is currently derived from the channel's name, so collisions between namespaces is possible.

Or are you concerned about receiving a Host header with only the namespace-local name and not being able to resolve it uniquely across the entire cluster?

This is the concern I'm attempting to resolve

How does VirtualService help with this (if at all)?

We use the VirtualService today to rewrite the Host header with a canonical name for the Channel, regardless how the service is invoked. (my-channel vs my-channel.default vs my-channel.default.svc.cluster.local vs an ip)

I haven't experimented with it, but it's possible that the destination IP can be used to distinguish between different services pointed at the same set of labels. (I might get a chance to try this out tomorrow.)

I would expect the destination IP to be the bus dispatcher pod that is receiving the traffic. I'm curious as to what you find.

[lindydonna]

/kind feature-request

[Harwayne]

To be clear about this feature request. Which of the following are we trying to do?

1. Be able to run with istio-lean, i.e. run without sidecars on every Pod, but still require Istio to be installed.
2. Be able to run without Istio at all.

My reading of the issue thus far is that it wants to be able to remove Istio in its entirety. Is that correct?

[akashrv]

/assign