Managing Container Clusters in OpenStack Native Way

Editor's Notes

• #5: The section which I will talk is “Why Containers, If you already have OpenStack.”
• #6: Container is a type of virtualization technology, and we can use it as computing resource. But computing resource?
• #7: OpenStack already has the Nova, which is an abstraction layoer of computing resource.
• #8: Basically Nova handles virtual machine, and Nova provides abstraction layer for managing virtual machine. So if container is a type of virtual machine, “Why Containers, If you already have OpenStack.” This diagram shows the difference between virtual machine and container model. Left side is a traditional virtual machine model. And right side is a container model. Virtual machine requires a hypervisor which emulate and translate the hardware, and has its own OS. Container provide isolation for processes sharing compute resources. They are similar to virtualized machine but share the host kernel and avoid hardware emulation. So you can use a Host resources more effectively than Virtual machine. Soin this case, you can use container like a virtual machine, It means that nova can manage containers.
• #9: In addition, Docker provides a simple tools and eco system for container which makes container technology become very polular . You can create container image easily using Dockerfile. You can share container image using docker registry, Container Image has all the additional dependencies that application need, above what is provided by host. You can move application from host to host easily.
• #10: Futthermore container scalability and elasticity are much better than virtual machine, and thanks to some managiment tools like kubernetes and docke swarm, managiment of containers between defferent host become much easier. So OpenStack needs this technology to make cloud managiment easiler.
• #11: This slide show major use cases of container technology. The first one is for application users, who only want the application to be started quickly, The don’t care how the application is started. For the application developers, they care about application lifecycles, version managiment and portablicty. And for cloud operators they care about how to manage infrastructure effectively, how to upgrade the system and so on.
• #12: Let’s see what container technology exists in OpenStack. we have nova lxc, docker and magnum so many projects supporting container technlogy.
• #13: For example, Nova has lxc driver and docker driver which provides same interface with virtual machine. User can start container like virtual machine. This model doesn’t support all the advantage of container technology, But this can meet the application user’s needs who just want to deploy application quickly.
• #14: Next heat. Heat has two way to manage cotainer. One is Docker::Container resource, and the other is SoftwareConfig or StructuredConfig Resource. This can also meet the application user’s needs but it has limitaion of managing the containers after they are created.
• #15: And the next is magnum. Magnum is a container orchestration engine as a service which deploy and manage COE. When magnum deploy the COE, user can use all of the advantage of container technology through it’s COE specific tools such as kubectl or docker cli. This can meet the developer and operator use cases. But you must manage containers without an OpenStack native way.
• #16: Next one is Kolla. Kolla is a OpenStack as a Service. which uses container technology to make managiment openstack easier. This is one caese of operator’s usecases. this is just use a containers but not a way to manage containers itself.
• #17: So in order to manage container well in OpenStack, we need to find the new solution. But we have a some problem to solve it. The commuty has disscussed a lot about this issues. Create an unified api which can support vm, baremetal and containers? But the usecase of vm and conrainer are different so we can’t provider unified API. next issue is how create an unified abstraction api for container orchestration engine? This also have same problem which is a difference between kuber But we can’t get an agreement on it.
• #29: As introduced previously Senlin is a project which provides clustering service, currently it only supports vm cluster. When supports container clustering, Senlin will do it in the similar way of vm clustering. So at first, we need a new type profile – a container type profile. In the profile we will define some properties which will be used to create containers. All necessary properties can be defined in this profile. The format is similar to Nova server format.
• #30: With the profile , we can create container nodes and container clusters, When create containers, we need host vms, and the host vms are also managed by Senlin.So Senlin can manage both vm layer and container layer.
• #31: This is the workflow of creating container cluster. We can create multiple containers in one vm depending on the vm resource. We can see physically containers are running on vms, but logically the container cluster(cluster2) and the vm cluster(cluster1) are separated clusters, Senlin can manage them separately. That means to end uses who just want containers, they may just see the container cluster.
• #32: Lets see how to manage the resources. The scalability control is the advantage of Senlin. When we have a vm cluster and container cluster, sometime the resource is not enough, it need to scale out. Senlin invents policies to tell the cluster how to scale out/scale in. As we see the policies are attached to the cluster. When the resource is not enough, we got an alarm from the ceilometer, the policy will be triggered. Then it will tell the vm cluster to create a vm, after that the scaling policy attached to the container cluster will be triggered, then a new container will be created. This is the scale out model, of course when the resources are idle, some vm/containers will be deleted. This is the way how senlin control cluster scalability.
• #35: About the design for container cluster, we still have some issues to think about. Everyone has its own advantage. When starting a container we need to determine starting it on which cluster which node. So do we need a scheduler to do this job. In senlin we have a placement policy, in the policy we can define where to start to nodes, it is a kind of scheduler, but very simple one, it’s not smart enough, we still need to improve it to meet our needs. Anyway it is a solution of this issue.
• #36: So we hope we can use Kuryr to create container network automatically just like we create vm network.
• #37: After all about container cluster support in senlin, we have had some discussions and have made some agreements on some issues. But we still want to hear more voices from the community, we need your ideas, your suggestions and also new hands, so please join us if you are interested in this job. You can find us on IRC senin channel and can also join our weekly meeting, any ideas are appreciated.