Namespace and Network

Relationship Between a Namespace and Network

A namespace corresponds to a subnet in a VPC, as shown in Figure 1. When a namespace is created, it will be associated with an existing VPC or a newly created VPC, and a subnet will be created under the VPC. In this namespace, resources such as pods and Services are created in the corresponding VPC and subnet, and the IP addresses in the subnet are used.

If you want to run resources of multiple services in the same VPC, you need to plan subnet CIDR blocks and IP addresses.

Figure 1 Relationship between namespaces and VPC subnets

Scenarios Where Multiple Namespaces Are Used

Because namespaces enable partial environment isolation, you can create different namespaces, such as production, test, and development namespaces based on project attributes when there are a large number of projects and persons.

Creating a Namespace

Under a namespace, a network is required to associate with a VPC and subnet. After a namespace is created, a network needs to be created.

In most cases, namespaces do not need to be frequently created. You are advised to log in to the CCI console to create a namespace. For details, see Namespace.

In the following example, create a namespace named namespace-test, and specify the CCI resource type to general-computing.

apiVersion: v1
kind: Namespace
metadata:
  name: namespace-test
  labels:
    sys_enterprise_project_id: "0" 
  annotations:
    namespace.kubernetes.io/flavor: general-computing
spec:
  finalizers:
  - kubernetes

The definition file is in the YAML or JSON format. For more details about the YAML format, see YAML Syntax.

• sys_enterprise_project_id: enterprise project ID, which can be obtained from the project details page on the Enterprise Project Management (EPS) console. This field does not need to be set if you have not enabled EPS. If this parameter is not set, the default value 0 is used, indicating the default enterprise project.
• namespace.kubernetes.io/flavor: general-computing: namespace type.

  There are two namespace types:

  • General-computing: container instances and workloads with CPU resources. This namespace type is suitable for general computing scenarios.
  • GPU-accelerated: container instances and workloads with GPU resources. This namespace type is suitable for scenarios such as deep learning, scientific computing, and video processing.

If the file name of the namespace definition is ns.yaml, run kubectl create -f ns.yaml to create a namespace. -f indicates that the namespace is created from a file.

# kubectl create -f ns.yaml 
namespace/namespace-test created

Run kubectl get ns to check whether the namespace is successfully created. In this command, ns indicates the namespace.

# kubectl get ns
NAME             STATUS    AGE
namespace-test   Active    23s

The preceding information indicates that the namespace namespace-test is created successfully and the duration is 23 seconds.

Log in to the CCI console. In the navigation pane, choose Namespaces. You can see that the namespace is created successfully but the status is Abnormal. This is because in CCI, you need to define a network policy for the namespace. For details, see Creating a Network.

Figure 2 Namespace - abnormal

Creating a Network

After creating a namespace, you need to create a network policy for the namespace and associate the namespace with the VPC and subnet.

apiVersion: networking.cci.io/v1beta1
kind: Network
metadata:
  annotations:
    network.alpha.kubernetes.io/default-security-group: security-group-id
    network.alpha.kubernetes.io/domain-id: domain-id
    network.alpha.kubernetes.io/project-id: project-id
  name: test-network
spec:
  cidr: 192.168.0.0/24
  attachedVPC: vpc-id
  networkID: network-id
  networkType: underlay_neutron
  subnetID: subnet-id

The CIDR blocks of the VPC and subnet cannot be 10.247.0.0/16, which is the CIDR block reserved by CCI for Services. If you use this CIDR block, IP address conflicts may occur, which may result in workload creation failures or service unavailability. If you do not need to access pods through Services, you can allocate this CIDR block to a VPC.

You can obtain the preceding parameters as follows:

• network.alpha.kubernetes.io/domain-id: account ID, which can be obtained from My Credentials.
• network.alpha.kubernetes.io/project-id: project ID, which can be obtained from My Credentials.
• network.alpha.kubernetes.io/default-security-group: security group ID, which can be obtained from the Security Groups page.
  Figure 3 Obtaining the security group ID
  
• cidr: subnet CIDR block.
• attachedVPC: VPC ID, which can be obtained from the VPC console.
  Figure 4 Obtaining the VPC ID
  
• networkID: subnet network ID, which can be obtained by choosing Virtual Private Cloud under Network and then choosing Subnets in the navigation pane.
  Figure 5 Obtaining the subnet network ID
  
• networkType: network type. Currently, only the underlay_neutron network type is supported.
• subnetID: subnet ID, which can be obtained by choosing Virtual Private Cloud under Network and then choosing Subnets in the navigation pane.
  Figure 6 Obtain the subnet ID.
  

If the file name of the network definition is network.yaml, run kubectl create -f network.yaml to create a namespace. -f indicates that the namespace is created from a file. namespace namespace-test indicates that it is created in the namespace namespace-test.

# kubectl create -f network.yaml --namespace namespace-test
network.networking.cci.io/test-network created

Log in to the CCI console. In the navigation pane, choose Namespaces. You can see that the namespace is created successfully and the status is Available.

Figure 7 Namespace - available

Specifying a Namespace for the kubectl Context

The network above is created in a specified namespace. The subsequent resources are created in a namespace. It is time-consuming to specify the namespace each time. You can specify the namespace for a kubectl context. In this way, the resources created in the context are all under this namespace, which facilitates operations.

To specify the namespace, you only need to add the --namespace option to the context setting command, as shown in the following command:

kubectl config set-context $context --namespace=$ns

In the preceding command, $ns indicates the namespace name, and $context indicates the context name, which can be customized or obtained by running the following command:

# kubectl config get-contexts
CURRENT   NAME                                         CLUSTER                  AUTHINFO                                  NAMESPACE
          cci-context-cn-east-3-1C8PNI0POPPCSFGXPM6S   cci-cluster-cn-east-3    cci-user-cn-east-3-1C8PNI0POPPCSFGXPM6S   
*         cci-context-cn-east-3-hwuser_xxx             cci-cluster-cn-east-3    cci-user-cn-east-3-hwuser_xxx       
          kubernetes-admin@kubernetes                  kubernetes               kubernetes-admin 

For example, if the namespace created above is named namespace-test, the command is as follows:

# kubectl config set-context cci-context --namespace=namespace-test

After a namespace is specified, you can run kubectl commands to directly operate CCI resources. For example, run kubectl get pod to check pod resources. The result shows that all resources are normal.

# kubectl get pod
No resources found.