How to Deploy and Test Multus CNI for Multi‑Network Pods in Kubernetes
This guide explains the background, architecture, and step‑by‑step deployment of Multus CNI in a Kubernetes cluster, including configuring Calico and Flannel as primary and secondary networks, creating network attachment definitions, and testing pod connectivity across multiple interfaces.
Background of Multus CNI
In a default Kubernetes pod only the loopback interface and eth0 exist. For workloads that need both external API access and internal data synchronization, a single NIC is insufficient, leading to latency and bottlenecks. Multi‑network solutions like Multus CNI are used to add extra interfaces.
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 itself does not provide IP allocation.
When Multus is installed, pods can have additional interfaces besides eth0.
CNI Types
CNI plugins are classified as Main, IPAM, and Meta.
Main : creates container interfaces (bridge, ipvlan, macvlan, ptp, etc.)
IPAM : manages IP address allocation (host‑local, dhcp, static, calico‑ipam, whereabouts)
Meta : extends functionality (tuning, bandwidth, portmap, etc.)
Deploying Multus CNI
The cluster uses Calico as the primary CNI (IPIP mode). Multus is deployed with the following commands:
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni/deployments
kubectl apply -f multus-daemonset-thick.yml
kubectl get ds -n kube-system | grep multusMultus runs as a DaemonSet, creates the binary multus‑shim in /opt/cni/bin, and generates 00‑multus.conf with capabilities for bandwidth and port mappings.
Deploying Flannel as a Secondary Network
Flannel is downloaded and modified to use eth1:
wget https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
# edit to set --iface=eth1
kubectl apply -f flannel.yamlFlannel creates a bridge interface flannel.1 on each node.
Adjusting Calico to Use a Specific Interface
Calico’s IP autodetection method is changed from can‑reach=$(NODEIP) to interface=eth0 via:
kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHOD=interface=eth0Testing Pods
A pod is created with an annotation to attach the Flannel network:
apiVersion: v1
kind: Pod
metadata:
name: nginx
annotations:
k8s.v1.cni.cncf.io/networks: flannel
spec:
containers:
- name: nginx
image: docker.io/library/nginx:latestAfter deployment, the pod has two interfaces: eth0 (Calico) and net1 (Flannel). Connectivity tests show that the default route uses eth0, while the Flannel IP is reachable only from the host.
NetworkPolicy only affects the primary interface; Flannel does not support NetworkPolicy.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
