Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Networking Plugin

The Networking Plugin has the ability to create, delete, query and update virtual networks. This will implement API's like CreateVL, DeleteVL, QueryVL and UpdateVL. Networking plugin on initialization will call discovery function to find out about the type of networking plugin available. It'll load the required plugin and call init functions of the appropriate plugin.

CreateVL:

Input: Name of the Virtual Network, Subnet IP, Gateway IP

Output: Success/Failure

  • Check in the database if a virtual network with same name already exists. If so return error.
  • Get the networking artifact.
  • Figure out the networking plugin to call
  • Call the appropriate plugin to initialize virtual network.
  • If success returned then add the Virtual network to the database
  • Return success

Create VL for OVN:

Input: Name of the Virtual Network, Subnet IP, Gateway IP

Output: Success/Failure

  • Figure out if the virtual network already exists. Use the ovn-nbctl call to figure that out. If already exist skip next step.
  • Create Logical switch with name as provided in input and  other-config:subnet=<Subnet-IP> set to the subnet required for the virtual network and external-ids:gateway_ip=<Gateway-IP> set to the gateway IP for the virtual network.
  • Check if the virtual network is attached to the distributed router if not attach virtual network to the distributed router.
  • Return success if initialization is successful

Multus Integration

One of the requirements for VNF's  is to support multiple virtual network interfaces and multiple IP addresses. Multus acts as a Multi plugin in Kubernetes and provides the multiple network interface support in a pod. https://github.com/intel/multus-cni. It'll be used in this project to provide a default management port based on Flannel to all VNF's. The other interfaces will all be based on ovn-kubernetes as discussed in the next section.

CNI configuration

Multus is configured to have default network as Flannel:

{

"type": "multus",
"kubeconfig": "/etc/kubernetes/admin.conf",
"delegates": [
   {
         "type": "flannel",
         "masterplugin": true,
          "delegate": {
              "isDefaultGateway": true
           }
    }
]

}

Create following network resource for OVN.

OVN network resources in Kubernetes:

apiVersion: "kubernetes.cni.cncf.io/v1"
kind: Network
metadata:
name: ovn-network
spec:
config: '{
"name": "ovn-kubernetes",
"type": "ovn-k8s-cni-overlay"
}'

With this setup a Pod can be annotated as below for OVN:

apiVersion: v1
kind: Pod
metadata:
  name: pod-ovn
  annotations:
     kubernetes.v1.cni.cncf.io/networks: '[
                { "name": "ovn-network", "interfaceRequest": "eth1"}
      ]'
spec: # specification of the pod's contents
containers:
     - name: pod-ovn
      image: "busybox"
      command: ["top"]
      stdin: true
      tty: true

With this setup and with above pod definition a Pod with two interfaces is created. This has a limitation though. The OVN interfaces always belongs to the subnet configured during initialization.

OPEN: To get above pod configuration to work ovn-kubernetes had to be modified and AddRoute for the Pod had to be removed. 

Ovn-kubernetes design and changes for multiple interface support

  • ovn-kubernetes current design doesn't support multiple interfaces and also a single default network is created at the time initialization time and all pods are connected to that.
  • Currently if a Pod is annotated with "ovn" then static IP, MAC can be assigned for the single interface that is created. And if the pod is not annotated with "ovn" then the ovn watcher annotates the pod with the "ovn" with dynamic address allocation. This information is then used by OVN CNI plugin to assign address for the interface. For backward compatibility this behavior will not change and pods can be created with single interface as before. The one interface is attached to a default network created at the time initialization time.
  • To create multiple interface the pods or to attach single interface to a different virtual network a new annotation is added to the Pods - "ovnNetwork". If "ovnNetwork" annotation is present then the "ovn " annotation is ignored.
  • Assumption CreateVL call is already made prior pod getting created with the virtual network needed for new Pod initialization.
  • To create a pod with multiple interfaces annotate the pod like below:

{ "name": "ovn-ls-25", "interface": "net0" },

{ "name": "ovn-ls-26", "interface": "net1", "ip_address":"172.16.26.3", "mac_address":"0a:00:00:00:00:15" }

        In this example net0 interface will be connected to a "ovn-ls-25" network and dynamic address allocation will be done for the addresses. net1 is connected to the ovn-ls-26 network and static address is used as specified.

    • "name": Virtual network name, used to connect interface to network
    • "interface": Name of the interface. Assumption: Current 10 interfaces are supported. All interfaces should be named with alphanumeric characters with the last character being a number between 0-9. This is required as this number is used to distinguish between interfaces within the pod namespace.
    • Ip_address: static ip. Optional if not given dynamically assigned
    • mac_address: static mac. Optional if not given dynamically assigned
  • ovn-kubernetes watcher based on the "ovnNetwork" annotation connects the interfaces to the right virtual network and creates a list of interfaces and corresponding addresses for the CNI to assign addresses to the newly created Pods.  It annotates the pod with the list "ovnIfaceList".

 For example:  ovnIfaceList=[{"ip_address":"172.16.25.3", "mac_address":"0a:00:00:00:00:24", "gateway_ip": "172.16.25.1"}, {"ip_address":"172.16.26.3", "mac_address":"0a:00:00:00:00:15", "gateway_ip": "172.16.26.1"}]


  • No labels