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.
- 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
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 CDNF.io – a portfolio of cloud-native network functions, by PANTHEON.tech.
Explore our PANTHEON.tech GitHub.
Watch our YouTube Channel.