I don't think there is a single "correct" model, as it depends on the definition and use cases / requirements. A working group has been created to address the multi-tenancy space:
https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/ https://github.com/kubernetes-sigs/multi-tenancy It appears one model is the "Namespaces as a Service", where namespaces are used as the tenant unit. This model emerges from the mechanisms already in place to isolate tenants, like RBAC, NetworkPolicies, Quotas, whose definitions are tightly bound to that of namespaces: https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/#namespaces-as-a-service On 8 Dec 2021, at 12:25, Roberto Camelk <[email protected]<mailto:[email protected]>> wrote: Antonin, is it correct assuming that the correct mode to deal with multi-tenancy in k8s is by using namespaces? There is any official documentation about this? On Tue, Dec 7, 2021 at 3:19 PM Antonin Stefanutti <[email protected]<mailto:[email protected]>> wrote: On 7 Dec 2021, at 18:31, Roberto Camelk <[email protected]<mailto:[email protected]>> wrote: Thanks again! But, to run a new integration on another namespace, how can I do this using the CLI ? My camel-k operator is running at the default namespace. I have second namespace named "poc", so to run my integration in that namespace I just run: kamel run MyIntegration.java -n poc Is this correct? Yes, that's correct. On Tue, Dec 7, 2021 at 11:59 AM Antonin Stefanutti <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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]<mailto:[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?
