Multiple Knative Eventing control planes

[aliok]

Problem
We see an interest in users who want to have complete isolation in their Knative Eventing setups.

We already have components that support isolated dataplanes. These components create dataplanes in the user namespace and this allows having multiple dataplanes that are completely isolated.

However, there are use cases where the control plane also needs to be isolated, such as it shouldn't have access to all of the cluster.

We believe kcp is the way to go to address this problem.

Expected outcome is:

• Having multiple Knative Eventing control planes working without any conflict
• Having different versions of Knative Eventing in a cluster

In Knative Serving, there were similar discussions before and some of the use cases had to be left unaddressed because of a lack of a tool like KCP. While it seems it is possible to make Knative Eventing control plane to only reconcile specific namespaces, multiple CRD versions and multiple webhooks are making the matter complicated.

Related Serving issues:

• Consider allowing serving controllers to be run for a single namespace serving#2107: making Serving control plane operate on a given namespace only
• Multi-Tenant Control Plane serving#4959: multiple Serving control planes on a cluster

Persona:
Developer

Exit Criteria
A measurable (binary) test that would indicate that the problem has been resolved.

Time Estimate (optional):
How many developer-days do you think this may take to resolve?

Additional context (optional)
Add any other context about the feature request here.

[aliok]

This issue is mentioned in GSoC 23 ideas list: knative/community#1209

[AmanSarraf]

Hi @aliok , I am interested in learning about this project and want to work on this project under gsoc. I have contributed to knative before, also worked as intern at (Triggermesh).
Please let me know about the resources to get started.

[aliok]

@AmanSarraf thanks for your interest in this project idea.

This is a research project about trying to make Knative Eventing control plane running with kcp.

The idea is that we will learn more about the changes required in Knative Eventing to have multiple control planes. Then, if time is allowed, make those changes. As this is not really tried, we cannot estimate what kind of problems are there and if they can be solved. This is the reason I describe it as a "research project".

In the end, Knative community will learn a lot from this exercise. I am pretty sure we will find some bad designs, some tight couplings, etc.

I would suggest doing these for starters:

• Knative Eventing - go through the tutorials as a user
• Knative Eventing control plane: for simplicity how these work: InMemoryChannel controller, Subscription controller
• kcp: go though the tutorials

[AmanSarraf]

Thanks for mentioning the pointers @aliok ,I am looking forward to explore the mentioned topics.

[aliok]

Feel free to reach out to the community at Knative Slack (https://github.com/knative/community/blob/main/SLACK-GUIDELINES.md) if you're stuck.

[evershalik]

Hi @aliok Me too interested in this project for GSoc 2023, can you instruct me for the same

[aliok]

hi @evershalik

Instructions above are the same for everyone :)

• Go through the tutorials at knative.dev, try things on your machine
• Start with some good-first issues
• Interact with the community: join Slack channels, introduce yourself, reach out whenever you're stuck in tutorials, ...

See cncf/mentoring#755 for finding good-first issues.

[octonawish-akcodes]

I am interested in this issue. I'll go through the references mentioned above.

[cubxxw]

That's cool. I want to try it. I want to research it~

[rutvik24]

@aliok I am interested too. and also thank you for providing stuff where to start

[ronitblenz]

Hi @aliok I am looking forward to contributing to this project. Few words about me, I have prior experience with open source contribution and also received scholarship to visit OSS Dublin 2022. I would love to know more about the project.

Thanks and Regards

[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.