ovs networking document

Update networking.md

docs/networking.md

@@ -63,6 +63,11 @@ Docker allocates IP addresses from a bridge we create on each node, using its
 
 2. Create the user containers and specify the name of the network container as their “net” argument. Docker finds the PID of the command running in the network container and attaches to the netns of that PID.
 
+### Other networking implementation examples
+With the primary aim of providing IP-per-pod-model, other implementations exist to serve the purpose outside of GCE.
+  - [OpenVSwitch with GRE/VxLAN](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/ovs-networking.md)
+  - [Rudder](https://github.com/coreos/rudder#rudder)
+
 ## Challenges and future work
 
 ### Docker API

docs/ovs-networking.md

@@ -0,0 +1,14 @@
+# Kubernetes OpenVSwitch GRE/VxLAN networking
+
+This document describes how OpenVSwitch is used to setup networking between pods across minions.
+The tunnel type could be GRE or VxLAN. VxLAN is preferable when large scale isolation needs to be performed within the network.
+
+![ovs-networking](./ovs-networking.png "OVS Networking")
+
+The vagrant setup in Kubernetes does the following:
+
+The docker bridge is replaced with a brctl generated linux bridge (kbr0) with a 256 address space subnet. Basically, a node gets 10.244.x.0/24 subnet and docker is configured to use that bridge instead of the default docker0 bridge.
+
+Also, an OVS bridge is created(obr0) and added as a port to the kbr0 bridge. All OVS bridges across all nodes are linked with GRE tunnels. So, each node has an outgoing GRE tunnel to all other nodes. It does not need to be a complete mesh really, just meshier the better. STP (spanning tree) mode is enabled in the bridges to prevent loops.
+
+Routing rules enable any 10.244.0.0/16 target to become reachable via the OVS bridge connected with the tunnels.