You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Jumani <Da...@shapeblue.com> on 2020/10/12 10:50:44 UTC
[DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Hi,
I'm currently working on adding support for CloudStack as a cloud provider for Kubernetes to allow it to dynamically scale the cluster size based on capacity requirements.
It runs as a separate pod in its own deployment and requires an API and Secret key to communicate with CloudStack.
While that's going on, I'd like some feedback on how it can be integrated and even deployed from the CloudStack side. I have three proposals and would like your input :
1. Provide the deployment yaml file to the user, have them change the min and max cluster size to suit their requirement, provide the API keys as Kubernetes secrets and deploy it themselves. (Most flexible as the user can change several autoscaling parameters as well)
2. Deploy it via the scaleKubernetesCluster API. This will require adding additional parameters to the API such as minsize, maxsize, apikey and secretkey for the service to communicate with CloudStack. (Uses default autoscaling parameters, api keys provided by the user)
3. Deploy it via the scaleKubernetesCluster API, but also create a service account and use its API keys to communicate with CloudStack. The user will still need to provide the minsize and maxsize to the API. (Uses default autoscaling parameters, api keys generated and used by a service account, which if deleted could cause issues)
The design document can be found here :
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
Additional info can be found here :
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
Look forward to hearing from you!
Thanks,
David
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by David Jumani <Da...@shapeblue.com>.
A service account with only access to the listKubernetesCluster and scaleKubernetesCluster should work.
But to prevent a single API key from being used to mess with all the clusters, multiple users within the service account, mapping to each account which has a cluster with autoscaling enabled will need to be created. This might add additional complexity.
How about asking the user to provide API keys instead (or generating them if not already created) ?
________________________________
From: Sven Vogel <S....@ewerk.com>
Sent: Wednesday, October 14, 2020 2:45 AM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Maybe RBAC this is not a bad idea so it’s possible to grant different permissions to users or the service user.
________________________________
Von: Rakesh v <ww...@gmail.com>>
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com<http://www.ewerk.com>
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
Gesendet: Tuesday, October 13, 2020 9:53:16 PM
An: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Betreff: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Service account best suits the need. We can probably apply some RBAC on the account if possible
Sent from my iPhone
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
> On 12-Oct-2020, at 2:19 PM, David Jumani <Da...@shapeblue.com> wrote:
>
> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or create a service account and use its keys?
>
> ________________________________
> From: Rakesh v <ww...@gmail.com>>>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather than providing yaml files to them. Using API we can do automation also and editing yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>> On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com> wrote:
>>
>> Hi Daan,
>>
>> Thanks for your feedback!
>> Wrt the ideas, Submitting a yaml to an API would be redundant since the user can deploy it himself.
>> The API proposal was to simplify it for the user so they can just pass min / max size as well as API keys if needed (so no tweaking a yaml file)
>> The scaleAPI could have a flag to indicate whether it enables autoscaling or not, and if enabled, the additional fields provided.
>>
>> Thanks,
>> David
>> ________________________________
>> From: Daan Hoogland <da...@gmail.com>
>> Sent: Monday, October 12, 2020 4:36 PM
>> To: dev <de...@cloudstack.apache.org>
>> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>>
>> David,
>> as a general principle an API called scale<something> should not be used to
>> configure autoscaling of <something> in my opinion.
>> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
>> instead of requiring an yaml we could just ask for the required fields
>>
>>> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I'm currently working on adding support for CloudStack as a cloud provider
>>> for Kubernetes to allow it to dynamically scale the cluster size based on
>>> capacity requirements.
>>> It runs as a separate pod in its own deployment and requires an API and
>>> Secret key to communicate with CloudStack.
>>>
>>> While that's going on, I'd like some feedback on how it can be integrated
>>> and even deployed from the CloudStack side. I have three proposals and
>>> would like your input :
>>>
>>> 1. Provide the deployment yaml file to the user, have them change the
>>> min and max cluster size to suit their requirement, provide the API keys as
>>> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
>>> change several autoscaling parameters as well)
>>> 2. Deploy it via the scaleKubernetesCluster API. This will require
>>> adding additional parameters to the API such as minsize, maxsize, apikey
>>> and secretkey for the service to communicate with CloudStack. (Uses default
>>> autoscaling parameters, api keys provided by the user)
>>> 3. Deploy it via the scaleKubernetesCluster API, but also create a
>>> service account and use its API keys to communicate with CloudStack. The
>>> user will still need to provide the minsize and maxsize to the API. (Uses
>>> default autoscaling parameters, api keys generated and used by a service
>>> account, which if deleted could cause issues)
>>>
>>> The design document can be found here :
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>>>
>>> Additional info can be found here :
>>>
>>> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>>>
>>> Look forward to hearing from you!
>>>
>>> Thanks,
>>> David
>>>
>>> David.Jumani@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>
>> --
>> Daan
>>
>> David.Jumani@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>>
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Sven Vogel <S....@ewerk.com>.
Maybe RBAC this is not a bad idea so it’s possible to grant different permissions to users or the service user.
________________________________
Von: Rakesh v <ww...@gmail.com>
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
Gesendet: Tuesday, October 13, 2020 9:53:16 PM
An: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Betreff: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Service account best suits the need. We can probably apply some RBAC on the account if possible
Sent from my iPhone
> On 12-Oct-2020, at 2:19 PM, David Jumani <Da...@shapeblue.com> wrote:
>
> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or create a service account and use its keys?
>
> ________________________________
> From: Rakesh v <ww...@gmail.com>>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather than providing yaml files to them. Using API we can do automation also and editing yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>> On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com> wrote:
>>
>> Hi Daan,
>>
>> Thanks for your feedback!
>> Wrt the ideas, Submitting a yaml to an API would be redundant since the user can deploy it himself.
>> The API proposal was to simplify it for the user so they can just pass min / max size as well as API keys if needed (so no tweaking a yaml file)
>> The scaleAPI could have a flag to indicate whether it enables autoscaling or not, and if enabled, the additional fields provided.
>>
>> Thanks,
>> David
>> ________________________________
>> From: Daan Hoogland <da...@gmail.com>
>> Sent: Monday, October 12, 2020 4:36 PM
>> To: dev <de...@cloudstack.apache.org>
>> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>>
>> David,
>> as a general principle an API called scale<something> should not be used to
>> configure autoscaling of <something> in my opinion.
>> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
>> instead of requiring an yaml we could just ask for the required fields
>>
>>> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I'm currently working on adding support for CloudStack as a cloud provider
>>> for Kubernetes to allow it to dynamically scale the cluster size based on
>>> capacity requirements.
>>> It runs as a separate pod in its own deployment and requires an API and
>>> Secret key to communicate with CloudStack.
>>>
>>> While that's going on, I'd like some feedback on how it can be integrated
>>> and even deployed from the CloudStack side. I have three proposals and
>>> would like your input :
>>>
>>> 1. Provide the deployment yaml file to the user, have them change the
>>> min and max cluster size to suit their requirement, provide the API keys as
>>> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
>>> change several autoscaling parameters as well)
>>> 2. Deploy it via the scaleKubernetesCluster API. This will require
>>> adding additional parameters to the API such as minsize, maxsize, apikey
>>> and secretkey for the service to communicate with CloudStack. (Uses default
>>> autoscaling parameters, api keys provided by the user)
>>> 3. Deploy it via the scaleKubernetesCluster API, but also create a
>>> service account and use its API keys to communicate with CloudStack. The
>>> user will still need to provide the minsize and maxsize to the API. (Uses
>>> default autoscaling parameters, api keys generated and used by a service
>>> account, which if deleted could cause issues)
>>>
>>> The design document can be found here :
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>>>
>>> Additional info can be found here :
>>>
>>> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>>>
>>> Look forward to hearing from you!
>>>
>>> Thanks,
>>> David
>>>
>>> David.Jumani@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>
>> --
>> Daan
>>
>> David.Jumani@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>>
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Rakesh v <ww...@gmail.com>.
Service account best suits the need. We can probably apply some RBAC on the account if possible
Sent from my iPhone
> On 12-Oct-2020, at 2:19 PM, David Jumani <Da...@shapeblue.com> wrote:
>
> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or create a service account and use its keys?
>
> ________________________________
> From: Rakesh v <ww...@gmail.com>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather than providing yaml files to them. Using API we can do automation also and editing yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> David.Jumani@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>> On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com> wrote:
>>
>> Hi Daan,
>>
>> Thanks for your feedback!
>> Wrt the ideas, Submitting a yaml to an API would be redundant since the user can deploy it himself.
>> The API proposal was to simplify it for the user so they can just pass min / max size as well as API keys if needed (so no tweaking a yaml file)
>> The scaleAPI could have a flag to indicate whether it enables autoscaling or not, and if enabled, the additional fields provided.
>>
>> Thanks,
>> David
>> ________________________________
>> From: Daan Hoogland <da...@gmail.com>
>> Sent: Monday, October 12, 2020 4:36 PM
>> To: dev <de...@cloudstack.apache.org>
>> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>>
>> David,
>> as a general principle an API called scale<something> should not be used to
>> configure autoscaling of <something> in my opinion.
>> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
>> instead of requiring an yaml we could just ask for the required fields
>>
>>> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I'm currently working on adding support for CloudStack as a cloud provider
>>> for Kubernetes to allow it to dynamically scale the cluster size based on
>>> capacity requirements.
>>> It runs as a separate pod in its own deployment and requires an API and
>>> Secret key to communicate with CloudStack.
>>>
>>> While that's going on, I'd like some feedback on how it can be integrated
>>> and even deployed from the CloudStack side. I have three proposals and
>>> would like your input :
>>>
>>> 1. Provide the deployment yaml file to the user, have them change the
>>> min and max cluster size to suit their requirement, provide the API keys as
>>> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
>>> change several autoscaling parameters as well)
>>> 2. Deploy it via the scaleKubernetesCluster API. This will require
>>> adding additional parameters to the API such as minsize, maxsize, apikey
>>> and secretkey for the service to communicate with CloudStack. (Uses default
>>> autoscaling parameters, api keys provided by the user)
>>> 3. Deploy it via the scaleKubernetesCluster API, but also create a
>>> service account and use its API keys to communicate with CloudStack. The
>>> user will still need to provide the minsize and maxsize to the API. (Uses
>>> default autoscaling parameters, api keys generated and used by a service
>>> account, which if deleted could cause issues)
>>>
>>> The design document can be found here :
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>>>
>>> Additional info can be found here :
>>>
>>> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>>>
>>> Look forward to hearing from you!
>>>
>>> Thanks,
>>> David
>>>
>>> David.Jumani@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>
>> --
>> Daan
>>
>> David.Jumani@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>>
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by David Jumani <Da...@shapeblue.com>.
Right now I've gone with the approach of creating a user in the cluster owner's account with the suffix '-kubeadmin'. That way api permissions won't be an issue and neither will a globally set api key and secret cause security loopholes.
It seems the simplest and meets the consensus of the discussion
________________________________
From: Paul Angus <pa...@shapeblue.com>
Sent: Thursday, November 5, 2020 4:07 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
I'm thinking about the way Accounts work. You could add users to the account, but their usernames would have to be unique. So an existing user would need another (different) username in the service account.
We're doing work on projects, where users (not accounts) can be members and have different roles in different projects. It may be possible to have a service 'project' with already existing users, but I've not tried it.
paul.angus@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Sven Vogel <S....@ewerk.com>
Sent: 13 October 2020 12:06
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Should it possible to grant other users the control about the service user?
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com<http://www.ewerk.com>
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
________________________________
Von: Paul Angus <pa...@shapeblue.com>
Gesendet: Tuesday, October 13, 2020 1:00:54 PM
An: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Betreff: RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
In the release notes for the old CCS we strongly recommended that the user created a service account or at least a service 'user'. Ultimately it has to be on the user to control 'who' can do what.
paul.angus@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
-----Original Message-----
From: David Jumani <Da...@shapeblue.com>
Sent: 13 October 2020 11:39
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Thanks Daan. Users within the same account can alter the cluster, so I'm thinking of a service user within the same account and use the service user's keys. This will also prevent any mess up if the user provides his keys and then later regenerates them.
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
That is a good question. Is the user going to be the only user responsible for messing up the k8 cluster, or will other users be able to as well? For convenience and if audit is to not lay false balme on a user, I'd say create a system/service account, if several users can mess up each other with it... makes sense?
On Tue, Oct 13, 2020 at 11:10 AM David Jumani <Da...@shapeblue.com>
wrote:
> Sounds good. And do you think it would be better to have the user
> provide the API keys or create a service account and use its keys?
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani
> <Da...@shapeblue.com>
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API
> > keys or create a service account and use its keys?
> >
> > ________________________________
> > From: Rakesh v <<http://>www.rakeshv.com@gmail.com<
> http://www.rakeshv.com@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> > support
> >
> > I prefer providing an API to customers with necessary parameters
> > rather than providing yaml files to them. Using API we can do
> > automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani
> > > <Da...@shapeblue.com>
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant
> > > since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just
> > > pass
> > min / max size as well as API keys if needed (so no tweaking a yaml
> > file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > ________________________________
> > > From: Daan Hoogland <da...@gmail.com>
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev <de...@cloudstack.apache.org>
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale<something> should not
> > > be
> used
> > to
> > > configure autoscaling of <something> in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required
> > > fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > David.Jumani@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size
> > >> based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an
> > >> API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three
> > >> proposals and would like your input :
> > >>
> > >> 1. Provide the deployment yaml file to the user, have them
> > >> change
> the
> > >> min and max cluster size to suit their requirement, provide the
> > >> API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as
> > >> the
> user
> > can
> > >> change several autoscaling parameters as well) 2. Deploy it via
> > >> the scaleKubernetesCluster API. This will require adding
> > >> additional parameters to the API such as minsize, maxsize,
> apikey
> > >> and secretkey for the service to communicate with CloudStack.
> > >> (Uses
> > default
> > >> autoscaling parameters, api keys provided by the user) 3.
> > >> Deploy it via the scaleKubernetesCluster API, but also create a
> > >> service account and use its API keys to communicate with CloudStack.
> The
> > >> user will still need to provide the minsize and maxsize to the API.
> > (Uses
> > >> default autoscaling parameters, api keys generated and used by a
> service
> > >> account, which if deleted could cause issues)
> > >>
> > >> The design document can be found here :
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autosca
> ler+for+CloudStack+Kubernetes+Service
> > >>
> > >> Additional info can be found here :
> > >>
> > >>
> >
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscale
> r/FAQ.md
> > >>
> > >> Look forward to hearing from you!
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> David.Jumani@shapeblue.com
> > >> www.shapeblue.com<http://www.shapeblue.com>
> > >> 3 London Bridge Street, 3rd floor, News Building, London SE1
> > >> 9SGUK @shapeblue
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Daan
> > >
> > > David.Jumani@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 3 London Bridge Street, 3rd floor, News Building, London SE1
> > > 9SGUK @shapeblue
> > >
> > >
> > >
> >
>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Paul Angus <pa...@shapeblue.com>.
I'm thinking about the way Accounts work. You could add users to the account, but their usernames would have to be unique. So an existing user would need another (different) username in the service account.
We're doing work on projects, where users (not accounts) can be members and have different roles in different projects. It may be possible to have a service 'project' with already existing users, but I've not tried it.
paul.angus@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Sven Vogel <S....@ewerk.com>
Sent: 13 October 2020 12:06
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Should it possible to grant other users the control about the service user?
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
________________________________
Von: Paul Angus <pa...@shapeblue.com>
Gesendet: Tuesday, October 13, 2020 1:00:54 PM
An: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Betreff: RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
In the release notes for the old CCS we strongly recommended that the user created a service account or at least a service 'user'. Ultimately it has to be on the user to control 'who' can do what.
paul.angus@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
-----Original Message-----
From: David Jumani <Da...@shapeblue.com>
Sent: 13 October 2020 11:39
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Thanks Daan. Users within the same account can alter the cluster, so I'm thinking of a service user within the same account and use the service user's keys. This will also prevent any mess up if the user provides his keys and then later regenerates them.
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
That is a good question. Is the user going to be the only user responsible for messing up the k8 cluster, or will other users be able to as well? For convenience and if audit is to not lay false balme on a user, I'd say create a system/service account, if several users can mess up each other with it... makes sense?
On Tue, Oct 13, 2020 at 11:10 AM David Jumani <Da...@shapeblue.com>
wrote:
> Sounds good. And do you think it would be better to have the user
> provide the API keys or create a service account and use its keys?
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani
> <Da...@shapeblue.com>
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API
> > keys or create a service account and use its keys?
> >
> > ________________________________
> > From: Rakesh v <<http://>www.rakeshv.com@gmail.com<
> http://www.rakeshv.com@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> > support
> >
> > I prefer providing an API to customers with necessary parameters
> > rather than providing yaml files to them. Using API we can do
> > automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani
> > > <Da...@shapeblue.com>
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant
> > > since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just
> > > pass
> > min / max size as well as API keys if needed (so no tweaking a yaml
> > file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > ________________________________
> > > From: Daan Hoogland <da...@gmail.com>
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev <de...@cloudstack.apache.org>
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale<something> should not
> > > be
> used
> > to
> > > configure autoscaling of <something> in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required
> > > fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > David.Jumani@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size
> > >> based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an
> > >> API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three
> > >> proposals and would like your input :
> > >>
> > >> 1. Provide the deployment yaml file to the user, have them
> > >> change
> the
> > >> min and max cluster size to suit their requirement, provide the
> > >> API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as
> > >> the
> user
> > can
> > >> change several autoscaling parameters as well) 2. Deploy it via
> > >> the scaleKubernetesCluster API. This will require adding
> > >> additional parameters to the API such as minsize, maxsize,
> apikey
> > >> and secretkey for the service to communicate with CloudStack.
> > >> (Uses
> > default
> > >> autoscaling parameters, api keys provided by the user) 3.
> > >> Deploy it via the scaleKubernetesCluster API, but also create a
> > >> service account and use its API keys to communicate with CloudStack.
> The
> > >> user will still need to provide the minsize and maxsize to the API.
> > (Uses
> > >> default autoscaling parameters, api keys generated and used by a
> service
> > >> account, which if deleted could cause issues)
> > >>
> > >> The design document can be found here :
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autosca
> ler+for+CloudStack+Kubernetes+Service
> > >>
> > >> Additional info can be found here :
> > >>
> > >>
> >
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscale
> r/FAQ.md
> > >>
> > >> Look forward to hearing from you!
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> David.Jumani@shapeblue.com
> > >> www.shapeblue.com<http://www.shapeblue.com>
> > >> 3 London Bridge Street, 3rd floor, News Building, London SE1
> > >> 9SGUK @shapeblue
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Daan
> > >
> > > David.Jumani@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 3 London Bridge Street, 3rd floor, News Building, London SE1
> > > 9SGUK @shapeblue
> > >
> > >
> > >
> >
>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Sven Vogel <S....@ewerk.com>.
Should it possible to grant other users the control about the service user?
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
________________________________
Von: Paul Angus <pa...@shapeblue.com>
Gesendet: Tuesday, October 13, 2020 1:00:54 PM
An: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Betreff: RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
In the release notes for the old CCS we strongly recommended that the user created a service account or at least a service 'user'. Ultimately it has to be on the user to control 'who' can do what.
paul.angus@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: David Jumani <Da...@shapeblue.com>
Sent: 13 October 2020 11:39
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Thanks Daan. Users within the same account can alter the cluster, so I'm thinking of a service user within the same account and use the service user's keys. This will also prevent any mess up if the user provides his keys and then later regenerates them.
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
That is a good question. Is the user going to be the only user responsible for messing up the k8 cluster, or will other users be able to as well? For convenience and if audit is to not lay false balme on a user, I'd say create a system/service account, if several users can mess up each other with it... makes sense?
On Tue, Oct 13, 2020 at 11:10 AM David Jumani <Da...@shapeblue.com>
wrote:
> Sounds good. And do you think it would be better to have the user
> provide the API keys or create a service account and use its keys?
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani
> <Da...@shapeblue.com>
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API
> > keys or create a service account and use its keys?
> >
> > ________________________________
> > From: Rakesh v <<http://>www.rakeshv.com@gmail.com<
> http://www.rakeshv.com@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> > support
> >
> > I prefer providing an API to customers with necessary parameters
> > rather than providing yaml files to them. Using API we can do
> > automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani
> > > <Da...@shapeblue.com>
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant
> > > since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just
> > > pass
> > min / max size as well as API keys if needed (so no tweaking a yaml
> > file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > ________________________________
> > > From: Daan Hoogland <da...@gmail.com>
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev <de...@cloudstack.apache.org>
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale<something> should not
> > > be
> used
> > to
> > > configure autoscaling of <something> in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required
> > > fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > David.Jumani@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size
> > >> based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an
> > >> API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three
> > >> proposals and would like your input :
> > >>
> > >> 1. Provide the deployment yaml file to the user, have them
> > >> change
> the
> > >> min and max cluster size to suit their requirement, provide the
> > >> API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as
> > >> the
> user
> > can
> > >> change several autoscaling parameters as well) 2. Deploy it via
> > >> the scaleKubernetesCluster API. This will require adding
> > >> additional parameters to the API such as minsize, maxsize,
> apikey
> > >> and secretkey for the service to communicate with CloudStack.
> > >> (Uses
> > default
> > >> autoscaling parameters, api keys provided by the user) 3.
> > >> Deploy it via the scaleKubernetesCluster API, but also create a
> > >> service account and use its API keys to communicate with CloudStack.
> The
> > >> user will still need to provide the minsize and maxsize to the API.
> > (Uses
> > >> default autoscaling parameters, api keys generated and used by a
> service
> > >> account, which if deleted could cause issues)
> > >>
> > >> The design document can be found here :
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autosca
> ler+for+CloudStack+Kubernetes+Service
> > >>
> > >> Additional info can be found here :
> > >>
> > >>
> >
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscale
> r/FAQ.md
> > >>
> > >> Look forward to hearing from you!
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> David.Jumani@shapeblue.com
> > >> www.shapeblue.com<http://www.shapeblue.com>
> > >> 3 London Bridge Street, 3rd floor, News Building, London SE1
> > >> 9SGUK @shapeblue
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Daan
> > >
> > > David.Jumani@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 3 London Bridge Street, 3rd floor, News Building, London SE1
> > > 9SGUK @shapeblue
> > >
> > >
> > >
> >
>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
RE: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Paul Angus <pa...@shapeblue.com>.
In the release notes for the old CCS we strongly recommended that the user created a service account or at least a service 'user'. Ultimately it has to be on the user to control 'who' can do what.
paul.angus@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: David Jumani <Da...@shapeblue.com>
Sent: 13 October 2020 11:39
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Thanks Daan. Users within the same account can alter the cluster, so I'm thinking of a service user within the same account and use the service user's keys. This will also prevent any mess up if the user provides his keys and then later regenerates them.
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
That is a good question. Is the user going to be the only user responsible for messing up the k8 cluster, or will other users be able to as well? For convenience and if audit is to not lay false balme on a user, I'd say create a system/service account, if several users can mess up each other with it... makes sense?
On Tue, Oct 13, 2020 at 11:10 AM David Jumani <Da...@shapeblue.com>
wrote:
> Sounds good. And do you think it would be better to have the user
> provide the API keys or create a service account and use its keys?
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani
> <Da...@shapeblue.com>
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API
> > keys or create a service account and use its keys?
> >
> > ________________________________
> > From: Rakesh v <<http://>www.rakeshv.com@gmail.com<
> http://www.rakeshv.com@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> > support
> >
> > I prefer providing an API to customers with necessary parameters
> > rather than providing yaml files to them. Using API we can do
> > automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani
> > > <Da...@shapeblue.com>
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant
> > > since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just
> > > pass
> > min / max size as well as API keys if needed (so no tweaking a yaml
> > file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > ________________________________
> > > From: Daan Hoogland <da...@gmail.com>
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev <de...@cloudstack.apache.org>
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale<something> should not
> > > be
> used
> > to
> > > configure autoscaling of <something> in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required
> > > fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > David.Jumani@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size
> > >> based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an
> > >> API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three
> > >> proposals and would like your input :
> > >>
> > >> 1. Provide the deployment yaml file to the user, have them
> > >> change
> the
> > >> min and max cluster size to suit their requirement, provide the
> > >> API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as
> > >> the
> user
> > can
> > >> change several autoscaling parameters as well) 2. Deploy it via
> > >> the scaleKubernetesCluster API. This will require adding
> > >> additional parameters to the API such as minsize, maxsize,
> apikey
> > >> and secretkey for the service to communicate with CloudStack.
> > >> (Uses
> > default
> > >> autoscaling parameters, api keys provided by the user) 3.
> > >> Deploy it via the scaleKubernetesCluster API, but also create a
> > >> service account and use its API keys to communicate with CloudStack.
> The
> > >> user will still need to provide the minsize and maxsize to the API.
> > (Uses
> > >> default autoscaling parameters, api keys generated and used by a
> service
> > >> account, which if deleted could cause issues)
> > >>
> > >> The design document can be found here :
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autosca
> ler+for+CloudStack+Kubernetes+Service
> > >>
> > >> Additional info can be found here :
> > >>
> > >>
> >
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscale
> r/FAQ.md
> > >>
> > >> Look forward to hearing from you!
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> David.Jumani@shapeblue.com
> > >> www.shapeblue.com<http://www.shapeblue.com>
> > >> 3 London Bridge Street, 3rd floor, News Building, London SE1
> > >> 9SGUK @shapeblue
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Daan
> > >
> > > David.Jumani@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 3 London Bridge Street, 3rd floor, News Building, London SE1
> > > 9SGUK @shapeblue
> > >
> > >
> > >
> >
>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by David Jumani <Da...@shapeblue.com>.
Thanks Daan. Users within the same account can alter the cluster, so I'm thinking of a service user within the same account and use the service user's keys. This will also prevent any mess up if the user provides his keys and then later regenerates them.
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Tuesday, October 13, 2020 3:28 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
That is a good question. Is the user going to be the only user responsible
for messing up the k8 cluster, or will other users be able to as well? For
convenience and if audit is to not lay false balme on a user, I'd say
create a system/service account, if several users can mess up each other
with it... makes sense?
On Tue, Oct 13, 2020 at 11:10 AM David Jumani <Da...@shapeblue.com>
wrote:
> Sounds good. And do you think it would be better to have the user provide
> the API keys or create a service account and use its keys?
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani <Da...@shapeblue.com>
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API keys or
> > create a service account and use its keys?
> >
> > ________________________________
> > From: Rakesh v <<http://>www.rakeshv.com@gmail.com<
> http://www.rakeshv.com@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
> >
> > I prefer providing an API to customers with necessary parameters rather
> > than providing yaml files to them. Using API we can do automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com>
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just pass
> > min / max size as well as API keys if needed (so no tweaking a yaml file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > ________________________________
> > > From: Daan Hoogland <da...@gmail.com>
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev <de...@cloudstack.apache.org>
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale<something> should not be
> used
> > to
> > > configure autoscaling of <something> in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > David.Jumani@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three proposals and
> > >> would like your input :
> > >>
> > >> 1. Provide the deployment yaml file to the user, have them change
> the
> > >> min and max cluster size to suit their requirement, provide the API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as the
> user
> > can
> > >> change several autoscaling parameters as well)
> > >> 2. Deploy it via the scaleKubernetesCluster API. This will require
> > >> adding additional parameters to the API such as minsize, maxsize,
> apikey
> > >> and secretkey for the service to communicate with CloudStack. (Uses
> > default
> > >> autoscaling parameters, api keys provided by the user)
> > >> 3. Deploy it via the scaleKubernetesCluster API, but also create a
> > >> service account and use its API keys to communicate with CloudStack.
> The
> > >> user will still need to provide the minsize and maxsize to the API.
> > (Uses
> > >> default autoscaling parameters, api keys generated and used by a
> service
> > >> account, which if deleted could cause issues)
> > >>
> > >> The design document can be found here :
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
> > >>
> > >> Additional info can be found here :
> > >>
> > >>
> >
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
> > >>
> > >> Look forward to hearing from you!
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> David.Jumani@shapeblue.com
> > >> www.shapeblue.com<http://www.shapeblue.com>
> > >> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > >> @shapeblue
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Daan
> > >
> > > David.Jumani@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > > @shapeblue
> > >
> > >
> > >
> >
>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Daan Hoogland <da...@gmail.com>.
That is a good question. Is the user going to be the only user responsible
for messing up the k8 cluster, or will other users be able to as well? For
convenience and if audit is to not lay false balme on a user, I'd say
create a system/service account, if several users can mess up each other
with it... makes sense?
On Tue, Oct 13, 2020 at 11:10 AM David Jumani <Da...@shapeblue.com>
wrote:
> Sounds good. And do you think it would be better to have the user provide
> the API keys or create a service account and use its keys?
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 6:28 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> Davis, how about a separate API called setAutoScalingParameter or
> setAutoScalingLimits?
>
> On Mon, Oct 12, 2020 at 2:19 PM David Jumani <Da...@shapeblue.com>
> wrote:
>
> > Thanks Rakesh.
> > Do you think it would be better to have the user provide the API keys or
> > create a service account and use its keys?
> >
> > ________________________________
> > From: Rakesh v <www.rakeshv.com@gmail.com<
> http://www.rakeshv.com@gmail.com>>
> > Sent: Monday, October 12, 2020 5:12 PM
> > To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
> >
> > I prefer providing an API to customers with necessary parameters rather
> > than providing yaml files to them. Using API we can do automation also
> and
> > editing yaml files can be sometimes messy
> >
> > Sent from my iPhone
> >
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> > > On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com>
> > wrote:
> > >
> > > Hi Daan,
> > >
> > > Thanks for your feedback!
> > > Wrt the ideas, Submitting a yaml to an API would be redundant since the
> > user can deploy it himself.
> > > The API proposal was to simplify it for the user so they can just pass
> > min / max size as well as API keys if needed (so no tweaking a yaml file)
> > > The scaleAPI could have a flag to indicate whether it enables
> > autoscaling or not, and if enabled, the additional fields provided.
> > >
> > > Thanks,
> > > David
> > > ________________________________
> > > From: Daan Hoogland <da...@gmail.com>
> > > Sent: Monday, October 12, 2020 4:36 PM
> > > To: dev <de...@cloudstack.apache.org>
> > > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler
> support
> > >
> > > David,
> > > as a general principle an API called scale<something> should not be
> used
> > to
> > > configure autoscaling of <something> in my opinion.
> > > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> > However
> > > instead of requiring an yaml we could just ask for the required fields
> > >
> > >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> > David.Jumani@shapeblue.com>
> > >> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I'm currently working on adding support for CloudStack as a cloud
> > provider
> > >> for Kubernetes to allow it to dynamically scale the cluster size based
> > on
> > >> capacity requirements.
> > >> It runs as a separate pod in its own deployment and requires an API
> and
> > >> Secret key to communicate with CloudStack.
> > >>
> > >> While that's going on, I'd like some feedback on how it can be
> > integrated
> > >> and even deployed from the CloudStack side. I have three proposals and
> > >> would like your input :
> > >>
> > >> 1. Provide the deployment yaml file to the user, have them change
> the
> > >> min and max cluster size to suit their requirement, provide the API
> > keys as
> > >> Kubernetes secrets and deploy it themselves. (Most flexible as the
> user
> > can
> > >> change several autoscaling parameters as well)
> > >> 2. Deploy it via the scaleKubernetesCluster API. This will require
> > >> adding additional parameters to the API such as minsize, maxsize,
> apikey
> > >> and secretkey for the service to communicate with CloudStack. (Uses
> > default
> > >> autoscaling parameters, api keys provided by the user)
> > >> 3. Deploy it via the scaleKubernetesCluster API, but also create a
> > >> service account and use its API keys to communicate with CloudStack.
> The
> > >> user will still need to provide the minsize and maxsize to the API.
> > (Uses
> > >> default autoscaling parameters, api keys generated and used by a
> service
> > >> account, which if deleted could cause issues)
> > >>
> > >> The design document can be found here :
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
> > >>
> > >> Additional info can be found here :
> > >>
> > >>
> >
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
> > >>
> > >> Look forward to hearing from you!
> > >>
> > >> Thanks,
> > >> David
> > >>
> > >> David.Jumani@shapeblue.com
> > >> www.shapeblue.com<http://www.shapeblue.com>
> > >> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > >> @shapeblue
> > >>
> > >>
> > >>
> > >>
> > >
> > > --
> > > Daan
> > >
> > > David.Jumani@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> > > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > > @shapeblue
> > >
> > >
> > >
> >
>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by David Jumani <Da...@shapeblue.com>.
Sounds good. And do you think it would be better to have the user provide the API keys or create a service account and use its keys?
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Monday, October 12, 2020 6:28 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Davis, how about a separate API called setAutoScalingParameter or
setAutoScalingLimits?
On Mon, Oct 12, 2020 at 2:19 PM David Jumani <Da...@shapeblue.com>
wrote:
> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or
> create a service account and use its keys?
>
> ________________________________
> From: Rakesh v <ww...@gmail.com>>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather
> than providing yaml files to them. Using API we can do automation also and
> editing yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
> > On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com>
> wrote:
> >
> > Hi Daan,
> >
> > Thanks for your feedback!
> > Wrt the ideas, Submitting a yaml to an API would be redundant since the
> user can deploy it himself.
> > The API proposal was to simplify it for the user so they can just pass
> min / max size as well as API keys if needed (so no tweaking a yaml file)
> > The scaleAPI could have a flag to indicate whether it enables
> autoscaling or not, and if enabled, the additional fields provided.
> >
> > Thanks,
> > David
> > ________________________________
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, October 12, 2020 4:36 PM
> > To: dev <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
> >
> > David,
> > as a general principle an API called scale<something> should not be used
> to
> > configure autoscaling of <something> in my opinion.
> > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> However
> > instead of requiring an yaml we could just ask for the required fields
> >
> >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> David.Jumani@shapeblue.com>
> >> wrote:
> >>
> >> Hi,
> >>
> >> I'm currently working on adding support for CloudStack as a cloud
> provider
> >> for Kubernetes to allow it to dynamically scale the cluster size based
> on
> >> capacity requirements.
> >> It runs as a separate pod in its own deployment and requires an API and
> >> Secret key to communicate with CloudStack.
> >>
> >> While that's going on, I'd like some feedback on how it can be
> integrated
> >> and even deployed from the CloudStack side. I have three proposals and
> >> would like your input :
> >>
> >> 1. Provide the deployment yaml file to the user, have them change the
> >> min and max cluster size to suit their requirement, provide the API
> keys as
> >> Kubernetes secrets and deploy it themselves. (Most flexible as the user
> can
> >> change several autoscaling parameters as well)
> >> 2. Deploy it via the scaleKubernetesCluster API. This will require
> >> adding additional parameters to the API such as minsize, maxsize, apikey
> >> and secretkey for the service to communicate with CloudStack. (Uses
> default
> >> autoscaling parameters, api keys provided by the user)
> >> 3. Deploy it via the scaleKubernetesCluster API, but also create a
> >> service account and use its API keys to communicate with CloudStack. The
> >> user will still need to provide the minsize and maxsize to the API.
> (Uses
> >> default autoscaling parameters, api keys generated and used by a service
> >> account, which if deleted could cause issues)
> >>
> >> The design document can be found here :
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
> >>
> >> Additional info can be found here :
> >>
> >>
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
> >>
> >> Look forward to hearing from you!
> >>
> >> Thanks,
> >> David
> >>
> >> David.Jumani@shapeblue.com
> >> www.shapeblue.com<http://www.shapeblue.com>
> >> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> >> @shapeblue
> >>
> >>
> >>
> >>
> >
> > --
> > Daan
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Daan Hoogland <da...@gmail.com>.
Davis, how about a separate API called setAutoScalingParameter or
setAutoScalingLimits?
On Mon, Oct 12, 2020 at 2:19 PM David Jumani <Da...@shapeblue.com>
wrote:
> Thanks Rakesh.
> Do you think it would be better to have the user provide the API keys or
> create a service account and use its keys?
>
> ________________________________
> From: Rakesh v <ww...@gmail.com>
> Sent: Monday, October 12, 2020 5:12 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> I prefer providing an API to customers with necessary parameters rather
> than providing yaml files to them. Using API we can do automation also and
> editing yaml files can be sometimes messy
>
> Sent from my iPhone
>
>
> David.Jumani@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
> > On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com>
> wrote:
> >
> > Hi Daan,
> >
> > Thanks for your feedback!
> > Wrt the ideas, Submitting a yaml to an API would be redundant since the
> user can deploy it himself.
> > The API proposal was to simplify it for the user so they can just pass
> min / max size as well as API keys if needed (so no tweaking a yaml file)
> > The scaleAPI could have a flag to indicate whether it enables
> autoscaling or not, and if enabled, the additional fields provided.
> >
> > Thanks,
> > David
> > ________________________________
> > From: Daan Hoogland <da...@gmail.com>
> > Sent: Monday, October 12, 2020 4:36 PM
> > To: dev <de...@cloudstack.apache.org>
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
> >
> > David,
> > as a general principle an API called scale<something> should not be used
> to
> > configure autoscaling of <something> in my opinion.
> > So option 1 seems the best to me (an submitYamlForKubernetes-API?)
> However
> > instead of requiring an yaml we could just ask for the required fields
> >
> >> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <
> David.Jumani@shapeblue.com>
> >> wrote:
> >>
> >> Hi,
> >>
> >> I'm currently working on adding support for CloudStack as a cloud
> provider
> >> for Kubernetes to allow it to dynamically scale the cluster size based
> on
> >> capacity requirements.
> >> It runs as a separate pod in its own deployment and requires an API and
> >> Secret key to communicate with CloudStack.
> >>
> >> While that's going on, I'd like some feedback on how it can be
> integrated
> >> and even deployed from the CloudStack side. I have three proposals and
> >> would like your input :
> >>
> >> 1. Provide the deployment yaml file to the user, have them change the
> >> min and max cluster size to suit their requirement, provide the API
> keys as
> >> Kubernetes secrets and deploy it themselves. (Most flexible as the user
> can
> >> change several autoscaling parameters as well)
> >> 2. Deploy it via the scaleKubernetesCluster API. This will require
> >> adding additional parameters to the API such as minsize, maxsize, apikey
> >> and secretkey for the service to communicate with CloudStack. (Uses
> default
> >> autoscaling parameters, api keys provided by the user)
> >> 3. Deploy it via the scaleKubernetesCluster API, but also create a
> >> service account and use its API keys to communicate with CloudStack. The
> >> user will still need to provide the minsize and maxsize to the API.
> (Uses
> >> default autoscaling parameters, api keys generated and used by a service
> >> account, which if deleted could cause issues)
> >>
> >> The design document can be found here :
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
> >>
> >> Additional info can be found here :
> >>
> >>
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
> >>
> >> Look forward to hearing from you!
> >>
> >> Thanks,
> >> David
> >>
> >> David.Jumani@shapeblue.com
> >> www.shapeblue.com<http://www.shapeblue.com>
> >> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> >> @shapeblue
> >>
> >>
> >>
> >>
> >
> > --
> > Daan
> >
> > David.Jumani@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
>
--
Daan
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by David Jumani <Da...@shapeblue.com>.
Thanks Rakesh.
Do you think it would be better to have the user provide the API keys or create a service account and use its keys?
________________________________
From: Rakesh v <ww...@gmail.com>
Sent: Monday, October 12, 2020 5:12 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
I prefer providing an API to customers with necessary parameters rather than providing yaml files to them. Using API we can do automation also and editing yaml files can be sometimes messy
Sent from my iPhone
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
> On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com> wrote:
>
> Hi Daan,
>
> Thanks for your feedback!
> Wrt the ideas, Submitting a yaml to an API would be redundant since the user can deploy it himself.
> The API proposal was to simplify it for the user so they can just pass min / max size as well as API keys if needed (so no tweaking a yaml file)
> The scaleAPI could have a flag to indicate whether it enables autoscaling or not, and if enabled, the additional fields provided.
>
> Thanks,
> David
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 4:36 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> David,
> as a general principle an API called scale<something> should not be used to
> configure autoscaling of <something> in my opinion.
> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
> instead of requiring an yaml we could just ask for the required fields
>
>> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
>> wrote:
>>
>> Hi,
>>
>> I'm currently working on adding support for CloudStack as a cloud provider
>> for Kubernetes to allow it to dynamically scale the cluster size based on
>> capacity requirements.
>> It runs as a separate pod in its own deployment and requires an API and
>> Secret key to communicate with CloudStack.
>>
>> While that's going on, I'd like some feedback on how it can be integrated
>> and even deployed from the CloudStack side. I have three proposals and
>> would like your input :
>>
>> 1. Provide the deployment yaml file to the user, have them change the
>> min and max cluster size to suit their requirement, provide the API keys as
>> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
>> change several autoscaling parameters as well)
>> 2. Deploy it via the scaleKubernetesCluster API. This will require
>> adding additional parameters to the API such as minsize, maxsize, apikey
>> and secretkey for the service to communicate with CloudStack. (Uses default
>> autoscaling parameters, api keys provided by the user)
>> 3. Deploy it via the scaleKubernetesCluster API, but also create a
>> service account and use its API keys to communicate with CloudStack. The
>> user will still need to provide the minsize and maxsize to the API. (Uses
>> default autoscaling parameters, api keys generated and used by a service
>> account, which if deleted could cause issues)
>>
>> The design document can be found here :
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>>
>> Additional info can be found here :
>>
>> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>>
>> Look forward to hearing from you!
>>
>> Thanks,
>> David
>>
>> David.Jumani@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>>
>>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Rakesh v <ww...@gmail.com>.
I prefer providing an API to customers with necessary parameters rather than providing yaml files to them. Using API we can do automation also and editing yaml files can be sometimes messy
Sent from my iPhone
> On 12-Oct-2020, at 1:13 PM, David Jumani <Da...@shapeblue.com> wrote:
>
> Hi Daan,
>
> Thanks for your feedback!
> Wrt the ideas, Submitting a yaml to an API would be redundant since the user can deploy it himself.
> The API proposal was to simplify it for the user so they can just pass min / max size as well as API keys if needed (so no tweaking a yaml file)
> The scaleAPI could have a flag to indicate whether it enables autoscaling or not, and if enabled, the additional fields provided.
>
> Thanks,
> David
> ________________________________
> From: Daan Hoogland <da...@gmail.com>
> Sent: Monday, October 12, 2020 4:36 PM
> To: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
>
> David,
> as a general principle an API called scale<something> should not be used to
> configure autoscaling of <something> in my opinion.
> So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
> instead of requiring an yaml we could just ask for the required fields
>
>> On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
>> wrote:
>>
>> Hi,
>>
>> I'm currently working on adding support for CloudStack as a cloud provider
>> for Kubernetes to allow it to dynamically scale the cluster size based on
>> capacity requirements.
>> It runs as a separate pod in its own deployment and requires an API and
>> Secret key to communicate with CloudStack.
>>
>> While that's going on, I'd like some feedback on how it can be integrated
>> and even deployed from the CloudStack side. I have three proposals and
>> would like your input :
>>
>> 1. Provide the deployment yaml file to the user, have them change the
>> min and max cluster size to suit their requirement, provide the API keys as
>> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
>> change several autoscaling parameters as well)
>> 2. Deploy it via the scaleKubernetesCluster API. This will require
>> adding additional parameters to the API such as minsize, maxsize, apikey
>> and secretkey for the service to communicate with CloudStack. (Uses default
>> autoscaling parameters, api keys provided by the user)
>> 3. Deploy it via the scaleKubernetesCluster API, but also create a
>> service account and use its API keys to communicate with CloudStack. The
>> user will still need to provide the minsize and maxsize to the API. (Uses
>> default autoscaling parameters, api keys generated and used by a service
>> account, which if deleted could cause issues)
>>
>> The design document can be found here :
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>>
>> Additional info can be found here :
>>
>> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>>
>> Look forward to hearing from you!
>>
>> Thanks,
>> David
>>
>> David.Jumani@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>>
>>
>
> --
> Daan
>
> David.Jumani@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by David Jumani <Da...@shapeblue.com>.
Hi Daan,
Thanks for your feedback!
Wrt the ideas, Submitting a yaml to an API would be redundant since the user can deploy it himself.
The API proposal was to simplify it for the user so they can just pass min / max size as well as API keys if needed (so no tweaking a yaml file)
The scaleAPI could have a flag to indicate whether it enables autoscaling or not, and if enabled, the additional fields provided.
Thanks,
David
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Monday, October 12, 2020 4:36 PM
To: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
David,
as a general principle an API called scale<something> should not be used to
configure autoscaling of <something> in my opinion.
So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
instead of requiring an yaml we could just ask for the required fields
On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
wrote:
> Hi,
>
> I'm currently working on adding support for CloudStack as a cloud provider
> for Kubernetes to allow it to dynamically scale the cluster size based on
> capacity requirements.
> It runs as a separate pod in its own deployment and requires an API and
> Secret key to communicate with CloudStack.
>
> While that's going on, I'd like some feedback on how it can be integrated
> and even deployed from the CloudStack side. I have three proposals and
> would like your input :
>
> 1. Provide the deployment yaml file to the user, have them change the
> min and max cluster size to suit their requirement, provide the API keys as
> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
> change several autoscaling parameters as well)
> 2. Deploy it via the scaleKubernetesCluster API. This will require
> adding additional parameters to the API such as minsize, maxsize, apikey
> and secretkey for the service to communicate with CloudStack. (Uses default
> autoscaling parameters, api keys provided by the user)
> 3. Deploy it via the scaleKubernetesCluster API, but also create a
> service account and use its API keys to communicate with CloudStack. The
> user will still need to provide the minsize and maxsize to the API. (Uses
> default autoscaling parameters, api keys generated and used by a service
> account, which if deleted could cause issues)
>
> The design document can be found here :
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>
> Additional info can be found here :
>
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>
> Look forward to hearing from you!
>
> Thanks,
> David
>
> David.Jumani@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
David.Jumani@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] CloudStack Kubernetes Cluster Auto-Scaler support
Posted by Daan Hoogland <da...@gmail.com>.
David,
as a general principle an API called scale<something> should not be used to
configure autoscaling of <something> in my opinion.
So option 1 seems the best to me (an submitYamlForKubernetes-API?) However
instead of requiring an yaml we could just ask for the required fields
On Mon, Oct 12, 2020 at 12:51 PM David Jumani <Da...@shapeblue.com>
wrote:
> Hi,
>
> I'm currently working on adding support for CloudStack as a cloud provider
> for Kubernetes to allow it to dynamically scale the cluster size based on
> capacity requirements.
> It runs as a separate pod in its own deployment and requires an API and
> Secret key to communicate with CloudStack.
>
> While that's going on, I'd like some feedback on how it can be integrated
> and even deployed from the CloudStack side. I have three proposals and
> would like your input :
>
> 1. Provide the deployment yaml file to the user, have them change the
> min and max cluster size to suit their requirement, provide the API keys as
> Kubernetes secrets and deploy it themselves. (Most flexible as the user can
> change several autoscaling parameters as well)
> 2. Deploy it via the scaleKubernetesCluster API. This will require
> adding additional parameters to the API such as minsize, maxsize, apikey
> and secretkey for the service to communicate with CloudStack. (Uses default
> autoscaling parameters, api keys provided by the user)
> 3. Deploy it via the scaleKubernetesCluster API, but also create a
> service account and use its API keys to communicate with CloudStack. The
> user will still need to provide the minsize and maxsize to the API. (Uses
> default autoscaling parameters, api keys generated and used by a service
> account, which if deleted could cause issues)
>
> The design document can be found here :
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cluster+Autoscaler+for+CloudStack+Kubernetes+Service
>
> Additional info can be found here :
>
> https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
>
> Look forward to hearing from you!
>
> Thanks,
> David
>
> David.Jumani@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan