...
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, (Tue) Friday UTC 20:00 / ET 16:00 / PT 13:003:00pm from Jan 16/17, 2018. weekly meeting
...
- Slides presented to architecture subcommittee to start this project as PoC :
nameK8S_for_VNFs_And_ONAP_Support.pptxView file
Version 2 of slides are here:
K8S_for_VNFs_And_ONAP_Support_v2.pptx
...
K8s Plugin progress slide:
Project (This is sub project of Multi-Cloud as decided by Architecture subcommittee & Multi-Cloud team)
...
- Create a Multi-Cloud plugin service that interacts with Cloud regions supporting K8S
- VNF Bring up:
- API: Exposes API to upper layers in ONAP to bring up VNF.
- Currently Proposal 2 (Please see the attached presentation and referenced in Slides/Links section) seems to be the choice.
- Information expected by this plugin :
- K8S deployment information (in the form understood by K8S), which is opaque to rest of ONAP. This information is normally expected to be provided as part of VNF onboarding in CSAR) and some information (variables values) are created part of every instantiation.
- TBD - Is this artifact passed to Multi-Cloud as reference or is it going to be passed as immediate data from the upper layers of ONAP.
- Note that there could be multiple artifacts for a given deployment. For example, EdgeXFoundry requires multiple deployment yaml files (one for each type of container) and multiple service yaml files. Since, there could be many of them, ordering in which they get executed is important. Hence, it is required that the priority order is given in a separate yaml artifact, which is interpreted only by K8S plugin.
- Supported K8S yaml artifacts - Deployment (POD, Daemonset, Stateful set)(, Service, Persistent volume). Others for for future releases.
- Kubernetes templates (artifacts) and variables:
- Since many instances of deployments can be instantiated using same CSAR, it is necessary that they are brought in different namespaces. Namespace name is expected to be part of variables (which is different for different instances).
- And also any template information starting with $.... is replaced from the variables.
- Metadata information collected by upper layers of ONAP
- Cloud region ID
- Set of compute profiles (One for each VDU
- Cloud region ID
- Set of compute profiles (One for each VDU within the VNF).
- TBD - Is there anything to be passed
- K8S deployment information (in the form understood by K8S), which is opaque to rest of ONAP. This information is normally expected to be provided as part of VNF onboarding in CSAR) and some information (variables values) are created part of every instantiation.
- Functionality:
- Instantiate VNFs that only consist of VMs.
- Instantiate VNFs that only consist of containers
- Instantiate multiple VNFs (some VNFs realized as VMs and some VNFs realized as containers) that communicate with each other on same networks (External Connection Points of various VNFs could be on the same network)
- Reference to newly brought up VNF is stored in A&AI (Which is needed when VNF needs to be brought down, modify the deployment)
- TBD - Should it populate A&AI with reference to each VM & Container instance of VNF? Or one reference to entire VNF instance good enough? Assuming that there is a need for storing reference to each VM/Container instance in A&AI, some exploration is required to see whether this information is made available by K8S API or should it watch for the events from K8S?
- TBD - Is there any other information that this plugin is expected to populate A&AI DB (IP address of each VM/Container instance) and anything else?
- API: Exposes API to upper layers in ONAP to bring up VNF.
- VNF Bring down:
- API: Exposes API function to upper layers in ONAP to terminate VNF
- Functionality: Based on the request coming from upper ONAP layer, it will terminate the VNF that was created earlier.
- Scaling within VNF:
- It leaves the decision of scaling-out and scaling-in of services of the VNF to the K8S controller at the cloud-region.
- (TBD) - How the configuration life cycle management be taken care?
- Should the plugin watch for new replicas being created by K8S and inform APPC, which in turn sends the configuration?
- Or should we let the new instance that is being brought up talk to APP-C or anything else and let it get the latest configuration?
- Healing & Workload Movement (Not part of Casablanca)
- No API is expected as it is assumed that K8S master at the cloud region will take care of this.
- TBD - Is there any information to be populated in the A&AI when some healing or workload movement occurs that the cloud-region.
- VNF scaling: (Not part of Casablanca)
- API : Scaling of entire VNF
- Similar to VNF bring up.
- API : Scaling of entire VNF
- Create Virtual Link:
- API : Exposes API to create virtual link
- Meta data
- Opaque information (Since OVN + SRIOV are chosen, opaque information passed to it is amenable to create networks and subnets as per the OVN/SRIOV Controller capabilities)
- Reference to the newly created network is added to the A&AI.
- If network already exists, it is expected that use count is incremented.
- Functionality:
- Creates network if it does not exist.
- Using OVN/SRIOV CNI API, it will populate remote DHCP/DNS Servers.
- TBD : Need to understand OVN controller and SRIOV controller capabilities and figure out the functionality of this API in this plugin.
- API : Exposes API to create virtual link
- Delete Virtual Link:
- API : Exposes API to delete virtual network
- Functionality:
- If there is no reference to this network (if use count is 0), then using OVN/SRIOV controllers, it deletes the virtual network.
- Create persistent volume
- Create volume that needs to exist across VNF life cycle.
- Delete persistent volume
- Delete volume
- VNF Bring up:
...
Activity (Non ONAP related, but necessary to prove K8S plugin) | Owner | Status |
---|---|---|
Add K8S installation scripts | Victor Morales | Done |
Add flannel Networking support | Victor Morales | Done |
Add OVN ansible playbook | Victor Morales | Done |
Create functional test to validate OVN operability | In progress | |
Add Virtlet ansible playbook | Victor Morales | In progressDone |
Create functional test to validate Virtlet operability | In progress | |
Prove deployment with EdgeXFoundry containers with flannel network | ramamani yeleswarapu | |
Prove deployment with one VM and container sharing flannel network | ||
Prove deployment with one VM and container sharing CNI network | ||
Add Multus CNI ansible playbook | ramamani yeleswarapu | In progress |
Create functional test to validate Multus CNI operability | ramamani yeleswarapu | |
Prove deployment with one VM (firewall VM) and container (simple router container) sharing two networks (both from OVN) | ||
Prove deployment with one VM and container sharing two networks (one from OVN and another from Flannel | ||
Document how the usage of the project | Victor Morales | In progress |
Add Node Feature Discovery for Kubernetes | Victor Morales | |
Create functional test for NFD | Victor Morales |
MultiCloud/Kubernetes Plugin
Translates the ONAP runtime instructions into Kubernetes RESTful API calls. Its temporal repository is https://github.com/shank7485/k8-plugin-multicloud
Activities:
Activity | Owner | Status |
---|---|---|
Create a layout for the project | Shashank Kumar Shankar | Done |
Create a README file with the basic installation instructions | Shashank Kumar Shankar | Done |
Define the initial swagger API | Shashank Kumar Shankar | Done |
Implement /vnf_instances POST endpoint | Victor Morales |
Done | ||
Implement the Create method for VNFInstanceClient struct | Victor Morales | Done |
Implement /vnf_instances GET endpoint | Done | |
Implement the List method for VNFInstanceClient struct | Victor Morales | Done |
Implement /vnf_instances/{name} GET endpoint | Victor Morales | In progress |
Implement the Get method for |
VNFInstanceClient struct | In progress | |
Implement /vnf_instances/{name} PATCH endpoint | In progress | |
Implement the Get method for VNFInstanceClient struct | Shashank Kumar Shankar | In progress |
Implement /vnf_instances/{name} DELETE endpoint |
Shashank Kumar Shankar | Done | |
Implement the Delete method for VNFInstanceClient struct | Done | |
Create the struct for the Creation response | ||
Create the struct for the List response | Victor Morales | |
Create the struct for the Get response | ||
K8S Plugin API definition towards rest of ONAP for compute | ||
K8S Plugin API definition towards rest of ONAP for networking | Shashank Kumar Shankar | |
K8S plugin API definition towards rest of ONAP for storage (May not be needed) | Shashank Kumar Shankar | |
Merge KRD and plugin repo and upload into the ONAP official repo | Victor Morales | |
SO Simulator for compute | Shashank Kumar Shankar | |
K8S plugin for compute Instantiation time:
|
|
Return values to be put in the A&AI
Testing with K8S reference deployment with hardcoded flannel configuration at the site (Using EdgeXFoundry) - Deployment yaml files to be part of K8S plugin (uploaded manually) | ramamani yeleswarapu | |
K8S Plugin implementation for OVN | Ritu Sood | |
SO simulator for network | ||
Testing with K8S reference deployment with OVN networking (using EdgeXFoundry) | ||
Testing with K8S reference deployment with OVN with VM and containers having multiple interfaces | ||
K8S plugin - Artifact distribution Client to receive artifacts from SDC (Mandatory - On demand artifact download, pro-active storage is stretch goal) | ||
Above test scenario without harcoding yaml files in K8S |
plugin | ||
K8s plugin - Download Kube Config file form AAI and use it to authenticate/operate with a Kubernetes cluster | Shashank Kumar Shankar | |
K8s plugin - Add an endpoint to render Swagger file | Shashank Kumar Shankar |
Note: Once above list is decided, appropriate JIRA stories will be created.
...
Role | First Name Last Name | Linux Foundation ID | Email Address | Location |
---|---|---|---|---|
committer | electrocucaracha | victor.morale@intelmorales@intel.com | PT(pacific time zone) | |
contributors | munish agarwal | Munish.Agarwal@ericsson.com | ||
Ritu Sood | ritusood | ritu.sood@intel.com | PT(pacific time zone) | |
Shashank Kumar Shankar | shashank.kumar.shankar@intel.com | PT(pacific time zone) | ||
ramamani yeleswarapuKiran Kamineni | ramamani.yeleswarapu@intel.com | PT(pacific time zone) | ||
Kiran Kamineni | kiran.k.kamineni@intel.com | PT(pacific time zone) | ||
Bin Hu | bh526r | bh526r@att.com | ||
libo zhu | ||||
Manjeet Singh Bhatia | manjeets | manjeet.s.bhatia@intel.com | PT(pacific time zone) | |
Phuoc Hoang | hoangphuocbk | phuoc.hc@dcn.ssu.ac.kr | ||
Mohamed ElSerngawy | melserngawy | mohamed.elserngawy@kontron.com | EST | |
Komer Poodari | kpoodari | kpoodari@berkeley.edu | PST | |
ramki krishnan | ramkri123 | ramki krishnan | PST | |
Interested (will attend my first on 20180206) - part of oom and logging projects | michaelobrien | frank.obrien@amdocs.com | EST (GMT-5) | |
View file | ||||
---|---|---|---|---|
|