How to Deploy and Test Multus CNI for Multi‑Network Pods in Kubernetes

Background of Multus CNI

In a Kubernetes environment a pod normally has only two network interfaces (loopback and eth0). When an application needs both external API access and internal data‑plane traffic, a single NIC is insufficient, leading to latency and bottlenecks.

To meet production requirements many multi‑network solutions have emerged; Multus CNI is the most widely used because it follows the CNI spec, is stable and actively maintained.

What is Multus CNI

Multus CNI is an open‑source CNI‑compliant plugin that enables multiple network interfaces for a pod by delegating the actual network configuration to other CNI plugins. It does not provide network configuration itself.

When Multus is installed and additional CNI plugins are configured, a pod will have more interfaces than just eth0.

CNI Types

CNI plugins are classified into three types:

Main : creates container interfaces (bridge, ipvlan, macvlan, ptp, etc.).

IPAM : allocates IP addresses (host‑local, dhcp, static, calico‑ipam, whereabouts, etc.).

Meta : extends functionality (tuning, bandwidth, portmap, etc.). Multus belongs to the Meta class.

Deploying Multus CNI

In the test environment the primary CNI is Calico (IPIP mode). The following commands clone the Multus repository and apply the daemonset:

git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni/deployments
kubectl apply -f multus-daemonset-thick.yml

Verify the daemonset is running:

kubectl get ds -n kube-system | grep multus

Deploying Flannel as an attachment network

Download the Flannel yaml, modify it to use eth1 as the interface, change the backend to vxlan, and apply it:

wget https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# edit to set --iface=eth1 and backend vxlan
kubectl apply -f flannel.yaml

Check that the Flannel daemonset is running and that the binary appears on each node.

Creating NetworkAttachmentDefinition

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: flannel
spec:
  config: '{
    "cniVersion": "0.3.0",
    "type": "flannel",
    "delegate": {
      "hairpinMode": true,
      "isDefaultGateway": false
    }
  }'

Apply it with kubectl apply -f flannel-nad.yaml.

Modifying Calico to use a specific NIC

Calico’s IP detection method can be changed from can‑reach to interface=eth0 via:

kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=interface=eth0

The daemonset restarts and the new environment variable can be verified inside a Calico pod.

Testing the multi‑network pod

Create a pod that requests the Flannel network:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  annotations:
    k8s.v1.cni.cncf.io/networks: flannel
spec:
  containers:
  - name: nginx
    image: nginx:latest

After the pod is created, inspect its network namespaces. The pod has eth0 (Calico) and net1 (Flannel). Routing tables show the default route via eth0, so traffic to the Flannel network must be accessed explicitly.

Ping tests from the host and between pods confirm that the Calico IPs are reachable, while Flannel IPs are not reachable from outside because the default route does not use net1.

Limitations

Flannel does not support NetworkPolicy, so policies applied to eth0 will not affect traffic on the secondary interface.