...
Gap Analysis for Integrating OpenNESS with ICN
Network Policy
Background
Network policy and DNS is used in OpenNESS for traffic steering. Network policy is used for restrict access among services but NOT “proactively” forward the traffic, While the OpenNESS DNS service can help “redirect” the external client’s traffic to the edge application service。
By default, in a Network Edge environment, all ingress traffic is blocked (services running inside of deployed applications are not reachable) and all egress traffic is enabled (pods are able to reach the internet). The following NetworkPolicy definition is used:
...
2. Create the Network Policy:
kubectl apply -f network_policy.yml
Cross-Node communication
Background
Edge apps can be divided into producer and consumer. This gap analysis is to investigate the communication between the producers and consumers which are on different edge nodes.
Edge applications must introduce themselves to OpenNESS framework and identify if they would like to activate new edge services or consume an existing service. Edge Application Agent (EAA) component is the handler of all the edge applications hosted by the OpenNESS edge node and acts as their point-of-contact.
...
For example:
producer1 is located in node1 and consumer2 is located on node2. The networking flow will be:
producer1 -> service eaa -> pod eaa
consumer2 -> service eaa -> pod eaa
node1 node2
eaa
producer1 consumer2
OS (Ubuntu)
Background
OpenNESS only supports Centos but ICN is based on Ubuntu 18.04. This gap analysis is to investigate how to deploy OpenNESS on Ubuntu 18.04
OpenNESS only supports Centos but ICN is based on Ubuntu 18.04. By changing the ansible scripts of OpenNESS, it is able to deploy OpenNESS on Ubuntu 18.04. The following parts of ansible scripts need to change:
1. Following ansible roles can be removed for OpenNESS master: grub, cnca, multus, nfd. Ansible role grub can be removed for OpenNESS node. Because:
...