Miguel Barroso

Creating a CNI plugin is a simple, but mostly undocumented, task. If you add plugin chaining the complexity is lofted by a layer. We’ll be getting you to where you can create your base plugin and add it to a chain, and inspect the links of that chain, the CNI result passed between each. With CNI chains each plugin depends on information created at the previous step in the chain. We’ll be relying on tools such as cnitool, dummy CNI plugins to chain and custom json configs. We'll show the tools we use every day to create a multi-step CNI plugin in a NetworkAttachmentDefinition. We’ll talk about how to use different capabilities, handle logging and writing a custom plugin in the chain. We’ll revisit concepts from the CNI spec such as prevResult and go from zero to a working multi-chain CNI plugin. We'll talk about how we architect CNI plugins to make debugging easier, and how to deploy them in a testing and production environment.

Design and implementation of dynamic network attachment for Kubernetes pods and KubeVirt VMs.

Immutable infrastructure is the law of the land in the cloud native landscape, promising benefits to software architectures run in Kubernetes. … except sometimes the rules must be broken to achieve certain use cases; take for instance the dynamic attachment of L2 networks to a running VM: to hotplug an interface into the VM running in a pod, you first need to hotplug that interface into the pod.

This feature is particularly of interest (required, actually) to enable scenarios where the workload (VM) cannot tolerate a restart, or when the workload is created prior to the network.

When thinking about strategies for tackling this problem, we faced a recurring question when trying to come up with a modular design to provide this functionality: "should the changes be located in KubeVirt, and thus solve this issue for Virtual Machines, or should we take the longer path and address this issue also for pods ?" We chose the latter, which unlocks dynamic network attachment for pods, thus also benefiting the Kubernetes community.

This talk will provide the audience with a basic understanding of KubeVirt, CNI, and Multus, and then propose a design to add (or remove) network interfaces from running pods (and virtual machines), along with the changes required in Multus and KubeVirt to make it happen.

It will also factor in a community perspective, explaining how we pitched and got both the Multus and KubeVirt communities involved in a working arrangement to deliver this functionality.

KubeVirt's architecture is composed of two main components: virt-handler, a trusted DaemonSet, running in each node, which operates as the virtualization agent, and virt-launcher, an untrusted Kubernetes pod encapsulating a single libvirt + qemu process.

To reduce the attack surface of the overall solution, the untrusted virt-launcher component should run with as little linux capabilities as possible.

The goal of this talk is to explain the journey to get there, and the steps taken to drop CAP NET ADMIN, and CAP NET RAW from the untrusted component.

This talk will encompass changes in KubeVirt and Libvirt, and requires some general prior information about networking (dhcp / L2 networking).