ONAP and ONAP Edge Orchestration Cloud Native Proposal Mike Elliott (Amdocs) Edge Automation WG May 2019

Cloud-native ONAP Orchestration Orchestrating Analytic Applications Agenda Scope of Proposal Cloud-native ONAP Orchestration Orchestrating Analytic Applications Centralized ONAP Registry ONAP Operations Manager Dashboard

Scope of Proposal Use cloud-native technologies to deploy ONAP to Edge Clouds Use Kubernetes as Orchestrator for all Managed Applications (Includes Analytics and 3rd Party applications) We’ve been discussing layers that sit on top of kubernetes and delegate to kubernetes DCAE Controller Multi-cloud Kubernetes is the lowest common denominator

Cloud-native ONAP Orchestration ONAP is orchestrated today using Kubernetes Work underway to expand cloud-native ecosystem in ONAP: Istio, Prometheus, Envoy, Cillium/Canal (CNI), API Gateways (e.g. Kong) Orchestrating ONAP to Edge Clouds is a natural fit Leverage existing K8s and Helm capabilities No additional multi-site support required – works out-of-box DevOps processes easily integrated (CRDs, Operators, k8s plugins) to manage ONAP as per specific company requirements OOM CRDs and Operators under development now Wealth of existing Operators can be found here: https://operatorhub.io

Deploy ONAP to Central Kubernetes Cluster helm deploy onap-central release/onap -f onap-central.yaml

Helm Deployment Specification onap-central.yaml Customization of ONAP Enables and configures specific Applications for deployment Re-deploy configuration changes at any time No service interruption for Applications supporting HA (rolling upgrades/downgrades)

ONAP Edge Cloud Orchestration helm deploy onap-central release/onap -f onap-central.yaml helm deploy onap-east-us release/onap -f onap-east-us.yaml helm deploy onap-west-us release/onap -f onap-west-us.yaml 1 2 3 East US 2 Today we do #1. By natural extension, can use the exact same mechanism to orchestrate edge clouds (although not restricted to “edges” – anywhere k8s is running) West US 3 1

ONAP Edge Cloud Orchestration Advantages Customized deployment and configuration specification per cloud or same template applied across any number of clouds for scale Deploys into Independent k8s clusters (localized orchestrator) No additional layers of complexity no “Multi-site” support required East US 2 West US 3 1

Orchestrating Analytic Applications (and 3rd party)

Redundant Orchestrators Two orchestrators currently exist in ONAP Kubernetes DCAE Controller (ECOMP Controller) Kubernetes orchestrates all Management Applications except Analytic Applications DCAE Controller orchestrates Analytic Applications The proposal: Expose all ONAP Applications as Helm Charts including collectors, analytic applications, 3rd party, etc.

VES Collector as Managed Application ves-collector Helm Chart deployable like any other ONAP application helm deploy onap-east-us release/onap -f onap-east-us.yaml Consistent LCM Consistent configuration mechanism Consistent upgrade/rollback - It would now possible to choose to deploy the ves-collector like any other application, to any cloud

VES Collector Scaled Down Applications deployable in dormant state until needed Consumes zero resources until scaled up No need for dynamic just-in-time deployment deploy entire ONAP platform to edge choose applications scaled down (replicas=0) scaled down apps still available to deployed Services (VNFs) automatic scaling based on HPA no “Pet management”

VES Collector Scaling (up or down) Manual via Helm helm deploy onap-east-us-dcaegen2 release/onap --set dcaegen2.ves-collector.replicaCount=1 Programmatic via Kubernetes API When deployed takes up zero cpu or memory (spec is already stored in etc.d)

VES Collector HPA (Horizontal Pod Autoscaler) HPA defines rules to trigger automatic scaling of pods up and down HPA descriptors defined on a per Helm Chart bases Desired state – k8s orchestrator takes care of the rest Allows for “hands off” cloud native approach – no pets Manually create HPA is also possible: kubectl autoscale deployment dcaegen2-ves-collector --cpu-percent=50 --min=1 --max=10

Reduction in layers of complexity (1 orchestrator not 2) Proposal Benefits Reduction in layers of complexity (1 orchestrator not 2) Reduction in resource requirements (Footprint Optimization) Lower Barrier to Entry for new ONAP adopters complexity and huge resource requirements lowers adoption Consistency in deployment, configuration, LCM and upgrades We want less complex not more complex No new layers use the layer we have (i.e. k8s) Leave orchestration to k8s DCAE free to focus on Data Collection and Analytics Collectors, Mappers, Analytics as Managed Applications