As discussion of standardization continues to sweep the container community, it has also extended into the networking space for containers. One effort in this realm is the Container Network Interface (CNI), initially launched by CoreOS.
Behera noted that CNI’s flexibility is a boon when compared to libnetwork, Docker’s own networking interface. “Libnetwork is sort of a life cycle model, or more of an overlay model around bridging technology together. It’s not as familiar with network administrators or in my opinion, developers,” said Owens. “If I look at CNI, it’s very similar to the way I would expect networking to work. It’s very easy, and a logical fit for network administrators.”
“The big difference between container network interface and the container networking model is that CNI is very agnostic to implementation technology. It hosts local specifications of an API, and where the rubber meets the road, is on every host. CNI is very un-opinionated, and is supported by a variety of vendors,” Behera said.
Abstracting this complexity out of the equation is something that Owens hopes CNI continues to focus on, highlighting that, “My view has always been developers just want to have the network do what the network needs to do, to allow ports to communicate to other services available. I don’t think you want your developers thinking about networking when they’re supposed to be working on applications.”
“The ability to do multiple types of orchestration, multiples types of networking, and get plugins up and running quickly: All those components together make a very strong case to look at CNI as the starting point for basic networking,” Owens said.