Introduction:

Table of Contents

Nodus is the Network controller designed based on the K8s controller framework and provides Open flow control based on OVN. This address OVN based Multiple Network creation, support Multiple network interfaces and support Virtual networking and Provider networkings.

Problem statement:

Application transformation is one of the major objectives in the edge computing in the cloud-native evolution. Taking a PNF(Physical Network Function) or a VNF(Virtual Network Functions) to be ready to deploy in the edge is as challenging because the NFs(Network Functions) are composited into smaller microservices and these microservers will be deployed in the multiple edge location. Controlling the network traffics such as both control plane and data plane traffics in the scenarios is required to achieve low latency and multiple clusters networking

Solution:

Adding Multi cluster networking is a challenging requirement for Edge networking in the cloud-native world. As Kubernetes delegates all the networking features to CNI(Container Network Interfaces), and right now we have 16+ CNI types that offer various networking features starting from localhost to BGP networking. Having a single network controller for the Multiple Cluster within an edge and also across geo-distributed edge location is a requirement to create a virtual network, provider networks across the edges, and apply the same tuning parameter for the network resources in the edges.

...

Nodus is designed to address all the challenges. We designed the very thin layer of CNI shim that development to maintain the CNI framework and all the networking complexity such as Multiple networking, handling the infinite network resouces and finite network resources are moved in a single network controller.

Features:

InFinite Network Resources:

Virtual Networks: 

Nodus uses the NFN operator to define the virtual network CRs that will create a OVN networking for virtual networking as defined in the CR.

...

This CR defines the OVN networking and provides the gateway and exclude IPs to be reserved for any internal static IP address assignment.

Provider Networks:

Provider network supports both VLAN and direct provider networking

...

apiVersion: k8s.plugin.opnfv.org/v1alpha1
kind: ProviderNetwork
metadata:
  name: directpnetwork
spec:
  cniType: ovn4nfv
  ipv4Subnets:
  - subnet: 172.16.34.0/24
    name: subnet2
    gateway: 172.16.34.1/24
    excludeIps: 172.16.34.2 172.16.34.5..172.16.34.10
  providerNetType: DIRECT
  direct:
    providerInterfaceName: eth1.
    directNodeSelector: specific
    nodeLabelList:
    - kubernetes.io/hostname=ubuntu18

Service Function Chaining:

apiVersion:  k8splugin.opnfv.org/v1alpha1
kind: NetworkChaining
metadata:
  name: chain1
  namespace: vFW
spec:
  type: Routing
  routingSpec:
    leftNetwork:
      - networkName: ovn-provider1
        gatewayIP: 10.1.5.1
        subnet: 10.1.5.0/24
    rightNetwork:
      - networkName: ovn-provider1
        gatewayIP: 10.1.10.1
        subnet: default
    networkChain: app=slb, ovn-net1, app=ngfw, ovn-net2, app=sdwancnf

Finite network Resources:

SRIOV Overlay Networks:

Required features in SRIOV Overlay networking:

• Currently, OVN4NFV by default create the Veth pair interfaces for all interfaces.
• SRIOV Overlay networks introduce a feature to include the interfaceType in the OVN networking and provide the deviceplugin sock name and targets on the devices only having SRIOV hardware-enabled labels

SRIOV Type Virtual network

apiVersion: k8splugin.opnfv.org/v1alpha1
kind: Network
metadata:
  name: ovn-sriov-net
spec:
  cniType: ovn4nfv
  ipv4subnets:
  - subnet: 172.16.33.0/24
    name: subnet1
    gateway: 172.16.33.1/24
    excludeIps: 172.16.33.2 172.16.33.5..172.16.33.10
    NodeSelector: specific
    nodeLabelList:
    - feature.node.kubernetes.io/network-sriov.capable=true
    - feature.node.kubernetes.io/custom-xl710.present=true

SRIOV Type provider network

apiVersion: k8s.plugin.opnfv.org/v1alpha1
kind: ProviderNetwork
metadata:
  name: ovn-sriov-vlan-pnetwork
spec:
  cniType: ovn4nfv
  interface:
  - Type:sriov
    deviceName: intel.com/intel_sriov_700
  ipv4Subnets:
  - subnet: 172.16.33.0/24
    name: subnet1
    gateway: 172.16.33.1/24
    excludeIps: 172.16.33.2 172.16.33.5..172.16.33.10
  providerNetType: VLAN
  vlan:
    vlanId: "100"
    providerInterfaceName: eth0
    logicalInterfaceName: eth0.100
    vlanNodeSelector: specific
    nodeLabelList:
    - feature.node.kubernetes.io/network-sriov.capable=true
    - feature.node.kubernetes.io/custom-xl710.present=true

SRIOV Type Direct network

apiVersion: k8s.plugin.opnfv.org/v1alpha1
kind: ProviderNetwork
metadata:
  name: ovn-sriov-direct-pnetwork
spec:
  cniType: ovn4nfv
  interface:
  - Type:sriov
    deviceName: intel.com/intel_sriov_700
  ipv4Subnets:
  - subnet: 172.16.34.0/24
    name: subnet2
    gateway: 172.16.34.1/24
    excludeIps: 172.16.34.2 172.16.34.5..172.16.34.10
  providerNetType: DIRECT
  direct:
    providerInterfaceName: enp
    directNodeSelector: specific
    nodeLabelList:
    - feature.node.kubernetes.io/network-sriov.capable=true
    - feature.node.kubernetes.io/custom-xl710.present=true

Parameter definition:

interface - Define the type of sriov interface to be created.

...

1. Admission controller should be part of NFN operator that insert the request and limit to pod spec by reading the OVN4NFV net CR.
2. This design adds the SRIOV directly into the OVN overlay for both primary and secondary networking. The development should also address the SNAT for all the interfaces

Comprehensive documentation:

Nodus

How to use?

Development

Configuration

Presentation:

October 11th 2021

Nodus slide deck:

July 19th 2021

Nodus slide deck:

March 9th 2021

OVN4NFV Slide deck:

OVN4NFV recorded Video:

October 8th 2020

OVN4NFV slide deck:

OVN4NFV Prerecorded Demo:

...