Everyone knows the pain to install or update a monolithic OpenStack release every six months. How to make this process easier? How to containerize OpenStack release itself to make it fit into modern CI/CD workflow? The solution is to use the concept of cloud over cloud i.e. use Kubernetes as under cloud, then install OpenStack as Upper cloud. Kubernetes under cloud will install containerized OpenStack components, such as Horizon, Nova, Neutron, Cinder as normal Kubernetes applications with the help of package management tools like Helm.
After the completion of such a container based installation, OpenStack will function the same way as its monolithic counterpart. Users can launch virtual machines, configure it and migrate it as normal.
Containerized Cloud over Cloud
This is not a new concept. Before using Kubernetes as under cloud to install OpenStack, projects like OOO (OpenStack over OpenStack) from OpenStack.org can install different versions of OpenStack over existing OpenStack deployment. What is new here is that the monolithic OpenStack is containerized, which means each of its function blocks such as Neutron, Nova, Glance and so on, is running from a container. Kubernetes, as the orchestrator, installs those containerized OpenStack components with help of tools and solutions such as Helm, Armada, OpenStack-Helm charts and so on to realize OpenStack installation by descriptive ways, which is well fit into modern software CI/CD development model.
This diagram illustrates this concept: First, the bare metal server is installed with Linux operating systems such as CentOS. Then, Kubernetes is installed using Ansible together with tool sets as Helm, Armada to bootstrap the server in ZTP (zero touch provision) way.
All necessary Docker images for all those tools, Kubernetes system components (etcd, kube-api, kubelet,kube-proxy and so on) are all downloaded from the available Docker registry and installed automatically.
With work with Kubernetes platform, OpenStack-Helm, which are containerized OpenStack components, are pulled from github and installed automatically. By this way, containerized OpenStack installation is finished and you will get your familiar OpenStack GUI interface as usual. Your daily operation of OpenStack can be carried on.
Industry Example
StarlingX open source Edge Cloud is one of examples utilizing this approach. it realized a common platform to host containerized, cloud native applications and OpenStack virtual machine applications with Kubernetes as orchestrator in one unified infrastructure. Its architecture is illustrated by following diagram:
More information can be obtained from https://www.starlingx.io/.
After the bare metal server is up and running, the infrastructure orchestrator takes care of whole system software installation, management and configuration. It automatically installed and configured all necessary software components: Kubernetes orchestrator system component containers, Armada and Helm Kubernetes software management tools’ containers, local docker registry to name a few. At this moment, the server is a fully functioned, Kubernetes managed, container application platform. OpenStack can then be realized by downloading a batch of Helm charts for each of its function blocks, such as Nova, Neutron, Glance, Horizon provided by the OpenStack-Helm project. After installation is finished, a working OpenStack platform is running over Kubernetes orchestrator platform.
Due to this cloud native way of OpenStack installation, updating and upgrading your OpenStack deployment is easier, faster and being done in the same way as all other CI/CD based software development and release projects.
Knowledge, Experience and Learning 