Antonin ...
I got it, but In the scenario of a integration that can be shared
between all tenants and avoid the deploy duplication of the same
integration by namespace I need to go by the strategy to have 1
integration scaled, if necessary, in 1 namespace.
In this case, all my tenants wil
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
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
wrote:
>
>
> > On 7 Dec 2021, at 18:31, Roberto Camelk
> > wrote:
> >
> > Thanks aga
> On 7 Dec 2021, at 18:31, Roberto Camelk 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 n
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 co
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
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
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
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 abor
