I've been a big fan of ipvlan since it was added to the kernel[1] mainly for the reasons you've outlined and the overall reduction in complexity compared to bri

I've been a big fan of ipvlan since it was added to the kernel[1] mainly for the reasons you've outlined and the overall reduction in complexity compared to bridges and overlay networks. It should also be noted that ipvlan offers a bit of an improvement over macvlan because ipvlan also works in places where L2 is not an option (i.e cloud providers). In the post you mentioned one of the drawbacks to adopting ipvlan was the lack of tooling to manage it. To address this issue, and a few others[2], Kubernetes has recently adopted the Container Network Interface(CNI)[3] standard as the solution for managing network plugins in Kubernetes. CNI ships with a few plugins including ipvlan and, maybe more importantly, the ability to allocate and manage IP addresses[4]. Over time CNI should give Kubernetes the flexibility to work well with multiple container runtimes including Docker and rkt, while allowing third party solutions to fill in the gaps around networking. [1] https://www.kernel.org/doc/Documentation/networking/ipvlan.txt https://www.kernel.org/doc/Documentation/networking/ipvlan.t... [2] http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-... [3] https://github.com/appc/cni/blob/master/SPEC.md https://github.com/appc/cni/blob/master/SPEC.md [4] https://github.com/appc/cni/blob/master/SPEC.md#ip-allocation https://github.com/appc/cni/blob/master/SPEC.md#ip-allocatio...