Notes and Constraints

Clusters and Nodes

• After a cluster is created, the following items cannot be changed:
  • 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.
• 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. 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. Network policies are classified into the following types:
    • Ingress: All versions support this type.
    • Egress: This rule type cannot be set currently.
  • Network isolation is not supported for IPv6 addresses.

Volumes

• Constraints on EVS volumes:
  • 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.
  • 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