...
- Support for co-existence of VNF VMs and VNF containers - Add container orchestration technology in addition to the traditional VM-based VIM or environment managed by ONAP. So that VNFs can be deployed within container by ONAP.
- Support in various ONAP projects to bring up VNFs as containers by standardized definition of workload as VM or container (e.g TOSCA model)
- Enhance VNF SDK to support container based VNFs.
- Support for uniform network connectivity among VMs and containers.
Goal and scope
Some of architecture/design are under discussion. subject to change depending on the outcome of discussion.the first target of container/COE is k8s. but other container/COE technology, e.g. docker swarm, is not precluded. If volunteers steped steps up for it, it would be also addressed.
The use of CoE/K8S is optional.
- Have ONAP take advantage of container/COE technology for cloud native era
- Utilizing of industry momentum/direction for container/COE
Influence/feedback the related technologies(e.g. TOSCA, container/COE)
Teach ONAP container/COE instead of openstack so that VNFs can be deployed/run over container/COE in cloud native way
At the same time it's important to keep ONAP working, not break them.
- Don’t change the existing components
- Leverage the existing interfaces and the integration points where possible
the scope of Beijing is
Pure COE/K8S deployment
Assume that COE/K8S is already deployed
Deployment unit is Pod
Future work
Hybrid deployment: VM + container (+ PF)
Dynamic deployment of COE/K8S instances on demand
Multicloud: basic API
Lifecycle management: keep compatibility of APP-C
No (major) change by using bare pod
Future work
Delegation in APP-C or VNF controllers is future work
Functionality
- 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.
...
- Installer/test/integration
- VNF SDK
- Policy
- Feedback to modeling project
- More container orchestration technology
- More than sample VNFs
- delegating functionalities to CoE/K8S
Non-Goal/out of scope
The followings are not goal or out-of-scope of this proposal.
...
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 slide is cited from multi-cloud slide and modified for this proposal. The first target will be small part of them.
...
depicts the basic workflow.
work flow to register k8s
...
instance
work flow to deploy VNF into pod
...
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)
...