...
- 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
new API is introduced into multicloud projects shown in the following slide.
the following table summarizes the impact on other projects
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.
SO and Controllers(SDN-C, APP-C, VF-C etc...)
Enhancements in SO and controllers to take advantage of enhanced Multi-Cloud model driven API that may be enhanced for container orchestrators. This will be done as a part of multi-cloud project.
This implies sort of converters from NS/VNF models(VNF descriptors, more higher level, it can be TOSCA ) to enhanced Multi-Cloud API or directly to k8s API.
Multi cloud project
Registry logic to reigster container instances. E.g. k8s instances and its API endpoint with its features.
API enhancements in Multi-Cloud project to enable container orchestration technologies through planned model driver API.(currently TOSCA): First target is Kubenetes plugin - converting the input from northbound API to kubernetes API.
Southbound plugin in Multi-cloud project to talk to container/COE. The first target will be kubernetes API.
Plugins to FCAPS/data management to report statistics(e.g. Cpu usage, memory usage) from underlying containers to upper ONAP component
API enhancements (if needed) in Multi-Cloud project to realize uniform network across VMs and containers instantiated by VIMs TBD : container orchestration api or CNCF using flannel with Multus
AAI
If necessary, enhance AAI schema to describe feature/capability of managed environment. This can be generic among VM-based VIM and container-based VIM.
multi-VIM project to report container orchestration features/capacity to AAI
DCAE
Plugin for event/stats collectors for containers
Policy
Awareness of container requirements. It won’t’ be directly referenced as container technology, but as, for example, performance requirement/low overhead requirement etc such as they can be achieved by container technology.
VNF SDK
...
First target for first release
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
First target for first release
- Container orchestration technology: First target of container orchestration is kubernetes. But support for other container orchestrations can/will be addressed later. SO and multicloud
- Sample VNF running within container: sample VNFs as vFW/vDNS
- test
Target for later release
- Installer/test/integration
- VNF SDK
- Policy
- Feedback to modeling project
- More container orchestration technology
- More than sample VNFs
- delegating functionalities to CoE/K8S
...