| Table of Contents |
|---|
...
| Microservices of Openness Infrastructure mode | Description | Deployment method | Deployment of the component | Propose to integrate |
|---|---|---|---|---|
| eaa | application/service registration, authentication etc | deployment | edge node | yes |
| edgedns | for client to access microservices in edge node | daemonset (propose to change to deployment) | edge node | yes |
| interfaceservice | similar with providernet implemented in ovn4nfv-k8s-plugin | daemonset | edge node | no, will use ovn4nfv-k8s-plugin's provider network |
| cnca | Core Network Configuration: Configure the access network (e.g., LTE/CUPS, 5G) control plane | deployment | controller | no |
| syslog | log service for openness | daemonset | controller & edge node | no |
| multus | enabling attaching multiple network interfaces to pods | daemonset | controller & edge node | Already covered by ONAP4K8s - KUD |
| nfd | node feature discovery | daemonset | controller & edge node | Already covered by ONAP4K8s - KUD |
| sriov | sriov network device plugin & sriov cni | daemonset | controller & edge node | Already covered by ONAP4K8s - KUD |
| topology manager | kubernetes topology manager | Kubelet component | controller & edge node | Work in Progress to upgrade the K8s v16.0 integrate into ONAP4K8s - KUD |
| CMK | CPU Manager | part of kubelet | controller & edge node | Work in Progress - Integrate into ONAP4K8s - KUD |
| bios | Used for change BIOS and firmware configuration: CPU configuration, Cache and Memory configuration, PCIe Configuration, Power and Performance configuration, etc | privileged Pod | controller & edge node | Required for ICN? Already in ICN Metal3, could be enabled part of it |
| fpga | Open Programmable Acceleration Engine (OPAE) package consisting of a kernel driver and user space FPGA utils package that enables programming of the FPGA is used. sriov is used to configure the FPGA resources such as Virtual Functions and queues | pod | controller & edge node | Need to integrate into ONAP4K8s - KUD with FPGA device |
...
- 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.
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.
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.
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.