The Kubernetes networking framework does support only 1 interface, where as when we deploy applications it requires multiple interfaces. For examples, an application in 5G gNB names f1ctransport which resides in CUCP function and responsible for providing mid-haul (F1-C) connectivity between DU and CUCP, then f1ctransport requires two interface.
- eth0 interface internal communication (same network)
- net1 interface for external communication (different network)
So to meet the requirement of additional interface in deployments, we need to use Multus Container Network Interface (CNI) .
Multus Working:
Multus allows containerized applications to have more than one network interface. It has the ability to group multiple plugins. Multus calls for each CNI in a sequential order as implied in the CNI configuration file. Default path would be typically /opt/cni/bin
At the time container instantiation, Kubelet invokes the CNI plugin and the CNI plugin in turn invokes the Multus master plugin. Multus Master plugin now invokes other CNI plugins (e.g. SRIOV plugin) in a sequential order to create the required interfaces.
Multus by itself is not a network interface so it does not actually provide any routing capabilities. The primary responsibility of Multus is to orchestrate multiple interfaces acting as a meta plugin
The per-requisite for implementing Multus is to already have a default network plugin in place (e.g. Calico). From now on any new interface or plugin to be called is done by Multus in addition to the existing default network interface
Related Posts