Basic OVS CNI plugin implementation

[phoracek]

With this initial implementation, ovs-cni would just connect container to an OVS bridge available on host and optionally assign connection port to a VLAN. Support for IPAM and other advanced features will be added later and described in separate issues. Pure L2 plugins sounds limiting, but it should be enough for KubeVirt VMs use-case.

This basic support should reflect bridge plugin from containernetworking/plugins. Code must have unit tests coverage, reasonable logging and standalone usage examples and usage example for local cluster.

Open vSwitch CNI Plugin

Overview

With ovs plugin, containers (on the same host) are plugged into an Open vSwitch bridge (virtual switch) that resides in the host network namespace. It's host adminitrator's responsibility to create such bridge and optinally connect it to broader network, be it using L2 directly, NAT or an overlay. The containers receive one end of the veth pair with the other end connected to the bridge.

Example configuration

{
    "name": "mynet",
    "type": "ovs",
    "bridge": "mynet0",
    "vlan": 100
}

Network configuration reference

• name (string, required): the name of the network.
• type (string, required): "ovs".
• bridge (string, required): name of the bridge to use.
• vlan (integer, optional): VLAN ID of attached port. Opened for all if not specified.

[phoracek]

@SchSeba @yuvalif @dankenigsberg could you check this? Thanks

[phoracek]

There is also an option not to use veth, but rather OVS internal interfaces. AFAIK they are faster but don't support all traffic shaping features. The problem is, that it would be created by OVS in host network namespace - therefore we would need to give it a random name and only then move it to container netns and rename.

[phoracek]

Looking for OVSDB client with nice abstraction in Go. I found several libraries that expose ovsdb directly, that means communicating directly with OVS database and making sure all references between objects (ports, interfaces, bridges) are consistent, that is a lot of extra work. DigitalOcean library has nice OVS abstraction (single command to add bridge, ports, set attribute etc.), but that is implemented on top ovs ovs-vsctl command line tool. Therefore, in the intial PR, I will call the ovs-vsctl command directly.

[dankenigsberg]

If there is no high-level Go binding for OvS, how about implementing this CNI in Python, using ovsdbapp?
(I am not completely joking here!)

[phoracek]

@dankenigsberg it would have other problems:

• packaging and shipping of extra dependencies
• no that many examples of existing CNI plugins (although there are some)
• we will not be able to use containernetworking cni and plugins repositories and their helpers to build and test CNI
• general acceptance (at least for me, Python plugin does not look that appealing)

There are not many calls to ovs-vsctl in the code. It should not be that hard to rewrite them to pure ovsdb calls if we decide to.

[dankenigsberg]

Yeah, yeah. That's why I was /mostly/ joking.