Multiple Interface Pod

With multiple virtual networks created, you can attach (you could also say plug, or insert) any of them into a pod, with the pod’s YAML file like this:

Or, another valid format:

You’ve probably noticed that pods in a namespace can not only refer to the networks defined in the local namespace, but also the networks created on other namespaces using their fully scoped name. This is very useful. The same network does not have to be duplicated again and again in every namespace that needs it. It can be defined once and then referred to everywhere else.

We’ve gone through the basic theories and explored the various templates, so let’s get a working example in the real world. Let’s start by creating two virtual networks, examining the virtual network objects, then create a pod and attach the two virtual networks into it. We’ll conclude by examining the pod interfaces and the connectivity with other pods sharing the same virtual networks.

Here is the YAML file of the two virtual networks (vn-left-1 and vn-right-1):

Now create both virtual networks:

Examine the virtual networks:

The virtual networks are created, as expected. Nothing much exciting here but, if you log in to the Contrail UI, you will see something unexpected in the next screen capture, Figure 1.

Figure 1: Contrail Command: Main Menu > Virtual Networks

And what you’ll find is the lack of any virtual network with the exact name of vn-left-1 or vn-right-1 in the UI. Instead, there two virtual networks, named k8s-vn-left-1-pod-network and k8s-vn-right-1-pod-network.

There is nothing wrong here. What happened is whenever a virtual network gets created from Kubernetes, Contrail automatically adds the Kubernetes cluster name (by default k8s) as a prefix to the virtual network name that you give in your network YAML file, and a suffix -pod-network in the end. This makes sense because we know a virtual network can be created by different methods and with these extra keywords embedded in the name, it’s easier to tell how the virtual network was created (from Kubernetes or manually from the UI) and what will it be used for. Also, potential virtual network name conflicts can be avoided when working across multiple Kubernetes clusters.

Here is YAML file of a pod with multiple virtual networks:

In pod annotations under metadata, insert two virtual networks: vn-left-1 and vn-right-1. Now, guess how many interfaces the pod will have on bootup? You might think two because that is what we specified in the file. Let’s create the pod and verify:

In Annotations, under k8s.v1.cni.cncf.io/network-status, you can see a list […], which has three items, each represented by a curly brace {} of key-value mappings. Each curly brace includes information about one interface: the allocated IP, the MAC, and the virtual network it belongs to. So you will end up having three interfaces created in the pod instead of two.

Notice the second item stating the IP address 10.47.255.238. It is the interface attached to the default pod network named cluster-wide-default, which is created by the system. You can look at the default pod network as a management network because it is always up and running in every pod’s network namespace. Functionally, it’s not much different from the virtual network you created, except that you can’t delete it.

Let’s log in to the pod, list the interfaces, and verify the IP and MAC addresses:

You can see one lo interface and three interfaces plugged by Contrail CNI, each with the IP allocated from the corresponding virtual network. Also notice the MAC addresses match what we’ve seen in the kubectl describe command output.

You’ll see the multiple-interfaces pod again in the example where the pod will be based on a Juniper cSRX image instead of a general Docker image. The basic idea remains the same.