...
Services like Kubernetes, Cloud Foundry, DBaaS require integration support from underlying cloudstackCloudStack. This support includes Grouping Vms, Scaling, Monitoring. Rather than making changes every time to support various services in ACS, a generic framework has to be developed.
Not only but predominantly As an example container technologies are gaining quite a momentum and changing the way how application are traditionally deployed in the public and private clouds. Gaining interest in micro services based architecture is also fostering adooption adoption of container technologies. Much like how cloud orchestration platforms enable the provisioning of VM's VMs and adjacent services, container orchestration platforms like Kubernetes [3], docker swarm [1], mesos [2] are emerging to enable orchestration of containers. Container orchestration platforms typically can be run any where and be used to provision containers. A popular choice of running containers has been running them on the IAAS IaaS provisioned VM'sVMs. AWS and GCE provide native functionality to launch containers abstracting out the underlying consumption of VM'sVMs. A container orchestration platform can be provisioned on top of CloudStack using development tools, (see [6]), but they are not an out of the box solution. Given the momentum of container technologies, micro-services etc it make sense to provide a native functionality in CloudStack which is available out-of-the-box for users.
Another example are DBaaS installations. These have different sets of roles then the above mentioned container services with different number of nodes in each role. Those two have usually only two roles but for instance sdn solutions might have three roles; switch-, controlplane- and configuration-machines.
Apache Cloudstack should not involve itself with how virtual machines are used, though plugins for CloudStack might be written that do configure sets of VMs for certain uses (like kubernetes in [8]). The intention of this functionality is to provide teh organisation of sets of VMs with roles to be used as a single application, be it a container cluster or a database or a SDN facility.
Purpose of this document is present the functional requirements for supporting generic vm cluster Purpose of this document is present the functional requirements for supporting generic vm cluster service functionality in CloudStack
...
PaaS - Platform as a service
...
CloudStack vm VM cluster service shall introduce the notion of application cluster. A 'application cluster' shall be first class CloudStack entity that will be a composite of existing CloudStack entities like virtual machines, network, network rules etc.
The application cluster service shall stitch together cluster resources, and deploys cluster resources. Any enhancements or plugins can call it to do further deploys of the chosen cluster manager like application like a manager and nodes in Kubernetes, Mesos, docker swarm etc, to provide the managers manager's service type, like AWS ECS, Google container service etc to the CloudStack users.
...
Container service shall provide following container cluster life-cycle operations.
As The provisioning of the service is out of scope for the application cluster. A calling plugin or external tool add value by calling, as part of its creation , application cluster shall be responsible for plan, any setting up of a control plane of the service type that was chosen. How a service will be setup is dependent on the chosen service type.
Following API shall be introduced with application cluster:
New reponse 'applicationclusterreponse' shall be added with below details:
...
Each of the life cycle operation is a workflow resulting in either provisioning or deleting multiple CloudStack resources. There is no guarantee a workflow of a life cycle operation will succeed due to lack of 2PC like model of resource reservation followed by provisioning semantics. Also there is no guarantee of a rollback getting succeededsucceeding. For e.g. instance, while provisioning a cluster of size 10 VM'sVMs, deployment may run out of capacity to provision any more VM's VMs after provisioning 5 Vm's the first five Vms. In which case as rollback provisioned VM's action, the provisioned VMs can be destroyed. But there can be cases where deleting a provisioned VM is not possible temporarily like disconnected hosts . For instance when a host is disconnected etc. So its not possible to achieve strong consistency and this will not be a focus in this phase of the development.
Below approach is followed while performing life cycle operations..
...
[7] https://github.com/kubernetes/kubernetes/tree/master/cluster/rackspace/cloud-config