On Wed, Nov 2, 2016 at 1:04 PM, Kasun De Silva <[email protected]> wrote:

> Hi All,
>
> Past couple of days I was working on a POC for the $subject.
>
> Following is the current model that AppCloud use to create application /
> services. Basically for each application / service AppCloud will create a 
> *Deployment
> >> ReplicaSet >> Pod* in Kubernetes cluster. At this point each
> ReplicaSet created has only one replica which is a Pod. This deployment
> does not scale up or scale down under any circumstances.
>
> This effort is to bring up a new feature to autoscale the application /
> service deployed in AppCloud according to certain metrics.
>
> Basically as usual AppCloud will create a *Deployment >> RS >> Pod* in
> Kubernetes for each application / service created as in above scenario.
>
> With the new feature, user can set auto-scaling parameters in the
> application settings level. We are using Kubernetes v1.3.4, and by default
> it accepts following parameters for *Horizontal Pod Autoscaler* (HPA).
>
>    1. Minimum # of pods
>    2. Maximum # of pods
>    3. Target CPU Utilization
>
>
> and the autoscaling logic will be following,
>
> TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization)
> / TargetCPUUtilization)
>
> But target number of pods will be bounded by the values provided for the
> MinPods and MaxPods values.
>
> MinPods <= TargetNumOfPods <= MaxPods
>
> When user set the auto scale parameters AppCloud will basically create a
> Kubernetes HPA kind for the particular appllication / service version (This
> is on demand. we do not create an HPA kind for each application / service
> version that user creates.). So that HPA for that particular version will
> take responsibility of scaling up, scaling down of pods according to the
> given threshold. Following will be the model that we are using in
> Kubernetes with the autoscaling feature in AppCloud.
>

In the server less paradigm user should get a simple application creation
user experience, therefore making the auto scaling feature as the default
behavior is a good option. Also we have to send the minimum pod count to 2
to support node failures.

>
> Your thoughts and comments are welcome on this.
>
> Thanks,
> Kasun
> ​
> --
> *Kasun de Silva*
> Senior Software Engineer | Cloud TG
>
> WSO2 Inc <http://wso2.com>*. *|* E*mail : [email protected] | Mobile: +94
> 77 794 4260
>
>


-- 
Deependra Ariyadewa
WSO2, Inc. http://wso2.com/ http://wso2.org

email [email protected]; cell +94 71 403 5996 ;
Blog http://risenfall.wordpress.com/
PGP info: KeyID: 'DC627E6F'

*WSO2 - Lean . Enterprise . Middleware*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to