Why Google Won’t Support Docker’s Container Network Model
Google jumped into the container management game last year with the release of Kubernetes v1.0 last July. Kubernetes [koo-bur-net-eeze], is “an open source container cluster manager [that] aims to provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts.”
Along with the Kubernetes release, Google announced its partnership with the Linux Foundation to form the Cloud Native Computing Foundation (CNCF) and offered Kubernetes as a seed technology.
So, then, why is Google’s Kubernetes shunning Docker’s Container Network Model (CNM), Docker’s approach to providing container networking with support for multiple network drivers.
After all,” wrote Tim Hockin, Software Engineer at Google, “vendors will almost certainly be writing plugins for Docker — we would all be better off using the same drivers, right?”
Well, Google would, but it turns out that there are fundamental differences in the design of Docker’s network drivers that don’t play well with Kubernetes.
Hockin breaks down the multiple reasons in detail in a recent blog post. The short version: At their core, the two systems are different in structure, making it complicated to get them to talk to each other. Which is the antithesis of the container’s philosophy of ease of use?
“Kubernetes supports multiple container runtimes, of which Docker is just one,” Hockin explained, “Configuring networking is a facet of each runtime, so when people ask “will Kubernetes support CNM?” what they really mean is “will Kubernetes support CNM drivers with the Docker runtime?”
Google engineers worked with the libkv interface used by Docker but found libkv wasn’t compatible with the structure of Kubernetes.
Hockin discusses several technical solutions for solving these problems, but none was found to solve the issues in a satisfying way. They even tried writing plugins for Dockers plugins to get the platforms to work together, but there is too much of a philosophical difference between the Kubrenetes and Docker’s underlying structure to make this workable. At the end of the day, why shoehorn a multi-container runtime solution into a single runtime solution?
Google engineers have, instead, focused on CoreOS’s Container Network Interface (CNI) model and part of the App Container (appc) specification.
There will be some unfortunate side-effects of this,” acknowledged Hockin. “In particular, containers started by Docker run might not be able to communicate with containers started by Kubernetes, and network integrators will have to provide CNI drivers if they want to fully integrate with Kubernetes.
On the upside, focusing on the multi-container runtime solution, Kubernetes will enable the engineers to streamline the system, making it more flexible and simpler to use.
Are you frustrated by Google’s lack of compatibility with Docker? Google engineers are continually looking for ways to integrate and simplify Kubernetes.
“If you have thoughts on how we can do that,” wrote Hockin, “we really would like to hear [your ideas] — find us on slack or on our network SIG mailing list.”
Your move.
Docker is a sponsor of The New Stack.
Feature image by Ryan McGuire, licensed under CC0.
