Did you know? You can run multiple network plugins in Kubernetes with Multus
CNI (Container Network Interface)
First, let’s define what CNI is. CNI or Container Network Interface is a CNCF project that provides an API to configure network interfaces in Linux containers. It is a minimal specification to define a common interface between the network plug-ins and containers.
- CNI specification – defines the API that network plug-ins should support
- Plug-ins – provides network setup for different container use cases
- Library – a Go implementation of the CNI specification that network plugins can use
Each CNI plugin can provide different features and capabilities, and Multus is a great tool to make them work together.
Multus acts as a contact between the container runtime and a selection of network plugins, which are called upon to do the actual net configuration tasks.
Multiple network interfaces
Multiple network interface connections in Kubernetes pods are important when enabling delivery of cloud and communication service provider services.
Kubernetes pods usually support connection to only one network interface. However, pods are able to host containers supporting service-provisioning applications or virtual network functions (VNFs) that are requiring connectivity to multiple network interfaces.
Multiple network interfaces let you create configurations in which an instance connects directly to several networks (e.g. multiple VPC networks).
You can also use an additional network when there is a need for network isolation (data plane, control plane separation, etc.)
You can use multiple network interfaces to:
- Storage/legacy applications: Multiple connections enable the service provisioned within the pod to access a legacy application or storage drive and support pod communications.
- Multi-tenant networks: Multiple interfaces allow dedicated network connections for each customer when pod resources are shared between multiple tenants.
- Isolate network traffic: Enhances performance by sending traffic on two different planes so that you can manage how much traffic is along each plane. Improves security by separating private data that is not to be shared between tenants because it allows you to send sensitive traffic onto a network plane that is managed specifically for security considerations.
- Virtual private network (VPN)/router applications: Multiple network interfaces are essential for VPN and router use cases where security capabilities need to be extended into the pod. In these cases, the VPN/router links are encrypted, while others are unencrypted for normal pod communications.
What is Multus?
Multus can be used to create multiple network interfaces for pods in Kubernetes.
It is a Multi CNI plugin for Kubernetes that supports the Multi Networking feature by using CRD based network objects in Kubernetes, in other words, it enables attaching multiple network interfaces to pods.
- Supports reference plugins (e.g. Flannel, Macvlan) that implement the CNI specification and 3rd party plugins (e.g. Calico, Weave, Cilium, Contiv)
- Supports SR-IOV, DPDK, OVS-DPDK & VPP workloads in Kubernetes with both Cloud Native and NFV based applications in Kubernetes
- Manage contact between container runtime and plugins
- No network configuration done by itself (dependent on other plugins)
- Uses Flannel to group plugins into delegates
How does Multus work?
By default Kubernetes allows each pod to have only one network interface, apart from a loopback.
Multus allows you to create multi-homed pods that have multiple interfaces. Multus acts as a “meta plugin” (a CNI plugin that can call multiple other CNI plugins) to configure additional interfaces.
Multus use cases
- Traffic splitting
Running network functions (NF) that require separation of control/management, and data/user plane network traffic to meet throughput or Quality of Service (QoS) requirements.
Additional interfaces often leverage specialized hardware specifications such as Single Root I/O Virtualization (SR-IOV) and Data Plane Development Kit (DPDK), which bypass the operating system kernel for increased bandwidth and network performance.
Supporting multi-tenant networks with strict traffic isolation requirements. Connecting multiple subnets to pods to meet compliance requirements.
Multus Plugin Support and Management
Multus supports all plugins maintained in the official CNI repository, as well as popular third-party network plugins such as Contiv, Cilium, or Calico.
You can manage plugins by handling them as delegates (via Flannel). These can be invoked into a certain sequence, based on either a JSON scheme or CNI configuration.
Flannel is an overlay network in Kubernetes. It configures layer 3 network fabric and satisfies the requirements of Kubernetes (run by default on many installations).
After that, Multus invokes the eth0 interface in the pod for the primary/master plugin, while the rest of the plugins receive netx interfaces (net0, net1, etc.).
In the diagram below, you can observe the network interfaces attached to a pod, as provisioned by Multus CNI.
There are three interfaces in the pod: eth0, net0 and net1.
eth0 connects the kubernetes cluster network with kubernetes server/services (e.g. kubernetes api-server, kubelet and so on). net0 and net1 are additional network attachments and connect to other networks by using other CNI plugins (e.g. vlan/vxlan/ptp).