CNCF Aims to Make Container Network Interface a Standard
Container networking standards were advanced today following a unanimous decision by the Cloud Native Computing Foundation (CNCF) to accept the Container Networking Interface (CNI) as one of the 10 container projects the consortium is committed to developing.
Ken Owens, Cisco Systems CTO and Technical Oversight Committee project sponsor, says CNI describes a common interface between the network plugins and container execution. It is concerned only with network connectivity of containers and reclaiming allocated resources when the container is deleted.
Originally proposed by CoreOS, CNI has evolved as an open-source project to the point where it is now employed as part of Red Hat OpenShift, Apache Mesos, Cloud Foundry, Kubernetes, Kurma and rkt. Companies that already make use of CNI within their IT environments include Ticketmaster, Concur, CDK Global and BMW.
The three CNI components include a CNI specification that defines an API between runtimes and network plugins to set up a container network setup, a series of plug-ins that address various uses cases and a library of code written in the Go programming language that developers can embed in their applications. Owens says CNCF expects vendors and IT organizations to develop plug-ins by making use of schema defined in JSON.
Longer term, Owens says the CNCF will next move to address issues surrounding the ability to implement policies across container networks as well as higher-level services such as load balancing.
Owens says CNI is crucial to driving adoption of container networking in enterprise IT organizations that value standards. Most of those organizations tend to be rather conservative when it comes to deploying emerging technologies in a production environment that might lock them in to a specific vendor. CNI, Owens says, should make it possible to either extend existing network services to support containers or allow organizations to confidently deploy a new networking platform without worrying about getting locked in to a specific vendor or technology platform.
The goal, says Owens, is to make container networking transparent to developers. At the same time, organizations should not ignore the physical network underlay on which container networking overlays depend, he notes. If there’s an issue with a router or switch, for example, IT organizations will need to have enough working knowledge of the underlay to address those issues.
Of course, conspicuously absent from the list of CNI backers is Docker Inc. While conversations between CNCF and Docker Inc. are ongoing, there’s no immediate indication that Docker Inc. will embrace CNI yet. But under the leadership of newly appointed CEO Steve Singh, Docker Inc. has signaled its intention to be more accommodating to rival container technologies.
Naturally, it remains to be seen just how container networking standards will play out. But given the amount of support for CNI within the same consortium responsible for driving adoption of the Kubernetes containers orchestration engine, there’s no doubt that an interface that has the backing of CNCF is likely to play a significant role in determining how those standards finally come about.
