Allow multiple operators in a single namespace

[christophd]

This is a follow-up on #3358

We should allow to install multiple operators in a single namespace for the sake of multi operator handling on a single cluster. At the moment we have static operator resource names (e.g. deployment name is camel-k-operator) so there can only be one single operator per namespace.

When dealing with multi tenancy on a cluster we should be able to run multiple (global) operators in a single namespace.

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

[valdar]

I think there is the opportunity to expand a little bit the scope of this issue by also provide a way to have multiple versions of the camel-k operator installed in parallel using label selection to restrict the resources each camel-k operator should watch and reconcile.

This would also hopefully simplify requiring a specific installation of the camel-k operator using the camel-k bundle without requiring to hand craft and tweak deployments.

Current State

The camel-k bundle sets up a camel-k operator upon installation which then relies on IntegrationPlatforms to configure its behavior.

The IntegrationPlatform is meant to:

• configure various aspect of the operator i.e. the registry where container images are pushed, some maven build configurations options, etc

• provide a basic multi tenancy model where each tenant is tied to a platform and scoped using an operator_id (in the form of a label/annotation on any resource that should be reconciled by the same operator)

• provide a basic support for platform vs user configurations i.e. the platform admin can configure some aspect of the camel-k operatore but users can further customize them by creating a local IntegrationPlatform

• provide a basic support for running more than one camel-k operator by introducing the concept of secondary platform

Even if some initial support for having multiple running camel-k operators exists, in order to have another operator installed, a deployment must be hand crafted and deployed to kubernetes resulting in additional manual work to be done and increasing the complexity of handling updated as the deployment must be amended manually as the camel-k bundle is not aware of such additional operators.

Also, dealing with multiple IntegrationPlatforms is very confusing, it is not used very often and discouraged.

Proposed state

Introduce a new model where the IntegrationPlatform is not used only to configure some aspect of the operator, but also as a way to request the deployment of a specific Camel K operator. Within this model there won’t be a single camel-k operator dealing with a multitude of configurations and behaviors but a number of camel-k operators reconciling specific resources potentially with specific requirements and behaviors.

To make this possible the camel-k operator needs to be split (at least from a responsibility point of view) into:

• camel-k platform controller which is responsible to reconcile IntegrationPlatforms

• camel-k operator which is responsible to reconcile all other camel-k CR such as Integration, Kamelet, KameletBinding, etc

[claudio4j]

How do you view the CRD upgrade changes and the different controller versions ?