CN2 Components

The CN2 architecture on Amazon EKS consists of pods that perform the network configuration plane and network control plane functions, and pods that perform the network data plane functions.

The network configuration plane refers to the functionality that enables CN2 to manage its resources and interact with the Kubernetes control plane. The pods that perform the network configuration plane function reside on worker nodes that contain the Contrail controller.
The network control plane represents CN2's full-featured SDN capability. It uses BGP to communicate with other Contrail controllers and XMPP to communicate with the distributed data plane components on all worker nodes. The pods that perform the network control plane function reside on worker nodes that contain the Contrail controller.
The network data plane refers to the packet transmit and receive function on worker nodes. The pods that perform the network data plane function reside on all worker nodes.

Table 1 describes the main CN2 components. Depending on configuration, there might be other components as well (not shown) that perform ancillary functions such as certificate management and status monitoring.

Table 1: Main CN2 Components
Pod Name		Where	Description
Configuration Plane¹	contrail-k8s-apiserver	Worker Node	This pod is an aggregated API server that is the entry point for managing all Contrail resources. It is registered with the regular kube-apiserver as an APIService. The regular kube-apiserver forwards all network-related requests to the contrail-k8s-apiserver for handling. There is one contrail-k8s-apiserver pod per Contrail controller node.
	contrail-k8s-controller	Worker Node	This pod performs the Kubernetes control loop function to reconcile networking resources. It constantly monitors networking resources to make sure the actual state of a resource matches its intended state. There is one contrail-k8s-controller pod per Contrail controller node.
	contrail-k8s-kubemanager	Worker Node	This pod is the interface between Kubernetes resources and Contrail resources. It watches the kube-apiserver for changes to regular Kubernetes resources such as service and namespace and acts on any changes that affect the networking resources. In a single-cluster deployment, there is one contrail-k8s-kubemanager pod per Contrail controller node. In a multi-cluster deployment, there is additionally one contrail-k8s-kubemanager pod for every distributed workload cluster.
Control Plane¹	contrail-control	Worker Node	This pod passes configuration to the worker nodes and performs route learning and distribution. It watches the kube-apiserver for anything affecting the network control plane. It then communicates these changes with its BGP peers and vRouter agents (over XMPP) as appropriate. There is one contrail-control pod per Contrail controller node.
Data Plane	contrail-vrouter-nodes	Worker Node	This pod contains the vRouter agent and the vRouter. The vRouter agent acts on behalf of the local vRouter when interacting with the Contrail controller. There is one agent per node. The agent establishes XMPP sessions with two Contrail controllers to perform the following functions: translates configuration from the control plane into objects that the vRouter understands interfaces with the control plane for the management of routes collects and exports statistics from the data plane The vRouter provides the packet send and receive function for the co-located pods and workloads. It provides the CNI plug-in functionality.
¹The components that make up the network configuration plane and the network control plane are collectively called the Contrail controller.

Figure 1 shows these components in the context of an Amazon EKS cluster.

For clarity and to reduce clutter, the figures do not show the data plane pods on the Contrail controller node.

Figure 1: CN2 Components

The cluster operates in standard Kubernetes fashion, with the kube-apiserver being the REST API entry point for the cluster. The kube-apiserver directs all networking requests to the contrail-k8s-apiserver, which translates them into REST API calls to the respective CN2 objects. In some cases, these calls may result in the Contrail controller sending XMPP messages to the vRouter agent on other worker nodes or sending BGP messages (not shown) to other Contrail controller nodes or external routers. The Contrail controller sends these XMPP and BGP messages outside of regular Kubernetes cluster communications.

The contrail-k8s-kubemanager (cluster) components are only present in multi-cluster deployments. For more information on the different types of deployments, see Deployment Models.

The Contrail controller stores all CN2 cluster data in the Contrail etcd, separate from the main Amazon EKS etcd store.

Figure 2 shows a cluster with multiple Contrail controllers. As before, the Kubernetes components communicate with each other using REST (not shown) and the Contrail controllers communicate with the vRouters using XMPP. For redundancy, each vRouter establishes XMPP communications with two Contrail controllers. Additionally, the Contrail controllers exchange routes with each other using iBGP. By doing so, if any Contrail controller goes down, the other Contrail controllers have enough information to keep the network control plane running.

Figure 2: Multiple Contrail Controllers