Hi devs,

I did some research on $subject and IMO kurburnetes integration going to be
worthwhile thing. Below is the possible way of integration and some
benefits.

Kuburnetes provide docker provisioning (orchestration), scheduling across
docker host cluster, Self-healing mechanisms, such as auto-restarting,
re-scheduling, and replicating containers. IMO we should used them without
inventing the wheel. I was there in Linixcon and google heavily use this in
large-scale. in current state they are creating 2 million new dockers
weekly using kuburnetes.

So, with kurburnetes we can handover docker management scheduler to
kurburnetes without handling in autoscaler.  which mean we are not going to
have deployment policies and partitions docker in stratos. Only there is
auto scaling policy. But it will not change for VM based cartridges which
currently has.

We can extend jclouds for support kurburnetes, mean we may no need to used
docker api, instead we need to have kurburnetes API.

WIth docker, we are doing to have two mode, dockers top of VM and dockers
top of bare-metal.(its simple version is dev env)

Below is the initial design we can consider.

   - need to have global docker registry for a stratos deployment


   - cartridge definition should have a docker file attached related to the
   cartridge. e.g if PHP cartridge definition, should attached php docker
   file. IMO we should used same for any other type, like puppet, it should
   attached puppet module (location) and we can dynamically install this
   module into puppet master, which Raj and Lasindu suggest in separate
   thread. So this going to be generic, while deploying cartridge definition,
   we are expecting related docker, puppet, .etc files for that cartridge and
   dynamically setup.
   - then we can build docker file and upload (push) image into global (for
   stratos) docker registry.
   - we can consider docker service is MT service in Stratos.
   - above docker cartridges available for application deployment only
   after docker MT host cluster available in VM mode or generally after
   dynamically registering kuburnetese endpoint.
   - In bare metal we can manually register kurburnetes end point.
   - So in the VM mode, we can have cartridge definition for docker host
   cluster (IMO we can used coreOS+keburnetes) and can deploy as MT service.
   it can have min, max and auto scaling, deployment polices.
   - With the MT service deployment, it will create docker host cluster.
   All monitoring and scaling will happen normal way.
   - in MT docker host service up, it will dynamically  register kuburnetes
   endpoint for docker deployment
   - After end point register, docker application deployment available for
   all pushed docker cartridges which in the global docker registry.
   - In case of having multiple kuburnetes endpoint user can choose any
   available docker cluster while deployment docker applications. also user
   can define min max for his docker application while in the creation time
   and can change any time. Also can attached the auto scaling policy
   - communicate to kuburnetes endpoint for orchestrate required dockers.
   Kuburnetes will take care of rest.
   - update the topology with the member endpoints
   - individual docker application can scale depending on assign auto
   scaling policy.
   - In the bare-metal mode, without MT mode, we can just register
   kuburnetes end point and then same way to create dockers.

This is initial though of design, please share your thought. Need to draw
some pictures, will work on that. and IMO we should have a hangout session,
badly need a white board for these kind of discussions

thanks


-- 
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692

   - Blog : http://lakmalsview.blogspot.com/

Reply via email to