How Multus CNI Enables Multi‑Network Pods in Kubernetes

In Kubernetes, networking is a critical area. Kubernetes itself does not provide a network solution but defines the CNI specification, which many CNI plugins (e.g., WeaveNet, Flannel, Calico) implement to form the cluster’s default network, enabling Pods to communicate across nodes.

Kubernetes originally lacks the ability to support multiple network interfaces required by VNFs. To address this, Intel created the MULTUS CNI plugin, which allows adding multiple interfaces to a Pod, each managed by its own CNI plugin.

The diagram below illustrates a container with three interfaces: eth0, net0, and net1. eth0 connects to the Kubernetes cluster network, while net0 and net1 connect to additional networks via other CNI plugins (e.g., vlan, vxlan, ptp).

How MULTUS Works

Kubernetes does not natively provide a way to add extra interfaces to a Pod or to run multiple CNI plugins simultaneously, but it does expose an extensible API via Custom Resource Definitions (CRDs). MULTUS relies on a CRD to store information about additional interfaces and the CNI plugins that manage them.

Deployment Example

"Default network" – the primary Pod‑to‑Pod network (interface eth0) that provides basic connectivity.

"CRD" – Custom Resource Definition used by MULTUS to store configuration for each additional interface.

Supported on Kubernetes 1.16+.

Installation

We recommend deploying MULTUS via a DaemonSet, which runs a Pod on every node to install the MULTUS binary and configure it for use.

$ git clone https://github.com/intel/multus-cni.git && cd multus-cni

The repository includes YAML files for use with kubectl.

$ cat ./images/multus-daemonset.yml | kubectl apply -f -

What does the Multus DaemonSet do?

Launches a daemonset that places the MULTUS binary in /opt/cni/bin on each node.

Reads the first configuration file in /etc/cni/net.d (alphabetically) and generates a new /etc/cni/net.d/00-multus.conf based on the default network.

Creates a /etc/cni/net.d/multus.d directory on each node containing authentication information for MULTUS to access the Kubernetes API.

Creating Additional Interfaces

First, create a configuration for each extra interface you want to attach to a Pod by defining a custom resource. The quick‑start installation creates a CRD where these configurations are stored.

CNI Configuration

Each added interface uses a standard CNI JSON configuration. Example:

{
  "cniVersion": "0.3.0",
  "type": "loopback",
  "additional": "information"
}

Key fields: cniVersion: specifies the CNI spec version. type: name of the binary in /opt/cni/bin that implements the plugin (e.g., loopback). additional: any plugin‑specific parameters.

CNI configurations are read each time a Pod is created or deleted, so changes take effect on the next Pod creation.

Storing Configuration as a Custom Resource

We will create a macvlan interface for Pods. The custom resource is named NetworkAttachmentDefinition. The metadata.name field (e.g., macvlan-conf) is used in the Pod annotation to select the configuration.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-conf
spec:
  config: '{
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.1.0/24",
        "rangeStart": "192.168.1.200",
        "rangeEnd": "192.168.1.216",
        "routes": [{"dst": "0.0.0.0/0"}],
        "gateway": "192.168.1.1"
      }
    }'

This example uses eth0 as the master interface, which must match the host’s interface name.

Verify the custom resource: $ kubectl get network-attachment-definitions Get details:

$ kubectl describe network-attachment-definitions macvlan-conf

Creating a Pod with the Additional Interface

Define a Pod that references the custom resource via the annotation k8s.v1.cni.cncf.io/networks:

apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf
spec:
  containers:
  - name: samplepod
    command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: alpine

Inspect the Pod’s interfaces: $ kubectl exec -it samplepod -- ip a You should see three interfaces: lo – loopback. eth0 – the default network. net1 – the new macvlan interface.

Network Status Annotations

View the Pod’s annotations to confirm both CNI plugins are active:

Annotations:        k8s.v1.cni.cncf.io/networks: macvlan-conf
                    k8s.v1.cni.cncf.io/networks-status:
                      [{"name":"cbr0","ips":["10.244.1.73"],"default":true,"dns":{}},{"name":"macvlan-conf","interface":"net1","ips":["192.168.1.205"],"mac":"86:1d:96:ff:55:0d","dns":{}}]

This metadata shows two successfully running CNI plugins.

What if I Need More Interfaces?

Create additional custom resources and reference them in the Pod annotation. For example, to attach two macvlan interfaces:

apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-conf,macvlan-conf
spec:
  containers:
  - name: samplepod
    command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: alpine

The annotation now lists the two configurations separated by commas.

References

https://zhuanlan.zhihu.com/p/73863683