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.
In the Dublin release, we are providing an interim solution for remote deployment that requires no development outside of the DCAE project. Ideally, there would be an ONAP-wide approach to support multiple sites, including a mechanism for bringing up new clusters and adding information about them to an ONAP-wide data store. We do not have this in Dublin–instead, DCAE keeps its own store of data about remote Kubernetes clusters.
In Dublin, we delivered the following changes into DCAE:
location_id
, that specifies the name of the site where the component should be deployed.location_id
for a component from the blueprint and to use the location_id
to find the target Kubernetes cluster and to deploy the component into the target cluster.There is more information about these changes in this presentation.
The remaining sections of this document describe how to add information to the cluster ConfigMap and how to use the Helm chart to deploy the proxy into remote sites.
The proxy server for remote sites relies on having access from the remote site to the config-binding-service server at the central site. Prior to R6, we accomplished this by configuring a NodePort service on the central site exposing the config-binding-service http port (10000) and the https (10443) port. In R6, by default, we configure a ClusterIP service for config-service-service. This prevents the http port from being exposed outside the central site Kubernetes Cluster.
In addition, R6 changed how components get certificate for TLS. In prior releases, components that needed a certificate (a server certificate or just a CA certificate to use to validate servers) got the certificate using an init container (org.onap.dcaegen2.deployments.tls-init-container, version 1.0.3) that has the certificates "baked in" to the container image. In R6, the init container (org.onap.dcaegen2.deployments.tls-init-container, version 2.1.0) executes code that pulls a certificate from AAF. This will not work from a remote site because the necessary AAF services are not exposed there. We expect that work will be done for R7 to remedy this.
In the meantime, to use a remote, it will be necessary to deploy DCAE at the central site with these changes:
We expect significant changes to multi-site support in R7.
Note that as of this update (2020-03-09), there has been no testing of multi-site support in R6.
Multisite init-container : https://git.onap.org/dcaegen2/deployments/tree/multisite-init-container/README.md
DCAE remote site setup charts : https://git.onap.org/dcaegen2/deployments/tree/dcae-remote-site