Namespace
Namespace
Namespaces are a method of allocating resources among users. They are especially useful for users from different teams or projects. When there are many projects and personnel, you can create different namespaces based on project attributes (such as production, test, and development) to isolate the environment.
Constraints
- An account can create a maximum of five namespaces in a region, and the namespace name must be globally unique.
- General-computing resources support x86-based images.
Relationship Between Namespaces and Networks
Each namespace requires a separate subnet, as shown in Figure 1. When you create a namespace, you need to associate it with an existing VPC or a new VPC. If you create a VPC, create a subnet for the namespace. Containers and other resources created in this namespace will run in the VPC and subnet you select.
If you want to run resources of multiple services in the same VPC, you need to consider network planning, including subnet CIDR block division and IP address planning.
Creation Method
You can create a namespace through the console or using kubectl.
Creating a Namespace on the Console
- Log in to the CCI console. In the navigation pane on the left, choose Namespaces.
- CCI only provides General computing resources. Click Create.
Table 1 CCI pod types Pod Type
Description
General-computing pods
Pods with vCPUs can be created, which are ideal for general computing scenarios
- On the page displayed on the right, click Create for the target namespace type.
- Enter a name for the namespace.
- Set RBAC policies. After RBAC is enabled, the access to resources in the namespace is controlled by the RBAC policies. For details, see Namespace Permissions.
- Select an enterprise project. In CCI, each namespace can belong to one enterprise project, but an enterprise project can have multiple namespaces.
- After Enterprise Management is enabled, if an IAM user needs to use private images in your account, you need to log in to the CCI console using the account, choose Image Repository, and grant the required permission to the user on the SWR console. You can use either of the following methods to grant permission to an IAM user:
- On the details page of an image, click the Permissions tab, click Add Permission, and then grant the read, write, and manage permissions to the user. For details, see Granting Permissions of a Specific Image.
- On the details page of an organization, click the Users tab, click Add Permission, and then grant the read, write, and manage permissions to the user. For details, see Granting Permissions of an Organization.
- After you specify an enterprise project, both the namespace and the network and storage resources that are automatically created for the namespace belong to the enterprise project. You must migrate these resources together with the namespace. For example, when you migrate a namespace from project 1 to project 2, you must also migrate the associated network and storage resources to project 2, or the workloads in this namespace may not run normally.
- After Enterprise Management is enabled, if an IAM user needs to use private images in your account, you need to log in to the CCI console using the account, choose Image Repository, and grant the required permission to the user on the SWR console. You can use either of the following methods to grant permission to an IAM user:
- Configure a VPC.
You can use an existing VPC or create a VPC. If you create a VPC, it is recommended that you set the VPC CIDR block to 10.0.0.0/8–22, 172.16.0.0/12–22, or 192.168.0.0/16–22.
- You must not set the VPC CIDR block and subnet CIDR block to 10.247.0.0/16, because this CIDR block is reserved for workload access. If you select this CIDR block, IP address conflicts may occur, which may result in failure to create a workload or service unavailability. If you do not need to access pods through workloads, you can select this CIDR block.
- After the namespace is created, you can view VPC and subnet information by choosing Network Management > Networks.
- Configure a subnet CIDR block.
Ensure sufficient available IP addresses to create workloads.
Figure 2 Configuring a subnet- Some IP addresses (10 by default) in the configured subnet will be warmed up for the created namespace.
- You can set the number of IP addresses to be warmed up in 9.
- Warming up IP addresses for the created namespace affects the deletion of the configured subnet and VPC. They can be deleted only after the namespace is deleted.
- Configure advanced settings.
Each namespace provides an IP resource pool. You can customize the pool size to reduce the duration for applying for IP addresses and improve the workload creation efficiency.
For example, 200 pods are running every day. During peak traffic hours, the IP resource pool instantly scales out to provide 500 IP addresses. After a specified interval (for example, 23 hours), the number of IP addresses that exceed the pool size (500 – 200 = 300) will be reclaimed.
Figure 3 Configuring advanced settings- IP Pool Warm-up for Namespace: CCI creates an IP pool with the number of IP addresses you specify here for the namespace, and will warm up these IP addresses to accelerate workload creation. The IP pool can contain a maximum of 500 IP addresses.
- IP Address Recycling Interval (h): Warmed-up IP addresses that become idle can be recycled within the duration that you specify here.
- Container Network: Enable this option if you want CCI to start the container network in advance so that containers can connect to the network as soon as they are started.
- Click Create.
After the creation is complete, you can view the VPC and subnet information on the namespace details page.
Follow-up Operations
- Namespace and networks in CCI must be associated with security groups.
- When you create a namespace on the CCI console, a security group with the prefix kubernetes.io-default-sg is created and associated with the namespace. To ensure normal customer services, the security group allows all IP addresses to access the workload port. So traffic is allowed over some typical ports, such as ports 22, 443, and 3389.
- The security group for the workloads scheduled from CCE to CCI inherits the security group configuration for the CCE cluster.
- To improve security, you can change the security group rules to allow access only from specified IP address ranges. Exercise caution when performing this operation in the actual scenarios.
- If the workload uses HTTP GET requests for health check, all subnets in the VPC must be allowed to access the workload. If the VPC CIDR block is 192.168.0.0/16, this CIDR block must be allowed to access the workload.
- If there is a VPC endpoint in the VPC, allow traffic from the CIDR block of the VPC endpoint to the workload. For details, see What Should I Do If the VPC Endpoint I Purchased Cannot Connect to a VPC Endpoint Service?
- If ELB is required and a Service or ingress is configured, allow traffic from the load balancer to the workload. For details, see Why Are Backend Servers Frequently Accessed by IP Addresses in 100.125.0.0/16 or 214.0.0.0/8?
- Delete the namespace by following the instructions in section Deleting a Namespace.
Deleting a Namespace

Deleting a namespace will remove all data resources related to the namespace, including workloads, ConfigMaps, secrets, and SSL certificates.
- Log in to the CCI console. In the navigation pane on the left, choose Namespaces. On the page displayed, click the namespace you want to delete.
- In the upper right corner, click Delete. In the dialog box that is displayed, enter DELETE and click Yes.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot