Page History

...

• Create Ansible scripts to create building environment, build microservices' docker images and push them to docker repository
• Create helm charts to run microservice in ONAP4K8s

Application

• TBD

ICN Requirements for supporting geo-distributed producing and consuming applications

BACKGROUND

Cloud native applications usually use microservice architecture. It means the application will contain multiple micro-serivces like Figure 1. This application consists of four micro-services (μs1, μs2, μs3, μs4). And μs1 communicates with μs2, μs2 communicates with μs3 and μs3 communicates with μs4. μs1 is an user facing micro-service. μs1 and μs2 are expected to be deployed together. μs2 is stateful and hence needs to communicate with other μs2.

Image Added

Figure 1 Centralized Application

When it comes to edge computing, some micro-services will be deployed on the edge clouds and some micro-services will be deployed on the central cloud like Figure 2. μs1 and μs2 are deployed on the edge cloud. μs3 and μs4 are deployed on the central cloud. Thus the application for edge computing is geo-distributed in nature. 

Image Added

Figure 2. Distributed Application

ICN (which includes EMCO – formerly ONAP4K8s) is to show multiple clusters as one as far as the application life cycle is concerned as applications are becoming geo-distributed.  In EMCO, we have a concept called ‘Logical Cluster” which is an abstracted cluster across multiple K8s clusters as Figure 3. 

Image Added

Figure 3 Logical Cluster

REQUIREMENT

EAA provides application/service registration and authentication in openness. For now eaa only supports single cluster applications and doesn’t support geo-distributed, multi-cluster applications which are typically edge applications. To support geo-distributed applications, eaa needs to support application/service registration and authentication on different edge clouds which are kubernetes clusters in network edge. For example, 

• If creating one EAA for every tenant (logical cluster): micro-services on different edge clouds which are kubernetes clusters should be able to communicate with each other by registering the services to the EAA and consuming the services from the EAA on different edge clouds. For example, μs2 is stateful and needs to communicate with other μs2 on different edge clouds to synchronize the states.
• If creating one EAA for every kubernetes cluster: Docker image for EAA is signed by the root CA of the kubernetes cluster where EAA will be deployed as below:
  https://github.com/open-ness/edgenode/blob/master/docker-compose.yml#L77
  This will cause the certs of EAAs on different edge clouds to be on different certificate chains because different EAAs’ certs are signed by different kubernetes clusters’ root CAs. What’s more, producing application and consuming application will get certs from EAA and those certs are signed by EAA’s cert. And this will cause the producing application and consuming application on different edge cloud can’t communicate with each other because their certs are on different certificate chains. To solve this issue, the certs of EAAs should be signed by the same orchestrator. For example, ICN DCM(Distributed Cloud Manager) can take this role:
  https://wiki.onap.org/pages/viewpage.action?pageId=76875956
  And EAA should support mounting the certs when it will be deployed and not mount the certs during building docker image.