Overview
In its early releases, ONAP DCAE deployed all data collection and analysis components into a single Kubernetes cluster in a single central site. Since some operators will use ONAP to deploy network functions at multiple geographically distinct sites, and since it will often make sense to deploy DCAE data collection and analysis components close to the network functions the tools are monitoring, it will necessary for DCAE to be able to deploy components to multiple Kubernetes clusters at multiple sites.
Several things are needed to support deployment of DCAE components to remote sites.
- DCAE deploys components using blueprints that are processed by the Cloudify Manager orchestration tools. The blueprints must provide a way to specify the target site for a deployment. (Typically the site will be set at the time of deployment using an input to the blueprint, rather than being hardcoded into the blueprint.)
- The DCAE Kubernetes plugin that Cloudify Manager invokes must be able to extract the target site from a blueprint and obtain information about the Kubernetes cluster at the target site (such as the address of the Kubernetes API server and the credentials needed to access the API server).
- Because we are not deploying separate, independent instances of the DCAE platform into each site, DCAE components running in remote locations will need a way to access services running at the central site. These include the config binding service, which provides components with their configurations, and, in some scenarios, the Consul server and the DMaaP DR and MR servers.