Background

ONAP is a set of projects. It is unlikely that ONAP will be deployed in its entirety by customers.  It is envisaged that there could be multiple profiles, with each profile satisfying a set of deployments.  A given ONAP profile may not require all projects and also it may not require all Microservices in the chosen projects. 

In this document, we are defining one profile - ONAP4K8S.

Why ONAP4K8S?

Akraino ICN BP family (https://wiki.akraino.org/pages/viewpage.action?pageId=11995140) has chosen ONAP for orchestrating workloads across multiple edge locations.  ICN BP addresses the edge locations with K8S resource orchestrator, that is ICN BP is not used in cases where Openstack or non-K8S based resource orchestrators are used.  Keeping this in mind, ICN is requesting bare-minimum ONAP that is required to deploy workloads in K8S regions.

Many Enterprises are adopting K8S to deploy workloads in their local data centers/edge locations.  Many feel that ONAP asis can be a challenging to install and maintain.  Also concerned about security challenges associated with the code that is unused.  The second challenge is the amount of memory and CPU power it requires to run the entire ONAP.   Since, many components of ONAP are not required, it is felt that a profile of ONAP would be good.  Hence ONAP4K8S.

ONAP4K8S requirements 

Based on ICN requirements and talking to few Enterprise customers, following are the requirements for ONAP4K8S

• ONAP4K8S to contain Microservies that are required for K8S based workload deployments.  

• ONAP4K8S shall not have Microservices that are not used.

• ONAP4K8S shall provide a way to onboard resource bundles, applications consisting of multiple resource bundles.

• ONAP4K8S shall use cloud native open source projects for infrastructure

  • fluentD for logging.

  • Jaeger for tracing

  • ISTIO/Envoy for service mesh 

• ONAP4K8S shall maintain security of passwords and private keys.

• ONAP4K8S shall provide 'Role Based Access Control' for all operations.

• ONAP4K8S shall scale-out.

• ONAP4K8S shall use distributed databases 

• ONAP4K8S should have simple UI to onboard, instantiate, terminate and provide Day2 configuration

ONAP4K8S package

Keeping the above requirements in mind, current thinking is to create ONAP4K8S package with the following containers

From ONAP:

• Multi-Cloud K8S Service

• CSM MicroServices

  • SMS

    • SMS Microservice

    • SMS Quorumclient Service

    • Vault Service

    • Consul Service

  • CA key distribution services dist-center service

  • TPM Services - abrmd Service and testca service  AI - @Kiran,  @Pramod Raghavendra Jayathirth (Deactivated) and @Manjunath Ranganathaiah (Deactivated)

• UI Service (to be developed).

• Multi-Cluster scheduler micro-service (to be developed)

• ....

From CNCF and other open source projects:

• Vault

  • Vault is the only binary that runs in there.

• ConsulD Cluster
  
  

  • Consul Server and N number of Consul Agents

• MongoDB 

  • Mongo is the only binary that runs in the POD.

• etcD

  • List down Microservices @Former user (Deleted)

• ISTIO

  • istio-citadel

  • istio-egressgateway

  • istio-galley

  • istio-ingressgateway

  • istio-pilot

  • istio-policy

  • istio-sidecar-injector

  • istio-telemetry

• Logging (Fluentd, Elastic Search and Kibana)
  
  

  • List down Microservices @Kiran

• Jaeger

  • jaeger-agent

  • jaeger-collector

  • jaeger-query

ONAP4K8S's Projects and Repositories

Deliverables:

• Create ONAP4K8S helm chart (Figure out how OOM can be used to do this. If not, may need to go with its own set of helm charts)

• Ensure that ONAP4K8S package can be used to instantiate vFW and EdgeX applications.