Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Multiple Network Interfaces for Containers

 

Starting in Release 4.0, Contrail provides networking support for containers using Kubernetes Orchestration. You can allocate a network interface to every container that you create using standard Container Networking Interface (CNI plugin). For more information on Contrail Containers Networking, see Contrail Integration with Kubernetes.

Starting in Contrail Release 5.1, you can allocate multiple network interfaces (multi-net) to a container to enable the container to connect to multiple networks. You can specify the networks the container can connect to. A network interface is either a physical interface or a virtual interface and is connected to the Linux network namespace. A network namespace is the network stack in the Linux kernel. More than one container can share the same network namespace.

Contrail multi-net support is based on the Kubernetes multi-net model. Kubernetes multi-net model has a specific design and construct, and can be extended to non-kubernetes models like Contrail multi-net. Contrail multi-net model does not require changes to the Kubernetes API and Kubernetes CNI driver. Contrail multi-net model, as in the case of Kubernetes multi-net model, does not change the existing cluster-wide network behavior.

The following limitations and caveats apply when you create multi-net interfaces:

  • You cannot add or remove sidecar networks while the pod is still running.

  • The administrator is responsible for removing corresponding Contrail pods before deleting the network attachment definition from the Kubernetes API server.

  • Contrail creates a default cluster-wide-network in addition to custom networks.

  • Contrail CNI plugin is not a delegating plugin. It does not support specifications for delegating plugins that are provided in the Kubernetes Network Custom Resource Definition De Facto Standard Version 1. For more information, view [v1] Kubernetes Network Custom Resource Definition De-facto Standard.md from the https://github.com/K8sNetworkPlumbingWG/multi-net-spec page.

Creating Multi-Net Interfaces

Follow these steps to create multi-net interfaces.

  1. Create Network Object Model.

    You create the network object model if the cluster does not support the model.

    The object model of the container orchestration platform represents the network and attaches the network to a container. If the model does not support network objects by default, you can use extensions to represent the network.

    Creating Network Object Model by using Kubernetes NetworkAttachmentDefinition CRD object

    Kubernetes uses custom extensions to represent networks in its object model. CustomResourceDefinition(CRD) feature of Kubernetes helps support custom extensions.

    Note

    A CRD is created automatically when you install Contrail. Networks specified by CRD are sidecars that are not recognized by Kubernetes. The interaction of additional pod network attachments with Kubernetes API and its objects, such as services, endpoints, proxies, etc. are not specified. Kubernetes does not recognize the association of these objects to any pod.

  2. Create networks.

    You create networks in the cluster:

    • Through the API server.

      Create a right-network.yaml file.

    • By mapping to an existing network created from the Contrail Web user interface or from the Contrail Command user interface.

    Command to create the network:

    kubectl apply -f right-network.yaml
  3. Assign networks to pods.

    You assign the networks that you created in Step 2 to pods. Each pod also has a default network assigned to it. Therefore, each pod will have the following networks assigned:

    • default network (assigned by Kubernetes)

      Note

      Contrail internally creates a default network called cluster-wide-network. This interface is the default interface for the pod

    • network that you created in Step 2

    Assigning networks to pods by using k8s-semantics:

    Option 1

    Option 2