Eventing: RFC: Supporting Multi-tenant receive adapters

Created on 27 May 2020 · 12Comments · Source: knative/eventing

Let's discuss about multi-tenant receive adapters!

Problem Statement

Single-tenant receive adapters handle only one source (CO) at a time, i.e. there is a one-to-one mapping between receive adapter and source specification. While this architecture works well for high volume, always "on" event sources, it is not optimal (i.e. waste precious resources, cpu and memory) for sources producing "fewer" events, such as PingSource, APIServerSource and GitHubSource.

Proposed Solution

Add support for multi-tenant receive adapters capable of handling more than one source.

I feel that there is a general agreement on the need to support both architectures. If you think otherwise, please add a comment below.

Assuming we (as a community) decide to support both single-tenant and multi-tenant receive adapters, here some of the questions that need to be answered:

What sources would benefit most from being multi-tenant?
Do we want both single-tenant and multi-tenant receive adapters to coexist? If yes what is the UX?
How do we make multi-tenant receive adapters secure and scalable?
Where do we put the multi-tenant code? Along side with the single-tenant code or in a separate repo?
??

Let's discuss. @grantr @n3wscott @nachocano @vaikas @matzew @antoineco @sebgoa @davyodom @akashrv @duglin

Exit Criteria
a document recording any decisions made here.

Related PR/issues

areapi aresources areux-decision

Source

lionelvillard

🚀1

All 12 comments

I think it makes a lot of sense, kudos for suggesting this 👍

A few challenges I can envision:

for sources with a pull model, we will eventually have a single component that binds to multiple credentials. It can be difficult to ensure that "tenant1" doesn't reference a secret belonging to "tenant2" by abusing a flaw of a multi-tenant source. We did this by optionally enforcing namespace isolation in the NGINX ingress controller (1 igc per namespace and no secret caching outside of the namespace's boundaries).
for sources with a push model, we need to map individual URL paths to their source instance, and there is a world of auth methods we may have to support.

antoineco on 27 May 2020

For push based, at a first glance at least, seems fairly similar to what the Broker is already doing routing the events based off of a triggers/XXX/yyy. We should try to leverage work there as well as not duplicate this and hoist the common bits into something reusable.

vaikas on 27 May 2020

I feel that there is a general agreement on the need to support both architectures.

Agree, i see how the single receive adapter model it's a waste of resources for "webhook/notifications" like events from external systems like GH. On the other side of the spectrum, I think it works pretty well with queue event sources like kafka, aws sqs and so on.

What I wish to understand is: what is the line between

the resource efficiency of the MT receive adapter model
the scalability of the single receive adapter model

Where do we put the multi-tenant code? Along side with the single-tenant code or in a separate repo?

It would be awesome if they share most of the code, but maybe this won't be always possible

slinkydeveloper on 28 May 2020

👍1

@antoineco

We did this by ...

Are you saying you have mt source adapters?

For push-based, this seems to be a recurring pattern, for the broker and also for the MT Github adapter (https://github.com/knative/eventing-contrib/pull/1148)

lionelvillard on 28 May 2020

No, I'm just saying we had a similar problem with multi-tenancy and secrets.

antoineco on 28 May 2020

👍1

I have one question - I could imagine how the single-tenancy is fine enough for kafkasource right now but wouldn't the single kafkasource deployment for one serverless app an overhead here too, while comparing it to a single kafkasource deployment (for a namespace or the cluster) for all the serverless apps?
For example, I have 3 apps that I am deploying through knative and for them to get requests from kafka I'd need to deploy 3 kafkasource deployments - one service as a sink in each kafkasource. I am wondering now, whats the point of my apps scaling down to 0 if there are additional 3 controllers taking CPU and memory which I wanted to reduce from the starting?

please tell me if my understanding of this is wrong
if I understood this correctly: I know that this architecture could be massively helpful for apps that require considerable amount of cpu and memory, but what if my apps have just some small housekeeping code taking up minimal cpu and memory, would this architecture be justified there too?
I am still unaware of the implementation details, whether its even possible to do this or not. But, anyway I'd like to know how can I justify this architecture for small apps.

Shashankft9 on 12 Jun 2020

We talked about this during last week source WG meeting. Here the main points:

Move to namespaced-mt, option to have a cluster scoped Mt in the future
Anti-pattern to have 1:1 adapter to resource.

On the first point, what about reversing the statement: Move to cluster scoped-mt, option to have a namespace-scoped Mt in the near future, to be consistent with the rest of Knative.

We discussed to initially add this option in a ConfigMap and later on maybe provide an annotation on the namespace or CR. First we need to collect use cases.

@n3wscott @vaikas @nachocano Does that sound good to you? Did I miss something?

lionelvillard on 16 Jun 2020

👍1

@Shashankft9 you got this right. Thanks a lot for you feedback!

lionelvillard on 16 Jun 2020

We talked about this during last week source WG meeting. Here the main points:

Move to namespaced-mt, option to have a cluster scoped Mt in the future

Anti-pattern to have 1:1 adapter to resource.

On the first point, what about reversing the statement: Move to cluster scoped-mt, option to have a namespace-scoped Mt in the near future, to be consistent with the rest of Knative.

We discussed to initially add this option in a ConfigMap and later on maybe provide an annotation on the namespace or CR. First we need to collect use cases.

@n3wscott @vaikas @nachocano Does that sound good to you? Did I miss something?

SGTM. I'll create a tracking issue in knative-gcp as well because we are interested in this for our Google sources. Hope to be able to work on this sometime soon.