You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Roberto Camelk <be...@gmail.com> on 2021/12/07 14:15:58 UTC
Multiple CamelContexts using Camel-K
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?
Re: Multiple CamelContexts using Camel-K
Posted by Roberto Camelk <be...@gmail.com>.
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 will share the same instance of the
integration, and the metrics and logs will be a mess.
Is it possible to customize the quartus micro profile metrics to
inject labels about the current tenant name? Or I need to create my
own metrics inside the route flux?
On Wed, Dec 8, 2021 at 8:35 AM Antonin Stefanutti
<an...@stefanutti.fr.invalid> wrote:
>
> 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 <be...@gmail.com>> 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
> <an...@stefanutti.fr.invalid>> wrote:
>
>
> On 7 Dec 2021, at 18:31, Roberto Camelk <be...@gmail.com>> 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
> <an...@stefanutti.fr.invalid>> 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 <be...@gmail.com>> 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
> <an...@stefanutti.fr.invalid>> 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 <be...@gmail.com>> 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?
>
>
>
>
Re: Multiple CamelContexts using Camel-K
Posted by Antonin Stefanutti <an...@stefanutti.fr.INVALID>.
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 <be...@gmail.com>> 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
<an...@stefanutti.fr.invalid>> wrote:
On 7 Dec 2021, at 18:31, Roberto Camelk <be...@gmail.com>> 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
<an...@stefanutti.fr.invalid>> 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 <be...@gmail.com>> 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
<an...@stefanutti.fr.invalid>> 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 <be...@gmail.com>> 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?
Re: Multiple CamelContexts using Camel-K
Posted by Roberto Camelk <be...@gmail.com>.
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
<an...@stefanutti.fr.invalid> wrote:
>
>
> > On 7 Dec 2021, at 18:31, Roberto Camelk <be...@gmail.com> 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
> > <an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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
> >>> <an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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?
> >>>>
> >>
>
Re: Multiple CamelContexts using Camel-K
Posted by Antonin Stefanutti <an...@stefanutti.fr.INVALID>.
> On 7 Dec 2021, at 18:31, Roberto Camelk <be...@gmail.com> 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
> <an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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
>>> <an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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?
>>>>
>>
Re: Multiple CamelContexts using Camel-K
Posted by Roberto Camelk <be...@gmail.com>.
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?
On Tue, Dec 7, 2021 at 11:59 AM Antonin Stefanutti
<an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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
> > <an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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?
> >>
>
Re: Multiple CamelContexts using Camel-K
Posted by Antonin Stefanutti <an...@stefanutti.fr.INVALID>.
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 <be...@gmail.com> 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
> <an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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?
>>
Re: Multiple CamelContexts using Camel-K
Posted by Roberto Camelk <be...@gmail.com>.
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
<an...@stefanutti.fr.invalid> 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 <be...@gmail.com> 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?
>
Re: Multiple CamelContexts using Camel-K
Posted by Antonin Stefanutti <an...@stefanutti.fr.INVALID>.
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 <be...@gmail.com> 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?