ONAP Container/Container Orchestration Engine(COE) support
Code Name: COE
This page tracks the related materials/discussions/etc related to Container based network service/function deployment(ONAP container/Container Orchestration Engine(COE)) effort.
As starting point, this effort has started as small subgroup of multicloud as task force.As the efforts evolve, logistics would be revised. Maybe this task force would be promoted to a independent group or an independent project.
Meetings
- #coe Team ONAP7, Friday UTC 3:00pm from Jan 16/17, 2018. weekly meeting
- draft discussion for second presentation at architecture subcommittee draft slides/discussion will be posted here.
- Meeting Minutes
Items
determine timeslot for weekly zoom meeting: doodle poll- new time slot is China CST(Wed)2:00am/UTC(Wed) 18:00PM/ET(Tue) 13:00pm/PT(Tue) 10:00am
- start from Jan 16/17
materials for Usecase subcommitteeupdate matrials for architecture subcommitteesettle down legisticssubproject under the umbrella of multicloud projectsub PTL forsetup repocommitters
JIRA items
Beijing planninguse case
- archtecture/API design: WIP
- discussion is ongoing at https://gerrit.onap.org/r/#/c/30027/
collect k8s usage optionsMunish proposalIsaku proposalBin Hu proposal:Frank proposal
impact on modelingimpact on policyimpact on TOSCA
use case proposalimpacted projects
architecture proposaldiscussion pointshow to register k8s clusterhow to deploy vnflife cycle management and others(e.g. auto scaling): generic VNF controllers
- Create repository: now asking Gildas infra manager for it.
- start implementation
timeline
- Feb 5, 2018: discussion at multicloud meeting
- Feb 6, 2018: weekly meeting
- Feb 18, 2018: M2 deadline
Design Documents
Slides/links
- Jan 9, 2018: ARC subcommitee 2nd review: slide
Project template for project proposal
Project Name:
Project name: Container based network service/function deployment(ONAP container support):
code name: COE
Repository name: multicloud/container
Project Description:
The effort will investigate/drive a way to allow ONAP to deploy/manage Network Services/VNFs over container/COE.
Increasing VNF density on each node and latency requirements are driving container based VNFs. This project enhances ONAP to support VNFs as containers in addition to VNFs as VMs.
- Support for multiple container orchestration technologies as cloud infrastructure - allow VNFs to run within container technology and also allow closed feedback loop same to VM based VIM. e.g. openstack
- 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 for uniform network connectivity among VMs and containers.
Goal and scope
the first target of container/COE is k8s. but other container/COE technology, e.g. docker swarm, is not precluded. If volunteers steps up for it, it would be also addressed.
- 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/work flow with (mostly) zero impact.
- Leverage the existing interfaces and the integration points where possible
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 cloud infrastructure as initial container orchestration technology under Multi-Cloud project.
API/Interfaces
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 being discussed. |
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 plugin for COE/k8s. (depending on the community discussion, ARIA and helm support needs to be considered. But this is contained within multicloud project.) |
First target for first release
the scope of Beijing is
Scope for Beijing
First baby step to support containers in a Kubernetes cluster via a Multicloud SBI / Plugin
Minimal implementation with zero impact on MVP of Multicloud Beijing work
Use Cases
Sample VNFs(vFW and vDNS)
integration scenario
Register/unregister k8s cluster instance which is already deployed. (dynamic deployment of k8s is out of scope)
onboard VNFD/NSD to use container
Instantiate / de-instantiate containerized VNFs through K8S Plugin in K8S cluster
Vnf configuration with sample VNFs(vFW, vDNS)
Target for later release
- Installer/test/integration
- 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.
- Not installer/deployment. ONAP running over container
- OOM project ONAP on kubernetes
- https://wiki.onap.org/pages/viewpage.action?pageId=3247305
- https://wiki.onap.org/display/DW/ONAP+Operations+Manager+Project
- Self hosting/management might be possible. But it would be further phase.
- container/COE deployment
- On-demand Installing container/coe on public cloud/VMs/baremetal as cloud deployment
- This is also out of scope for now.
- For ease of use/deployment, this will be further phase.
Architecture Alignment.
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)
UseCases
- sample VNF(vFW and vDNS): In Beijing only deploying those VNF over CoE
- other potential usecases(vCPE) are addressed after Beijing release.
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)
Use the above information to create a key project facts section on your project page
Key Project Facts:
This project will be subproject of Multicloud project. Isaku will lead this effort under the umbrella of multicloud project.
NOTE: if this effort is sub-project of multicloud as ARC committee recommended, this will be same to multicloud's.
Facts | Info |
---|---|
PTL (first and last name) | same to multicloud project |
Jira Project Name | same to multicloud project |
Jira Key | same to multicloud project |
Project ID | same to multicloud project |
Link to Wiki Space | Container based network service/function deployment (DEPRECATED) |
Release Components Name:
Note: refer to existing project for details on how to fill out this table
Components Name | Components Repository name | Maven Group ID | Components Description |
---|---|---|---|
container | multicloud/container | org.onap.multicloud.container | container orchestration engine cloud infrastructure |
Resources committed to the Release:
Note 1: No more than 5 committers per project. Balance the committers list and avoid members representing only one company.
Note 2: It is critical to complete all the information requested, that will help to fast forward the onboarding process.
Role | First Name Last Name | Linux Foundation ID | Email Address | Location |
---|---|---|---|---|
committer | Isaku Yamahata | yamahata | isaku.yamahata@gmail.com | PT(pacific time zone) |
contributors | Munish Agarwal | Munish.Agarwal@ericsson.com | ||
Bin Hu | bh526r | bh526r@att.com | ||
Manjeet S. Bhatia | manjeets | |||
Phuoc Hoang | hoangphuocbk | phuoc.hc@dcn.ssu.ac.kr | ||
Mohamed ElSerngawy | melserngawy | mohamed.elserngawy@kontron.com | EST | |
Interested (will attend my first on 20180206) - part of oom and logging projects | michaelobrien | frank.obrien@amdocs.com | EST (GMT-5) |
12 Comments
Jason Hunt
Thank you for this proposal. This is an important area that ONAP needs to begin planning for, as we will see more containerized network functions in the future.
My biggest question is what is the best way to address these needs in ONAP, because (as the slides show) most of the changes impact existing projects. I don't know that Project is the right approach. I think perhaps it might be a mix of use cases and architecture subcommittee work.
Could we work during the Beijing release timeline to fully understand the impacts of containerized network functions on different projects & get buy-in from those projects to implement those changes in the 3rd release?
ramki krishnan
There are several interesting activities happening in the ecosystem around containerized network functions and beyond, e.g. https://datatracker.ietf.org/meeting/interim-2017-nfvrg-01/session/nfvrg. Perhaps worth having a sub-committee for driving this forward which is looking at the ecosystem and also the ONAP project impact which Jason mentioned. Thoughts?
Phuoc Hoang
Hi team,
Can I become a contributor for this project? I would like find some gaps between TOSCA and Kubernetes templates, K8s register and contribute code if possible.
Thanks!
Lukasz Rajewski
What is a relation of this project to Multi VIM/Cloud Project? Do issues and challenges addressed here will be (or already are) addressed in Multi VIM/Cloud Project?
Isaku Yamahata
Phuoc, please attend the weekly meeting (and multicloud weekliy meeting) and show your interest.
Let's discuss there in details.
Phuoc Hoang
In this week, I will upload some of my investigation about gaps between TOSCA and Kubernetes. Hope you guys can fix me about that.
Isaku Yamahata
@Lukasz, based on the feedback from ARC subcommittee, this effort would be a subproject under the unbrella of multicloud project.
Actually we have talked with them closely and will.
container support brings _new_ issues/challenges in addition to the existing ones that multicloud has been addressing.
Damian Nowak
Is there any work ongoing on containerized VNFs within MutliVIM/Cloud?
I tried to go thru the WIKI pages of MultiVIM, but haven`t found a lot...
Srinivasa Addepalli
Yes. Please see this link instead: Support for K8S (Kubernetes) based Cloud regions
Rebecca Lantz
What is the status of this? Does ONAP have any support for CNFs currently or planned? It looks like some work may have happened in multi-cloud, but I haven't found a use case or end-to-end support described anywhere.
Srinivasa Addepalli
Please see this link: K8S based Cloud Region Support on what would be available in R4.
For R5 (or R6 if R5 is going to be technical debt release), please check this : K8S based Cloud region support (Continue from R4)
Use cases that would be tested are:
Ritu Sood Kiran Kamineni Akhila Kishore
Dan Kohn
CNCF is pursuing work to support CNFs on ONAP. I'd encourage you to participate in these monthly calls: https://github.com/cncf/cnf-testbed