Multus CNI (Container Network Interface) is a novel approach to managing multiple CNIs in your container network (Kubernetes). Based on its name, which means multiple in Latin, Multus is an open-source plug-in, which serves as an additional layer in a container network, to enable multi-interface support. For example, Virtual Network Functions (VNFs) often depend on connectivity towards multiple network interfaces.

The CNI project itself, backed by the Cloud Native Computing Foundation, defines a minimum specification on what a common interface should look like. The CNI project consists of three primary components:

Specification: an API that lies between the network plugins and runtimes
Plugins: depending on use-cases, they help set up the network
Library: CNI specifications as Go implementations, which are then utilized by runtimes

Each CNI can deliver different results, which makes Multus a wonderful plugin to manage these functionalities and make them work together.

Multus delivers this functionality in form of a contact between the container runtime and a selection of plugins, which are called upon to do the actual net configuration tasks.

Multus Characteristics

Manage contact between container runtime and plugins
No net configuration by itself (dependent on other plugins)
Uses Flannel to group plugins into delegates
Support for reference & 3rd party plugins
Supports SRIOV, DPDK, OVS-DPDK & VPP workloads with cloud-native & NFV based applications

Multus Plugin Support & Management

Currently, Multus supports all plugins maintained in the official CNI repository, as well as 3rd party plugins like Contiv, Cilium or Calico.

Management of plugins done by handling plugins as delegates (using Flannel), which can be invoked into a certain sequence, based on either a JSON scheme or CNI configuration. Flannel is an overlay network in Kubernetes, which configures layer 3 network fabric and therefore satisfies Kubernetes requirements (run by default on many plugins). Multus then invokes the eth0 interface in the pod for the primary/master plugin, while the rest of the plugins receive netx interfaces (net0, net1, etc.).

StoneWork in K8s Pod with Multiple Interfaces

Our team created a demo on how to run StoneWork in a Microk8s pod with multiple interfaces attached via the Multus add-on.

This example attaches two existing host interfaces to the Stonework container running on a Microk8s pod. Highlights include the option to add multiple DPDK interfaces, as well as multiple af_packet interfaces to StoneWork with this configuration.

If you are interested in more details regarding this implementation, contact us for more information!

Utilizing Cloud-Native Network Functions

If you are interested in high-quality CNFs for your next or existing project, make sure to check out our portfolio of cloud-native network functions, by PANTHEON.tech.

Leave us your feedback on this post!

You can contact us here.

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.