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/
