One possible multi-tenancy setup with Camel K is: - A single Camel K operator instance, managing the entire cluster - One namespace per tenant / user, that can contain one or more integration (think one integration = one Camel context)
If you really want strict multi-tenancy, it's also possible to have an operator instance per tenant (= namespace), but that comes with extra overheads, resources wise and operationally wise. > On 7 Dec 2021, at 15:39, Roberto Camelk <[email protected]> wrote: > > Thanks, Antonin. > > So, granularizing by tenancy by Camel Context is not the correct > approach, the namespace is the correct one. > > But, 1 Camel-K operator can switch between multiple contexts or for > this I need 1 operator to each new context I want? > > On Tue, Dec 7, 2021 at 11:27 AM Antonin Stefanutti > <[email protected]> wrote: >> >> Generally, the tenancy unit in a Kubernetes cluster is the namespace. >> >> For the operator, an instance can be deployed per tenant, or a single >> instance can be deployed for the cluster. >> >> Whatever options, the Camel K unit is the integration, whose Pod(s) host a >> single Camel context. >> >> For monitoring, the metrics exposed are tagged with the context info. >> >>> On 7 Dec 2021, at 15:15, Roberto Camelk <[email protected]> >>> wrote: >>> >>> We are thinking about organizing our infra loading one CamelContext >>> per tenant in our cloud. >>> >>> So the idea is one CamelContext per tenant, so each tenant has its own >>> environment and it can not be impacted by other tenant environments >>> (contexts). >>> >>> This makes sence? What are the issues about this abordation? This can >>> help or complicate the monitoring of this environments? >>> >>> Is it possible to have multiple CamelContexts using 1 Camel-K operator? >>
