...
- Allow VNFs within container through container orchestration managed by ONAP same to VM based VIM.
- Allow closed loop feedback and policy
- Allow container based VNFs to be designed
- Allow container based VNFs be configured and monitored.
- Kubernetes VIM as initial container orchestration technology under Multi-Cloud project.
API/Interfaces
component | comment |
modelling | New names of Data model to describe k8s node/COE instead of compute/openstack. Already modeling for k8s is proposed. |
SO | Multi-cloud adapter to call multicloud k8s driver. ARIA adaptor which already was merged will be utilized. The difference of VM and container will be hidden in model driver API |
OOF | New policy to use COE, to run VNF in container |
A&AI/ESR | Schema extensions to represent k8s data. (kay value pairs) |
Multicloud | New driver for COE/k8s. (depending on the community discussion, ARIA and helm support needs to be considered. But this is contained within multicloud project.) |
controllers/APP-C | No impact or new adapto |
General/cross projects:
- At first new TOSCA node definition will be introduced to express container requirement. In long term, contributing to TOSCA specification would be in scope side project.
- Network Service(NS) and/or VNF will be described in NSD or VNFD in TOSCA format. one of ONAP component need to generate necessary API requests to continer/COE
- representation in TOSCA to be defined. In longer term, we may want to give feedback to TOSCA spec.
...
How does this project fit into the rest of the ONAP Architecture?
The architecture (will be)is designed to enhancement to some existing project.
It doesn’t introduce new dependency
How does this align with external standards/specifications?
Convert TOSCA model to each container northbound APIs in some ONAP component. To be discussed.
Are there dependencies with other open source projects?
Kubernetes pod API or other container northbound AP
CNCF(Cloud Native Computing Foundation), OCI(Open Container Initiative), CNI(Container Networking interface)
This above slide depicts the basic workflow there is no workflow change except k8s driver in multicloud.
the work flow to register k8s instance is depicted as follows
the work flow to deploy VNF into pod is as follows
Other Information:
link to seed code (if applicable) N/A
Vendor Neutral
if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
Meets Board policy (including IPR)
...