Notes and Constraints

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. For example, you cannot change a non-HA cluster (with one master node) to an HA cluster (with three master nodes).
  • 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.

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.
  • For clusters earlier than v1.19.10, if an HPA policy is used to scale out a workload with EVS volumes mounted, the existing pods cannot be read or written when a new pod is scheduled to another node.

    For clusters of v1.19.10 and later, if an HPA policy is used to scale out a workload with EVS volume mounted, a new pod cannot be started because EVS disks cannot be attached.

  • 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 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

There are resource quotas for your CCE clusters in each region.

Dependent Underlying Cloud Resources