Contrail Namespaces and Isolation

In Chapter 3 you read about namespace or NS in Kubernetes, and at the beginning of this chapter we mentioned object mappings between Kubernetes and Contrail. In this section you’ll see how namespace works in Contrail environments and how Contrail extends the feature set even further.

One analogy given when introducing the namespace concept is OpenStack project, or tenant. And that is exactly how Contrail is looking at it. Whenever a new namespace object is created, contrail-kube-manager (KM) gets a notice about the object creation event and it will create the corresponding project in Contrail.

To differentiate between multiple Kubernetes clusters in Contrail, a Kubernetes cluster name will be added to the Kubernetes namespace or project name. The default Kubernetes cluster name is k8s. So if you create a Kubernetes namespace ns-user-1, a k8s-ns-user-1 project will be created in Contrail just as you can see here in Figure 1, which shows the Contrail GUI.

Figure 1: Contrail Command: Projects

The Kubernetes cluster name is configurable, but only during the deployment process. If you don’t configure it k8s will be the default. Once the cluster is created, the name cannot be changed. To view the cluster name, you have to go to the contrail-kube-manager (KM) docker and check its configuration file.

To locate the KM docker container:

To log in to the KM container:

To find the cluster_name option:

Non-Isolated Namespaces

You should be aware that one Kubernetes basic networking requirement is for a flat/NAT-less network – any pod can talk to any pod in any namespace – and any CNI provider must ensure that. Consequently, in Kubernetes, by default, all namespaces are not isolated:

k8s-default-pod-network and k8s-default-service-network

To provide networking for all non-isolated namespaces, there should be a common VRF (virtual routing and forwarding) table or routing instance. In the Contrail Kubernetes environment, two default virtual networks are pre-configured in k8s’ default namespace, for pod and for service, respectively. Correspondingly, there are two VRF tables, each with the same name as their corresponding virtual network.

The name of the two virtual networks/VRF tables is in this format:

<k8s-cluster-name>-<namespace name>-[pod|service]-network

So, for the default namespace with a default cluster name, k8s, the two Virtual network/VRF table names are:

• k8s-default-pod-network: the pod virtual network/VRF table, with the default subnet 10.32.0.0/12

• k8s-default-service-network: the service virtual network /VRF table, with a default subnet 10.96.0.0/12

It is important to know that these two default virtual networks are shared between all of the non-isolated namespaces. What that means is that they will be available for any new non-isolated namespace that you create, implicitly. That’s why pods from all non-isolated namespaces, including default namespaces, can talk to each other.

On the other hand, any virtual networks that you create will be isolated with other virtual networks, regardless of the same or different namespaces. Communication between pods in two different virtual networks requires Contrail network policy.

Isolated Namespaces

In contrast, isolated namespaces have their own default pod-network and service-network, and accordingly, two new VRF tables are also created for each isolated namespace. The same flat-subnets 10.32.0.0/12 and 10.96.0.0/12 are shared by the pod and service networks in the isolated namespaces. However, since the networks are with a different VRF table, by default it is isolated with another namespace. Pods launched in isolated namespaces can only talk to service and pods on the same namespace. Additional configurations, for example, policy, are required to make the pod able to reach the network outside of the current namespace.

To illustrate this concept, let’s use an example. Suppose you have three namespaces: the default namespace, and two user namespaces: ns-non-isolated and ns-isolated. In each namespace you can create one user virtual network: vn-left-1. You will end up following virtual network/VRF tables in Contrail:

• default-domain:k8s-default:k8s-default-pod-network

• default-domain:k8s-default:k8s-default-service-network

• default-domain:k8s-default:k8s-vn-left-1-pod-network

• default-domain:k8s-ns-non-isolated:k8s-vn-left-1-pod-network

• default-domain:k8s-ns-isolated:k8s-ns-isolated-pod-network

• default-domain:k8s-ns-isolated:k8s-ns-isolated-service-network

• default-domain:k8s-ns-isolated:k8s-vn-left-1-pod-network

Note

The above names are listed in FQDN format. In Contrail, domain is the top-level object, followed by project/tenant, and then followed by virtual networks.

Figure 2 expertly illustrates all this.

Figure 2: NS and Virtual Network

Here is the YAML file to create an isolated namespace:

And to create the NS:

The annotations under metadata are an additional way to compare standard (non-isolated) k8s namespace. The value of true indicates this is an isolated namespace:

You can see that this part of the definition is Juniper’s extension. The contrail-kube-manager (KM) reads the namespace metadata from kube-apiserver, parses the information defined in the annotations object, and sees that the isolation flag is set to true. It then creates the tenant with the corresponding routing instance (one for pod and one for service) instead of using the default namespace routing instances for the isolated namespace. Fundamentally that is how the isolation is implemented.

The following sections will verify that the routing isolation is working.

Pods Communication Across NS

Create a non-isolated namespace and an isolated namespace:

In both namespaces and the default namespace, create a deployment to launch a webserver pod:

Ping between all pods in three namespaces:

The test result shows that bidirectional communication between two non-isolated namespaces (namespace ns-non-isolated and default, in this case) works, but traffic from a non-isolated namespace (default ns) toward an isolated namespace does not pass through. What about traffic within the same isolated namespace?

With the power of deployment you can quickly test it out: in isolated namespace ns-isolated, clone one more pod by scale the deployment with replicas=2 and ping between the two pods:

The ping packet passes through now. To summarize the test results:

• Traffic is not isolated between non-isolated namespace.

• Traffic is isolated between an isolated namespace and all other tenants in the cluster.

• Traffic is not isolated in the same namespace.