OpenNESS 19.12 Design
Openness released 19.12 on December 21 2019 and this new release has removed the deployment mode ( kubernetes + NTS ). Two modes is supported now: Native deployment Mode (which is based on pure docker/libvirt) and Infrastructure Mode (which is based on kube-ovn), below are the brief summary of the difference of these 2 modes:
Functionality | Native Deployment Mode | Infrastructure Deployment Mode |
Usage Scenarios | On-Premises Edge | Network Edge |
Infrastructure | Virtualization base: docker/libvirt Orchestration: OpenNESS controller Network: docker network (container) + NTS (through new added KNI interface) | Orchestration: Kubernetes Network: kube-ovn CNI |
Micro-Services in OpenNESS Controller | Web UI: controller UI Edge Node/Edge application lifecycle management Core Network Configuration Telemetry | Core Network Configuration: Configure the access network (e.g., LTE/CUPS, 5G) control plane Telemetry |
Micro-Services in OpenNESS Node | EAA: application/service registration, authentication etc. ELA/EVA/EDA: used by controller to configure host interfaces, network policy (used by NTS), create/destroy application etc. DNS: for client to access MS in edge node NTS: traffic steering | EAA: application/service registration, authentication etc. EIS(Edge Interface Service), looks to be similar with providernet implemented in ovs4nfv k8s CNI DNS: for client to access MS in edge node |
Application on-boarding | OpenNESS Controller Web UI or Restful API | Kubernetes (e.g. Kubectl apply -f application.yaml) Note: unlike 19.09, No UI used to on-board application |
Edge node interface configuration | ELA (Edge LifeCycle Agent, Implemented by OpenNESS) – Configurated by OpenNESS controller | EIS (Edge Interface Service, which is an kubectl extension to configurate edge node host network adapter), use
e.g. kubectl interfaceservice attach $NODE_NAME $PCI_ADDRESS |
Traffic Policy configuration | EDA (Edge Dataplane Agent, Implemented by OpenNESS) – Configurated by OpenNESS controller | Kubenetes Network Policy CRD
e.g. kubectl apply -f network_policy.yml Note: unlike 19.09, No UI used to configure policy |
DataPlane Service | NTS (Implemented based on DPDK in OpenNESS) to provide additional KNI interface for container | kube-ovn + Network policy |
Gap Analysis for Integration OpenNESS with ICN
Network Policy
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:
apiVersion: networking.k8s.io/v1 metadata: name: block-all-ingress namespace: default # selects default namespace spec: podSelector: {} # matches all the pods in the default namespace policyTypes: - Ingress ingress: [] # no rules allowing ingress traffic = ingress blocked
Admin can enable access to certain service by applying a NetworkPolicy CRD. For example:
1. To deploy a Network Policy allowing ingress traffic on port 5000 (tcp and udp) from 192.168.1.0/24 network to OpenVINO consumer application pod, create the following specification file for this Network Policy:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: openvino-policy namespace: default spec: podSelector: matchLabels: name: openvino-cons-app policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 192.168.1.0/24 ports: - protocol: TCP port: 5000 - protocol: UDP port: 5000
2. Create the Network Policy:
kubectl apply -f network_policy.yml
Cross-Node communication
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.
OpenNESS-awareness involves (a) authentication, (b) service activation/deactivation, (c) service discovery, (d) service subscription, and (e) Websocket connection establishment. The Websocket connection retains a channel for EAA for notification forwarding to pre-subscribed consumer applications. Notifications are generated by "producer" edge applications and absorbed by "consumer" edge applications.
The sequence of operations for the producer application:
- Authenticate with OpenNESS edge node
- Activate new service and include the list of notifications involved
- Send notifications to OpenNESS edge node according to business logic
The sequence of operations for the consumer application:
- Authenticate with OpenNESS edge node
- Discover the available services on OpenNESS edge platform
- Subscribe to services of interest and listen for notifications
Edge apps will access eaa through eaa.openness (name.namespace) which is a kubernetes service:
https://github.com/open-ness/edgecontroller/blob/master/kube-ovn/openness.yaml#L18
For example: as following links show, openvino consumer will access http://eaa.openness:443/auth for authentication.
https://github.com/open-ness/edgeapps/blob/master/openvino/consumer/cmd/main.go#L24
https://github.com/open-ness/edgeapps/blob/master/openvino/consumer/cmd/main.go#L66
eaa is deployed as a deployment and only 1 eaa will be deployed:
https://github.com/open-ness/edgecontroller/blob/master/kube-ovn/openness.yaml#L41
Because all edge apps will access only 1 eaa, it doesn't matter that eaa is stateful.
For example:
only 1 eaa is deployed on node1. producer1 and producer2 will activate the new service with eaa. consumer1 and consumer2 will consume services stored in eaa. Because all the information are stored in only 1 eaa, there won't be issues.
node1 node2
eaa
producer1 consumer1 producer2 consumer2
Because edge apps on different edge node all can access service eaa, the consumer can consume the service provided by producer which is on a different node.
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