...
The primary benefits of this approach are as follows:
- Life-cycle Management. Kubernetes is a comprehensive system for managing the life-cycle of containerized applications. Its use as a platform manager will ease the deployment of ONAP, provide fault tolerance and horizontal scalability, and enable seamless upgrades.
- Hardware Efficiency. As opposed to VMs that require a guest operating system be deployed along with the application, containers provide similar application encapsulation with neither the computing, memory and storage overhead nor the associated long term support costs of those guest operating systems. An informal goal of the project is to be able to create a development deployment of ONAP that can be hosted on a laptop.
- Deployment Speed. Eliminating the guest operating system results in containers coming into service much faster than a VM equivalent. This advantage can be particularly useful for ONAP where rapid reaction to inevitable failures will be critical in production environments.
- Cloud Provider Flexibility. A Kubernetes deployment of ONAP enables hosting the platform on multiple hosted cloud solutions like Google Compute Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more.
In no way does this project impair or undervalue the VM deployment methodology currently used in ONAP. Selection of an appropriate deployment solution is left to the ONAP user.
Challenges
Although the current structure of ONAP lends itself to a container based manager there are challenges that need to be overcome to complete this project as follows:
- Duplicate containers – The VM structure of ONAP hides internal container structure from each of the components including the existence of duplicate containers such as Maria DB.
- DCAE - The DCAE component not only is not containerized but also includes its own VM orchestration system. A possible solution is to not use the DCAE Controller but port this controller’s policies to Kubenetes directly, such as scaling CDAP nodes to match offered capacity.
- Ports - Flattening the containers also expose port conflicts between the containers which need to be resolved.
- Permanent Volumes - One or more permanent volumes need to be established to hold non-ephemeral configuration and state data.
- Configuration Parameters - Currently ONAP configuration parameters are stored in multiple files; a solution to coordinate these configuration parameters is required. Kubernetes Config Maps may provide a solution or at least partial solution to this problem.
- Container Dependencies – ONAP has built-in temporal dependences between containers on startup. Supporting these dependencies will likely result in multiple Kubernetes deployment specifications.
- Supplementing NEXUS repositories with additional containers which are currently built dynamically.
- Inactivating the DCAE Controller and replacing its functionality with native Kubernetes operations.
Scope:
- In scope: ONAP Platform lifecycle management & automation through containers, i.e.
- Automated deployment/un-deployment of ONAP instance(s) using containers
- Automated deployment/un-deployment of individual platform components using containers,
- Platform health checks, fault tolerance and self-healing using containers
- Platform horizontal scalability through containers
- Platform upgrades using containers
- Supplementing NEXUS repositories with additional containers which are currently built dynamically.
- Inactivating the DCAE Controller and replacing its functionality with native Kubernetes operations.
- Out of scope: support of container networking for VNFs. The project is about containerization of the ONAP platform itself.
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
- Please Include architecture diagram if possible
- What other ONAP projects does this project depend on?
- May have a close relationship with OAM (ONAP Administration and Management)
- How does this align with external standards/specifications?
- N/A
- Are there dependencies with other open source projects?
- Docker
- Kubernetes
...