ONAP Container/Container Orchestration Engine(COE) support

Code Name: TBD(invent short fancy 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] #coe Team ONAP5ONAP7, Fri Friday UTC 02:00 / China 10:00 / Eastern 21:00(Thr) / Pacific 18:00(Thr) From Nov 30/Dec 1, 2017.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 subcommittee
• update matrials for architecture subcommittee
• settle down legistics
  • subproject under the umbrella of multicloud project
  • sub PTL for
  • setup repo
    • committers
  • JIRA items
• Beijing planning
  
  • use case
• archtecture/API design: WIP
  • discussion is ongoing at https://gerrit.onap.org/r/#/c/30027/
  • collect k8s usage options
    
    • Munish proposal
    • Isaku proposal
    • Bin Hu proposal:
    slides needs to be uploaded
    • Frank proposal
  • impact on modeling
  • impact on policy
  • impact on TOSCA
• use case proposal
  • impacted projects
• architecture proposal
  • discussion points
  • how to register k8s cluster
  • how to deploy vnf
  • life cycle management and others(e.g. auto scaling): generic VNF controllers
• Create repository: now asking Gildas infra manager for it.
• start implementation

timeline

• determine timeslot for oneline meeting
• the week of Nov 30/Dec 1, 2017: first online meeting
• the week of Dec 4: kubecon: will skip
• the week of Dec 11: ONAP developer event. Let's have f2f session there.
• the week of Dec 18:
  
  • zoom meeting? or skip?
• after that, online meeting
• Maybe people will be on vacation around chrismas/new year
• The week of Dec 25: skip
• The week of Jan 1: skip?
• The week of Jan 8: Time slot will be determined by doodle poll
• the week of TBD: usecase subcommittee meeting
• The week of TBD: archtecture subcommittee meeting
• The week of TBD: present for TSC for new projects(or taskforce or whatever)

• Feb 5, 2018: discussion at multicloud meeting
• Feb 6, 2018: weekly meeting
• Feb 18, 2018: M2 deadline

Design Documents

• Multicloud API design for K8s for Beijing: work-in-progress

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: TBDCOE

Repository name: TBDmulticloud/container

Project Description:

The effort will investigate/drive a way to allow ONAP to deploy/manage Network Services/VNFs over container/COE.

...

• Support for multiple container orchestration technologies as VIM(Virtualized Infrastructure Manager) technologies - Support container orchestration technology as VIM by ONAP and 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 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

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.

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)

...

• Don’t change the existing components/work flow with (mostly) zero impact.
• 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 cloud infrastructure as initial container orchestration technology under Multi-Cloud project.
  
  
  

API/Interfaces

the following table summarizes the impact on other projects

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

...

First target for first release

the scope of Beijing is

Scope for Beijing

1. 1. First baby step to support containers in a Kubernetes cluster via a Multicloud SBI / Plugin

   2. Minimal implementation with zero impact on MVP of Multicloud Beijing work

Use Cases

1. 1. Sample VNFs(vFW and vDNS)

integration scenario

1. 1. Register/unregister k8s cluster instance which is already deployed. (dynamic deployment of k8s is out of scope)

   2. onboard VNFD/NSD to use container

   3. Instantiate / de-instantiate containerized VNFs through K8S Plugin in K8S cluster

   4. Vnf configuration with sample VNFs(vFW, vDNS)

...

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

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)

Image Removed

This slide depicts the basic workflow.  

Image Added

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

Image RemovedImage Added

the work flow to deploy VNF into pod is as follows

Image RemovedImage Added

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.

Release Components Name:

Note: refer to existing project for details on how to fill out this table

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.

...