This talk will encompass a demo of a brand new CNI plugin and auxiliary components which allow you to map devices to networks, and associate your pods attachments to devices at a higher level, with more automagic, so you don’t have to baby the workload specifications at the lowest possible level, and take advantage of how Kubernetes can help you orchestrate these attachments.

You’ll learn a lot about CNI! You’ll get instructions to take home on how to get this CNI plugin running in your own lab, and it’ll give you a test bed for learning how to make your own CNI plugins too. Even if you’re not a CNI plugin developer, it’ll help you understand better what your CNI plugins are doing, and help you diagnose issues in your own Kubernetes deployment. We’ll also talk about device plugins for Kubernetes and you’ll get to learn about how device availability impacts scheduling workloads.

While this talk encourages you to get into the nitty gritty of CNI – Doug really wants to invite you to become a participant in bigger picture efforts for the Kubernetes networking community, too. There is a nascent Kubernetes-native MultiNetworking effort, the Kubernetes Network Plumbing Working Group, and upcoming work for CNI 2.0. This talk, and PoC project represents some problems that we need to solve as a community – If we don’t represent the community and what we all want – we lose out to the commercial efforts which will steamroll the community and leave our (already overtaxed!) sysadmins in the dirt. We all need common ground to work together upon, and it’s up to the community to set those standards and let the commercial efforts follow.

CNI is the “Container Networking Interface”, and it’s an API for setting up networking for containers, and also used by Kubernetes. We love it for its simplicity, and for the fact that it’s a common ground for networking in Kubernetes, and we already know, container networking isn’t always easy. What you might not know is that CNI itself is “container orchestration engine agnostic.” For a 1.0, this limitation makes sense, and we need to respect the origins of this thinking, and it allows some overarching constructs that are useful for both orchestration engines, and container runtimes (like crio and containerd), but we need a step forward in terms of Kubernetes given how ubiquitous it’s become, and continues to become in the networking space.

Doug believes that we need an evolution, or potentially, a revolution for CNI 2.0. One that gives us a layer to speak to CNI using Kubernetes. If we don’t have this pathway, it encourages developers to ignore CNI and build their own Rube Goldberg machine, and sysadmins have already had to chase the rolling ball down the chute to light the match to drop the mousetrap enough as it is. We need standards, not contraptions!