Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Create an Isolated Namespace

SUMMARY This topic shows you how to create an isolated namespace in Juniper Cloud-Native Contrail® Networking™ (CN2). Juniper Networks supports isolated namespaces using Contrail Networking Release 22.1 or later in a Kubernetes-orchestrated environment.

Namespace Overview

Note:

In this document, we use the term "isolated" and "non-isolated" in the context of Contrail networking only.

Non-Isolated Namespaces

Namespaces, also called non-isolated namespaces, provide a mechanism for isolating a group of resources within a single cluster. By default, namespaces are not isolated.

Non-isolated namespaces are intended for use in environments with many users spread across multiple teams, or projects. Non-isolated namespaces enable each team to exist in its own virtual cluster without team members affecting each other's work. Let's say that you created all your resources in the default namespace that Kubernetes provides. If you have a complex application with multiple deployments, the default namespace can be hard to maintain. An easier way to manage this deployment is to group all your resources into different namespaces within the cluster. For example, the cluster can contain separate namespaces, such as a database namespace or a monitoring database. Names of resources must be unique within a namespace, but you can repeat resource names across namespaces.

Pods in a non-isolated namespace exhibit the following network behavior:

  • They can communicate with other pods in the cluster without using NAT.

  • They share the same default-podnetwork and default-servicenetwork.

Isolated Namespaces.

An isolated namespace enables you to run customer-specific applications that you want to keep private. You can create an isolated namespace to isolate a pod from other pods, without explicitly configuring a network policy.

Isolated namespaces are similar to non-isolated namespaces, except that each isolated namespace has its own pod network and service network. This means that pods in isolated namespaces cannot reach pods or services in other isolated or non-isolated namespaces.

Pods in isolated namespaces can communicate only with pods in the same namespace. The only exception is when a pod in an isolated namespace needs access to a Kubernetes service, such as Core DNS. In this case, the pod uses the cluster's default-servicenetwork to access the services.

Pods in an isolated namespace exhibit the following network behavior:

  • They can communicate only with pods in the same namespace.

  • They can reach services in non-isolated namespaces.

  • Their IP addresses and service IP addresses are allocated from the same subnet as the cluster's pod and service subnet.

  • They can access the underlay network, or IP fabric network, through IP fabric forwarding and fabric source NAT.

Note: You cannot convert a non-isolated namespace to an isolated namespace, or vice versa.

Example: Isolated Namespace Configuration

This sample configuration demonstrates an isolated namespace configuration in Cloud-Native Contrail Networking (CN2).

Figure 1: Isolated Namespace Configuration Isolated Namespace Configuration

In the above isolated namespace configuration:

  • Pod-1 (non-isolated-1) is in a non-isolated namespace created by the user.

  • Pod-2 (kube-system) and Pod-3 (contrail) are in non-isolated namespaces created by the controller.

  • Pod-4 (isolated-1) and Pod-5 (isolated-2) are in isolated namespaces created by the user.

  • The interfaces for Pod-1, Pod-2, and Pod-3 are created from the cluster's default-podnetwork and default-servicenetwork.

  • The interfaces for Pod-4 and Pod-5 are created on the default-podnetwork and default-servicenetwork in their own isolated namespaces. Both Pod-4 and Pod-5 interfaces share the same subnet as the cluster’s default-podnetwork and default-servicenetwork.

  • Pods in isolated namespaces cannot communicate with pods in non-isolated namespaces. In this example, Pod-4 and Pod-5 in isolated namespaces cannot communicate with Pod-1, Pod-2, or Pod-3 in non-isolated namespaces.

  • Pods in isolated namespaces (Pod-4 and Pod 5) can access any service through the cluster's default-servicenetwork.

  • Pods in all namespaces (non-isolated and isolated) can connect to the fabric through the cluster's ip-fabric-network.

