- What's New
- Function Overview
- Service Overview
- Billing
- Getting Started
- User Guide
- Best Practices
-
Developer Guide
- Overview
- Using Native kubectl (Recommended)
- Namespace and Network
- Pod
- Label
- Deployment
- EIPPool
- EIP
- Pod Resource Monitoring Metric
- Collecting Pod Logs
- Managing Network Access Through Service and Ingress
- Using PersistentVolumeClaim to Apply for Persistent Storage
- ConfigMap and Secret
- Creating a Workload Using Job and Cron Job
- YAML Syntax
-
API Reference
- Before You Start
- Calling APIs
- Getting Started
- Proprietary APIs
-
Kubernetes APIs
- ConfigMap
- Pod
- StorageClass
- Service
-
Deployment
- Querying All Deployments
- Deleting All Deployments in a Namespace
- Querying Deployments in a Namespace
- Creating a Deployment
- Deleting a Deployment
- Querying a Deployment
- Updating a Deployment
- Replacing a Deployment
- Querying the Scaling Operation of a Specified Deployment
- Updating the Scaling Operation of a Specified Deployment
- Replacing the Scaling Operation of a Specified Deployment
- Querying the Status of a Deployment
- Ingress
- OpenAPIv2
- VolcanoJob
- Namespace
- ClusterRole
- Secret
- Endpoint
- ResourceQuota
- CronJob
-
API groups
- Querying API Versions
- Querying All APIs of v1
- Querying an APIGroupList
- Querying APIGroup (/apis/apps)
- Querying APIs of apps/v1
- Querying an APIGroup (/apis/batch)
- Querying an APIGroup (/apis/batch.volcano.sh)
- Querying All APIs of batch.volcano.sh/v1alpha1
- Querying All APIs of batch/v1
- Querying All APIs of batch/v1beta1
- Querying an APIGroup (/apis/crd.yangtse.cni)
- Querying All APIs of crd.yangtse.cni/v1
- Querying an APIGroup (/apis/extensions)
- Querying All APIs of extensions/v1beta1
- Querying an APIGroup (/apis/metrics.k8s.io)
- Querying All APIs of metrics.k8s.io/v1beta1
- Querying an APIGroup (/apis/networking.cci.io)
- Querying All APIs of networking.cci.io/v1beta1
- Querying an APIGroup (/apis/rbac.authorization.k8s.io)
- Querying All APIs of rbac.authorization.k8s.io/v1
- Event
- PersistentVolumeClaim
- RoleBinding
- StatefulSet
- Job
- ReplicaSet
- Data Structure
- Permissions Policies and Supported Actions
- Appendix
- Out-of-Date APIs
- Change History
-
FAQs
- Product Consulting
-
Basic Concept FAQs
- What Is CCI?
- What Are the Differences Between Cloud Container Instance and Cloud Container Engine?
- What Is an Environment Variable?
- What Is a Service?
- What Is Mcore?
- What Are the Relationships Between Images, Containers, and Workloads?
- What Are Kata Containers?
- Can kubectl Be Used to Manage Container Instances?
- What Are Core-Hours in CCI Resource Packages?
- Workload Abnormalities
-
Container Workload FAQs
- Why Service Performance Does Not Meet the Expectation?
- How Do I Set the Quantity of Instances (Pods)?
- How Do I Check My Resource Quotas?
- How Do I Set Probes for a Workload?
- How Do I Configure an Auto Scaling Policy?
- What Do I Do If the Workload Created from the sample Image Fails to Run?
- How Do I View Pods After I Call the API to Delete a Deployment?
- Why an Error Is Reported When a GPU-Related Operation Is Performed on the Container Entered by Using exec?
- Can I Start a Container in Privileged Mode When Running the systemctl Command in a Container in a CCI Cluster?
- Why Does the Intel oneAPI Toolkit Fail to Run VASP Tasks Occasionally?
- Why Are Pods Evicted?
- Why Is the Workload Web-Terminal Not Displayed on the Console?
- Why Are Fees Continuously Deducted After I Delete a Workload?
-
Image Repository FAQs
- Can I Export Public Images?
- How Do I Create a Container Image?
- How Do I Upload Images?
- Does CCI Provide Base Container Images for Download?
- Does CCI Administrator Have the Permission to Upload Image Packages?
- What Permissions Are Required for Uploading Image Packages for CCI?
- What Do I Do If Authentication Is Required During Image Push?
-
Network Management FAQs
- How Do I View the VPC CIDR Block?
- Does CCI Support Load Balancing?
- How Do I Configure the DNS Service on CCI?
- Does CCI Support InfiniBand (IB) Networks?
- How Do I Access a Container from a Public Network?
- How Do I Access a Public Network from a Container?
- What Do I Do If Access to a Workload from a Public Network Fails?
- What Do I Do If Error 504 Is Reported When I Access a Workload?
- What Do I Do If the Connection Timed Out?
- Storage Management FAQs
- Log Collection
- Account
- SDK Reference
- Videos
- General Reference
Copied.
Namespace
Namespaces are used to logically divide your resources into different groups, especially in scenarios where a large number of users work across multiple projects.
Currently, CCI provides general-computing resources. When creating a namespace, you must choose a resource type so that workloads you create can run in the corresponding cluster.
- General-computing: Pods with vCPUs can be created, which are ideal for general computing scenarios.
- One account can create a maximum of five namespaces in one region.
- 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.
Application Scenarios
Namespaces can implement partial environment isolation. If you have a large number of projects and personnel, you can create different namespaces based on project attributes, such as production, test, and development.
Creating a Namespace
- Log in to the CCI console. In the navigation pane on the left, choose Namespaces.
- On the page displayed on the right, click Create for the target namespace type.
- Enter a name for the namespace.
NOTE:
The namespace name must be globally unique in CCI.
- 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.
NOTE:
- Skip this step if Enterprise Project Management Service is not enabled. To enable the service, see Enabling Enterprise Center. If you are an IAM user, pay attention to the notice provided in (Optional) Uploading Images.
- 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.
- 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.
NOTICE:
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 subnetNOTE:
- 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 8.
- 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.
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.
Creating a Namespace Using kubectl
For details, see Namespace and Network.
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