Enhancing Kubernetes for advanced Telecom use cases with Multus CNI

As telecommunications companies increasingly adopt cloud-native technologies, Kubernetes has emerged as a key platform for deploying modern applications and network functions. However, the default Kubernetes networking model, which limits each pod to a single network interface, often falls short of meeting the complex requirements of telecom environments. Multus CNI steps in to bridge this gap, enabling multiple network interfaces within a single pod and providing the flexibility needed for advanced telecom use cases.

In this blog, we’ll explore how Multus CNI enhances Kubernetes, making it the ideal solution for driving innovation in 5G, NFV, and beyond.

What is Multus?

Kubernetes, by default, assigns only one network interface (like “eth0”) to each pod, which is usually enough for basic applications. However, some advanced use cases, especially in fields like telecommunications, need more complex networking setups. That’s where Multus comes in.Multus acts as a “meta-plugin” or manager that allows other network plugins to be used simultaneously. Instead of sticking with just one network connection, Multus can call other plugins like Calico, Flannel, or Macvlan, and attach multiple networks to a single pod. This setup is particularly useful when you need to separate traffic types, like separating data traffic from management traffic, or connecting to specialized high-speed networks.

But How Does Multus Work?

To install Multus, you typically deploy it as a DaemonSet within your Kubernetes cluster using a ready-made YAML manifest provided by the Multus project. This DaemonSet ensures that Multus is installed on every node in the cluster, enabling multi-network capabilities for your pods.

To install Multus, use the following command:

# Installing Multus Thick Plugin
$ kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset-thick.yml

Before we dive into the steps on how to install Multus and configure NetworkAttachmentDefinitions, it’s important to understand the different types of network plugins that Multus can work with. Each type provides unique networking capabilities, allowing you to tailor Kubernetes to fit specific needs, especially in advanced telecom use cases.

Let’s quickly explore the key types of Multus plugins:

• Macvlan: Creates multiple virtual network interfaces on a single physical interface, each with its own MAC address, providing high performance and traffic isolation at the link layer (Layer 2).

• Ipvlan: Similar to Macvlan, but all virtual interfaces share the same MAC address, isolating traffic at the network layer (Layer 3), which simplifies and reduces overhead, especially in environments with MAC address limitations.

• Bridge: Acts as a virtual switch, connecting pod interfaces to the host network, allowing pods to communicate on the same Layer 2 domain; it’s straightforward for basic connectivity but less scalable for performance-critical scenarios.

• SR-IOV: Enables direct access to the network hardware by creating virtual functions on a NIC, bypassing the host’s networking stack, which provides near-native performance ideal for high-performance and low-latency applications like NFV.

Let’s now continue by creating a NetworkAttachmentDefinition, which specifies the additional network configurations that can be attached to a pod. This definition allows you to set up the desired network properties that Multus will use, making it easy to connect your pods to multiple networks. Use the following YAML code to do so:

---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-blog-attachement
  namespace: default
spec:
  config: |-
    {
      "cniVersion": "0.3.1",                    
      "type": "macvlan",                     # Type of CNI plugin to use
      "master": "eth0",                      # The physical network interface to attach Macvlan to
      "ipam": {
        "type": "static",
        "routes": [
          { 
             "dst": "192.168.244.0/24",
             "gw": "192.168.244.1"
          }
        ]
      }
    }

To apply this YAML configuration, save it to a file (e.g., macvlan-blog.yaml) and use the kubectl apply command:

# Apply macvlan-blog.yaml
$ kubectl apply -f macvlan-network.yaml

We’ve just applied the Multus NetworkAttachmentDefinition to our cluster. Next, we’ll be creating a pod and applying the necessary annotations to attach a second interface to it. Use the following YAML code to do so:

---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-multus
  annotations:
    k8s.v1.cni.cncf.io/networks: |
      [{
        "name": "macvlan-blog-attachement",
        "ips": ["192.168.244.167/24"]
      }]
spec:
  containers:
  - name: busybox
    image: busybox:latest
    ports:
    - containerPort: 80
    command: ["sleep","infinity"]

We’ve successfully deployed the Busybox pod with the Multus annotations. Our next step is to verify that the pod has been assigned the second network interface and ensure that it is reachable. We’ll check the pod’s network configuration and connectivity to confirm that everything is set up correctly.

# ip address show
$ kubectl exec -it busybox-multus -- ip a
...
4: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 65535 qdisc noqueue
    link/ether de:ca:a6:9c:05:ed brd ff:ff:ff:ff:ff:ff
    inet 172.12.18.87/16 brd 172.12.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::dcca:a6ff:fe9c:5ed/64 scope link
       valid_lft forever preferred_lft forever
5: eth1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 9000 qdisc noqueue state UNKNOWN
    link/ether a0:88:c2:3e:a5:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.244.167/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a088:c200:13e:a50e/64 scope link
       valid_lft forever preferred_lft forever
...
# ping
$ ping 192.168.244.167
PING 192.168.244.167 (192.168.244.167): 56 data bytes
64 bytes from 192.168.244.167: icmp_seq=0 ttl=53 time=39.771 ms
64 bytes from 192.168.244.167: icmp_seq=1 ttl=53 time=36.178 ms
64 bytes from 192.168.244.167: icmp_seq=2 ttl=53 time=33.038 ms

Everything is working as expected! The Busybox pod has the second network interface and is reachable.

While this example was straightforward, real-world scenarios can be more complex. You might encounter situations where using IP ranges in the NetworkAttachmentDefinition is necessary, or you may need to work with different network types and configurations. Always consider the specific requirements of your deployment to ensure optimal setup and performance.

Conclusion

Multus offers a robust solution for complex networking scenarios within Kubernetes, enabling the use of multiple network interfaces in a single pod. This capability is crucial for advanced, production-grade use cases where diverse networking requirements must be met. By expanding Kubernetes networking capabilities, Multus provides greater flexibility and scalability, making it an invaluable tool for modern cloud-native environments.

Call to Action

Ready to explore the benefits of Multus for your Kubernetes cluster? Dive into its powerful networking features and see how it can enhance your setup.For expert assistance with Kubernetes networking and cloud-native solutions, don’t hesitate to reach out us (conro.io). Our team is here to help you navigate and implement these advanced technologies seamlessly.

Useful Links

• https://github.com/k8snetworkplumbingwg/multus-cni