Kubernetes has historically taken a very hands-off approach to the multi-network topic. If you’re a telecom and network jockey you know the problem: Without it, pods only have one interface. When it came to solving this in Kubernetes, rather than tackling the problem, it was left for the ecosystem to solve. Thus, projects like Multus CNI, CNI Genie and DANM came to be: they solved a community problem (“I want more than one interface in my pod!”) outside Kubernetes, following its API extension philosophy.

Fast forward a bunch of years: there’s a new KEP to provide an in-tree solution to multi-networking, which will allow people to express in a Kubernetes native way that their pods require more than one network.

We’re going to look at the problem from two perspectives, first a political one: What’s the community experience with working with the Kubernetes community and what kind of challenges have we faced over the years? We’ll share our stories of successes and, yes, of the failures. But because there’s only so much politics you can stomach, we’ll also look at it from the other end of the spectrum – the hands-on-a-terminal-perspective, looking directly at an implementation.

Together we’ll explore architecture and API changes for Pod interfaces as Kubernetes elements, along with a prototype implementation … in Multus CNI of all things. We invite you to participate in unifying advanced networking technology in Kubernetes.