Notes

  • Isolated namespaces affect only the pod's default interface. This is because the default interface of pods in an isolated namespace are created on the default-podnetwork of the isolated namespace. However, interfaces from user-defined VirtualNetworks behave the same way in both isolated and non-isolated namespaces.

  • You can create network policies on isolated namespaces to adjust the isolation of pods. The network policy behaves the same for both isolated and non-isolated namespaces.

  • Two or more isolated namespaces can be interconnected through the VirtualNetworkRouter (VNR).

Here is an example of a VirtualNetworkRouter (VNR) configuration used to interconnect the default-podnetworks of two isolated namespaces (ns-isolated-1 and ns-isolated-2). In this configuration, the VirtualNetworkRouter connects to ns-isolated-1 and ns-isolated-2. This means that pods in these isolated namespaces can communicate with each other.

Isolated Namespace Objects

This table describes the namespace objects (API resources) that the controller creates when you create an isolated namespace.

Table 1: Isolated Namespace Objects
Isolated Namespace Object Description
default-podnetwork (VirtualNetwork) The default interfaces of pods in an isolated namespace are created in this default-podnetwork instead of the cluster's default-network.
default-servicenetwork (VirtualNetwork) The cluster IP of services in isolated namespaces are created in this default-servicenetwork instead of the cluster's default-servicenetwork.
IsolatedNamespacePodServiceNetwork (VirtualNetworkRouter) This object establishes connectivity between the isolated namespace's default-podnetwork and default-servicenetwork.
IsolatedNamespaceIPFabricNetwork (VirtualNetworkRouter) This object establishes connectivity between the isolated namespace's default-podnetwork and default-servicenetwork to the cluster's ip-fabricnetwork.
IsolatedNamespacePodToDefaultService (VirtualNetworkRouter) This object establishes connectivity between the isolated namespace's default-podnetwork to the cluster’s default-servicenetwork.

Create an Isolated Namespace

Follow these steps to create an isolated namespace:

  1. Create a YAML file called ns-isolated.yml.
  2. Add the label core.juniper.net/isolated-namespace to the namespace metadata and set the variable to "true".
  3. Issue the kubectl apply command to apply the configuration.
  4. To verify your configuration, issue the kubectl get ns ns-isolated -o yaml command.

    Success! You created an isolated namespace.

Optional Configuration: IP Fabric Forwarding and Fabric Source NAT

Optionally, you can enable IP fabric forwarding and fabric source NAT on an isolated namespace.

IP fabric forwarding enables virtual networks to be created as part of the underlay network and eliminates the need for encapsulation and de-encapsulation of data. Fabric source NAT allows pods in the overlay to reach the Internet without floating IPs or a logical system.

When you create an isolated namespace, two virtual networks are created, a default-podnetwork and a default-servicenetwork. By default, IP fabric forwarding and fabric source NAT in these two virtual networks are disabled. You enable IP fabric forwarding or fabric source NAT in the virtual networks by adding “forwarding-mode” annotations for each feature in your isolated namespace YAML file.

Here is an example of the default-podnetwork for an isolated namespace with forwarding-mode set to fabricSNAT.

Enable IP Fabric Forwarding

Follow these steps to enable IP fabric forwarding on an isolated namespace:

  1. Add the annotation core.juniper.net/forwarding-mode: "ip-fabric" to the namespace metadata.
  2. Set the label for the isolated namespace to "true".
  3. Issue the kubectl apply command to enable IP fabric forwarding.
  4. Verify your configuration.

    Success! You enabled IP fabric forwarding on the isolated namespace.

Enable Fabric Source NAT

Note:

You can enable fabric source NAT only on the default-podnetwork.

Follow these steps to enable fabric source NAT on an isolated namespace:

  1. Add the annotation core.juniper.net/forwarding-mode: "fabric-snat" to the namespace metadata.
  2. Set the label for the isolated namespace to "true".
  3. Issue the kubectl apply command to enable fabric source NAT.
  4. Verify your configuration.
    Success! You enabled fabric source NAT on the isolated namespace.

See Also