k-vswitch / k-vswitch Goto Github PK

Current set of OpenFlow rules accounts for both local and remote arp traffic. The good thing here is that there's no ARP broadcast as long as we capture this traffic via OpenFlow. An even better optimization would be to implement a local ARP proxy/responder so remote ARP is not necessary.

Basically, since k-vswitch is based on Open-vSwitch, sFlow support comes for free. We still need to configure sFlow parameters and expose it in the vSwitch config so it can be picked up later during bootstrap.

Some unit tests for syncFlows() would be nice. One approach is to create a kubernetes fake client, generate the resources we are watching for (vswitchconfig, pods and network policies) and validate that the flows buffer that would be passed into ovs-ofctl replace-flows. It doesn't actually validate that the flows are configured properly but I think it's still a good improvement from what we have now.

Currently we create a node-local internal port for local pod subnet traffic, it would be simpler to assign the local pod subnet directly on the OVS bridge instead.

cc @zanetworker

Like most CNI plugins, k-vswitch is creating a veth pair with the given network namespace and attaching one end of the veth pair to the OVS bridge. A possible performance optimization would be to have each pod network namespace behind an OVS internal port rather than a veth pair, possibly less overhead on the kernel.

OVS has Windows support and in Kubernetes v1.14, Windows support went GA. k-vswitch, if possible, should also have Windows support as a Kubernetes CNI.

In #10 as part of implementing ARP responder we had to duplicate the code from github.com/containernetworking/plugins which was responsible for creating the veth pair. This is ok for now but we should consider ways to get rid of this duplicated code