Notes and Constraints
This section describes the notes and constraints on using CCE.
Clusters and Nodes
- After a cluster is created, the following items cannot be changed:
- Cluster type. For example, change a Kunpeng cluster to a CCE cluster.
- Number of master nodes in the cluster.
- AZ of a master node.
- Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, IPv6 settings, and kube-proxy (forwarding) settings.
- Network model. For example, change the tunnel network to the VPC network.
- Applications cannot be migrated between different namespaces.
- Currently, the created ECS instances (nodes) support the pay-per-use and yearly/monthly billing modes. Other resources (such as load balancers) support the pay-per-use billing mode. You can change the billing mode from pay-per-use to yearly/monthly on the management console for the created ECS instances.
- Nodes created during cluster creation support pay-per-use and yearly/monthly billing modes, but with the following constraints:
- If the cluster to be created is pay-per-use, the nodes created in the cluster must also be pay-per-use.
- If the cluster to be created is billed on a yearly/monthly basis, nodes in the cluster are either pay-per-use or billed on a yearly/monthly basis.
- If nodes added after cluster creation are billed on a yearly/monthly basis, they need to be renewed separately from the cluster.
Note: If you purchase a node after a cluster is created, the billing mode of the node is not restricted by that of the cluster.
- Underlying resources, such as ECSs (nodes), are limited by quotas and their inventory. Therefore, only some nodes may be successfully created during cluster creation, cluster scaling, or auto scaling.
- The ECS (node) specifications must be higher than 2 cores and 4 GB memory.
- To access a CCE cluster through a VPN, ensure that the VPN CIDR block does not conflict with the VPC CIDR block where the cluster resides and the container CIDR block.
Networking
- By default, a NodePort Service is accessed within a VPC. If you need to use an EIP to access a NodePort Service through public networks, bind an EIP to the node in the cluster in advance.
- LoadBalancer Services allow workloads to be accessed from public networks through ELB. This access mode has the following restrictions:
- It is recommended that automatically created load balancers not be used by other resources. Otherwise, these load balancers cannot be completely deleted, causing residual resources.
- Do not change the listener name for the load balancer in clusters of v1.15 and earlier. Otherwise, the load balancer cannot be accessed.
- Constraints on network policies:
- Only clusters that use the tunnel network model support network policies.
- Egresses are not supported for network policies.
- Network isolation is not supported for IPv6 addresses.
- For clusters of v1.13 and v1.15 that use the tunnel network model, if the node OS kernel is CentOS, you need to upgrade the Open vSwitch version before configuring network policies. For details, see Upgrading the OS Kernel.
- Constraints on network attachment definitions:
- The use of ENIs in clusters that use the VPC network model is restricted. You are advised to create a CCE Turbo cluster.
- Only clusters whose network model is VPC (with IPv6 disabled) support NADs. If the network model is tunnel network, only default-network is displayed in the list (cannot be modified) and you cannot add NADs.
- This function can be enabled only for clusters of v1.13.7-r0 or later. If clusters of earlier versions require the function, upgrade the clusters to the latest version.
Volumes
- Constraints on EVS volumes:
- By default, CCE creates EVS disks billed in pay-per-use mode. To use EVS disks billed in yearly/monthly mode, see Yearly/Monthly-Billed EVS Disks.
- EVS disks cannot be attached across AZs and cannot be used by multiple workloads, multiple pods of the same workload, or multiple jobs.
- Data in a shared disk cannot be shared between nodes in a CCE cluster. If the same EVS disk is attached to multiple nodes, read and write conflicts and data cache conflicts may occur. When creating a Deployment, you are advised to create only one pod if you want to use EVS disks.
- When you create a StatefulSet and add a cloud storage volume, existing EVS volumes cannot be used.
- EVS disks that have partitions or have non-ext4 file systems cannot be imported.
- Container storage in CCE clusters of Kubernetes 1.13 or later version supports encryption. Currently, E2E encryption is supported only in certain regions.
- EVS volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported.
- Constraints on SFS volumes:
- Container storage in CCE clusters of Kubernetes 1.13 or later version supports encryption. Currently, E2E encryption is supported only in certain regions.
- Volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported.
- Constraints on OBS volumes:
- CCE clusters of v1.7.3-r8 and earlier do not support OBS volumes. You need to upgrade these clusters or create clusters of a later version that supports OBS.
- Kunpeng clusters do not support obsfs. Therefore, parallel file systems cannot be mounted.
- Volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported.
- Constraints on SFS Turbo volumes:
Currently, SFS Turbo volumes cannot be directly created on CCE. You can create an SFS Turbo file system on the SFS Turbo console before using it on CCE.
- Constraints on snapshots and backups:
- The snapshot function is available only for clusters of v1.15 or later and requires the CSI-based everest add-on.
- The subtype (common I/O, high I/O, or ultra-high I/O), disk mode (SCSI or VBD), data encryption, sharing status, and capacity of an EVS disk created from a snapshot must be the same as those of the disk associated with the snapshot. These attributes cannot be modified after being queried or set.
Services
A Service is a Kubernetes resource object that defines a logical set of pods and a policy by which to access them.
A maximum of 6,000 Services can be created in each namespace.
CCE Cluster Resources
A fixed quota is allocated to each HUAWEI CLOUD CCE cluster in each region.
|
Item |
Constraints on Common Users |
Method to Go Beyond Limit |
|---|---|---|
|
Real-name authentication |
Mandatory |
None |
|
Total number of clusters in a region |
50 |
|
|
Number of nodes in a cluster (cluster management scale) |
You can select 50, 200, 1,000, or 2,000 nodes. A maximum of 5000 nodes are supported. |
|
|
Maximum number of container pods created on each worker node |
This number can be set on the console when you are creating a cluster. In the VPC network model, a maximum of 256 pods can be created. |
None |
Dependent Underlying Cloud Resources
|
Category |
Item |
Constraints on Common Users |
Method to Go Beyond Limit |
|---|---|---|---|
|
Compute |
Pods |
1,000 |
|
|
Cores |
8,000 |
||
|
RAM capacity (MB) |
16384000 |
||
|
VPCs per account |
5 |
||
|
Subnets per account |
100 |
||
|
Security groups per account |
100 |
||
|
Security group rules per account |
5000 |
||
|
Routes per route table |
100 |
None |
|
|
Routes per VPC |
100 |
None |
|
|
VPC peering connections per region |
50 |
None |
|
|
Network ACLs per account |
200 |
||
|
Layer 2 connection gateways per account |
5 |
||
|
Load balancing |
Elastic load balancers |
50 |
|
|
Load balancer listeners |
100 |
||
|
Load balancer certificates |
120 |
||
|
Load balancer forwarding policies |
500 |
||
|
Load balancer backend host group |
500 |
||
|
Load balancer backend server |
500 |
Last Article: High-Performance Scheduling
Next Article: Pricing Details
Did this article solve your problem?
Thank you for your score!Your feedback would help us improve the website.