Creating a Node Pool

Scenario

This section describes how to create a node pool and perform operations on the node pool. For details about how a node pool works, see Node Pool Overview.

Notes and Constraints

• The autoscaler add-on needs to be installed for node auto scaling. For details about the add-on installation and parameter configuration, see autoscaler.
• Auto scaling is available only for pay-per-use node pools, not for those billed by year or month. Changing nodes in a pay-per-use node pool to yearly/monthly may cause auto scaling to fail. You need to migrate these nodes to DefaultPool by following the instructions in Migrating a Node.

Procedure

To create a node pool in a cluster, perform the following steps:

1. Log in to the CCE console. In the navigation pane, choose Resource Management > Node Pools.
2. In the upper right corner of the page, click Create Node Pool.
3. Set node pool parameters.
   • Billing Mode

     Only pay-per-use is supported. In this billing mode, resources are billed by hour.

     After a node pool is created, the billing mode of resources in the created node pool cannot be changed to the yearly/monthly billing, while this change is allowed for resources in the default node pool. You can migrate resources from a self-built node pool to the default node pool and then change the billing mode to yearly/monthly billing. For details, see Migrating a Node.

   • Current Region: geographic location of the node pool to be created.

     To minimize network latency and resource access time, select the region nearest to your node pool. Cloud resources are region-specific and cannot be used across regions over internal networks.

   • Name: name of the new node pool. By default, the name is in the format of Cluster name-nodepool-Random number. You can also use a custom name.
   • Node Type: Currently, only VM nodes are supported.
   • Nodes: number of nodes to be purchased for this node pool. The value cannot exceed the maximum number of nodes that can be managed by the cluster.
   • Auto Scaling:
     • By default, this parameter is disabled.
     • After you enable autoscaler by clicking , nodes in the node pool will be automatically created or deleted based on cluster loads.
       • Maximum Nodes and Minimum Nodes: You can set the maximum and minimum number of nodes to ensure that the number of nodes to be scaled is within a proper range.
       • Priority: Set this parameter based on service requirements. A larger value indicates a higher priority. For example, if this parameter is set to 1 and 4 respectively for node pools A and B, B has a higher priority than A. If the priorities of multiple node pools are set to the same value, for example, 2, the node pools are not prioritized and the system performs scaling based on the minimum resource waste principle.
         

         CCE selects a node pool for auto scaling based on the following policies:

         1. CCE uses algorithms to determine whether a node pool meets the conditions to allow scheduling of a pod in pending state, including whether the node resources are greater than requested by the pod, and whether the nodeSelect, nodeAffinity, and taints meet the conditions. In addition, the node pools that fail to be scaled (due to insufficient resources or other reasons) and are still in the 15-minute cool-down interval are filtered.
         2. If multiple node pools meet the scaling requirements, the system checks the priority of each node pool and selects the node pool with the highest priority for scaling. The value ranges from 0 to 100 and the default priority is 0. The value 100 indicates the highest priority, and the value 0 indicates the lowest priority.
         3. If multiple node pools have the same priority or no priority is configured for them, the system selects the node pool that will consume the least resources based on the configured VM specification.
         4. If the VM specifications of multiple node pools are the same but the node pools are deployed in different AZs, the system randomly selects a node pool to trigger scaling.
       • Scale-In Cooling Interval: Set this parameter in the unit of minute or hour. This parameter indicates the interval between the previous scale-out action and the next scale-in action.

         Scale-in cooling intervals can be configured in the node pool settings and the autoscaler add-on settings.

         Scale-in cooling interval configured in a node pool

         This interval indicates the period during which nodes added to the current node pool after a scale-out operation cannot be deleted. This interval takes effect at the node pool level.

         Scale-in cooling interval configured in the autoscaler add-on

         The interval after a scale-out indicates the period during which the entire cluster cannot be scaled in after the autoscaler add-on triggers scale-out (due to the unschedulable pods, metrics, and scaling policies). This interval takes effect at the cluster level.

         The interval after a node is deleted indicates the period during which the cluster cannot be scaled in after the autoscaler add-on triggers scale-in. This interval takes effect at the cluster level.

         The interval after a failed scale-in indicates the period during which the cluster cannot be scaled in after the autoscaler add-on triggers scale-in. This interval takes effect at the cluster level.

       

       You are advised not to store important data on nodes in a node pool because after auto scaling, data cannot be restored as nodes may be deleted.

       If Autoscaler is enabled, install the autoscaler add-on to use the auto scaling feature.

   • AZ: An AZ is a physical region where resources use independent power supply and networks. AZs are physically isolated but interconnected through an internal network.

     Set an AZ based on your requirements. After a node pool is created, AZ cannot be modified. Exercise caution when selecting an AZ for the node pool.

     To enhance workload reliability, you are advised to select Random AZ, allowing nodes to be randomly and evenly distributed among different AZs.

   • Specifications: Select the node specifications based on service requirements. The available node specifications vary depending on AZs.

     To ensure node stability, CCE automatically reserves some resources to run necessary system components. For details, see Formula for Calculating the Reserved Resources of a Node.

   • OS: Select an OS for the node to be created.
     • Public image: Select an OS for the node.
     • Private image (OBT): If no private image is available, click Creating a Private Image to create one. This function is available only for clusters of v1.15 or later.
     

     Reinstalling the OS or modifying OS configurations could make the node unavailable. Exercise caution when performing these operations.

   • VPC: The value is the same as that of the cluster and cannot be changed.

     This parameter is displayed only for clusters of v1.13.10-r0 and later.

   • Subnet: A subnet improves network security by providing exclusive network resources that are isolated from other networks.

     You can select any subnet in the cluster VPC. Cluster nodes can belong to different subnets.

     Ensure that the DNS server in the subnet can resolve the OBS domain name. Otherwise, nodes cannot be created.

     This parameter is displayed only for clusters of v1.13.10-r0 and later.

   • System Disk: Set the system disk space of the worker node. The value ranges from 40GB to 1024 GB. The default value is 40GB.

     By default, system disks support High I/O (SAS) and Ultra-high I/O (SSD) EVS disks.

   • Data Disk: Set the data disk space of the worker node. The value ranges from 100 GB to 32,768 GB. The default value is 100 GB. The EVS disk types provided for the data disk are the same as those for the system disk.
     

     If the data disk is uninstalled or damaged, the Docker service becomes abnormal and the node becomes unavailable. You are advised not to delete the data disk.

     • LVM: If this option is selected, CCE data disks are managed by the Logical Volume Manager (LVM). On this condition, you can adjust the disk space allocation for different resources. This option is selected for the first disk by default and cannot be unselected. You can choose to enable or disable LVM for new data disks.
       • This option is selected by default, indicating that LVM management is enabled.
       • You can deselect the check box to disable LVM management.
         

         • Disk space of the data disks managed by LVM will be allocated according to the ratio you set.
         • When creating a node in a cluster of v1.13.10 or later, if LVM is not selected for a data disk, follow instructions in Adding a Second Data Disk to a Node in a CCE Cluster to fill in the pre-installation script and format the data disk. Otherwise, the data disk will still be managed by LVM.
         • When creating a node in a cluster earlier than v1.13.10, you must format the data disks that are not managed by LVM. Otherwise, either these data disks or the first data disk will be managed by LVM.
     • Add Data Disk: Currently, a maximum of two data disks can be attached to a node. After the node is created, you can go to the ECS console to attach more data disks. This function is available only to clusters of certain versions.
     • Data disk space allocation: Click to specify the resource ratio for Kubernetes Space and User Space. Disk space of the data disks managed by LVM will be allocated according to the ratio you set. This function is available only to clusters of certain versions.
       • Kubernetes Space: You can specify the ratio of the data disk space for storing Docker and kubelet resources. Docker resources include the Docker working directory, Docker images, and image metadata. kubelet resources include pod configuration files, secrets, and emptyDirs.

         The Docker space cannot be less than 10%, and the space size cannot be less than 60 GB. The kubelet space cannot be less than 10%.

         The Docker space size is determined by your service requirements. For details, see Data Disk Space Allocation.

       • User Space: You can set the ratio of the disk space that is not allocated to Kubernetes resources and the path to which the user space is mounted.
         

         Note that the mount path cannot be /, /home/paas, /var/paas, /var/lib, /var/script, /var/log, /mnt/paas, or /opt/cloud, and cannot conflict with the system directories (such as bin, lib, home, root, boot, dev, etc, lost+found, mnt, proc, sbin, srv, tmp, var, media, opt, selinux, sys, and usr). Otherwise, the system or node installation will fail.

     

     • The ratio of disk space allocated to the Kubernetes space and user space must be equal to 100% in total. You can click to refresh the data after you have modified the ratio.
     • By default, disks run in the direct-lvm mode. If data disks are removed, the loop-lvm mode will be used and this will impair system stability.
   • Login Mode: You can use a password or key pair.
     • Password: The default username is root. Enter the password for logging in to the node and confirm the password.

       Be sure to remember the password as you will need it when you log in to the node.

     • Key pair: Select the key pair used to log in to the node. You can select a shared key.

       A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create a key pair.

       

       When creating a node using a key pair, IAM users can select only the key pairs created by their own, regardless of whether these users are in the same group. For example, user B cannot use the key pair created by user A to create a node, and the key pair is not displayed in the drop-down list on the CCE console.

       Figure 1 Key pair
       

4. Advanced ECS Settings (optional): Click to show advanced ECS settings.
   • ECS Group: An ECS group logically groups ECSs. The ECSs in the same ECS group comply with the same policy associated with the ECS group.
     • Anti-affinity: ECSs in an ECS group are deployed on different physical hosts to improve service reliability.

     Select an existing ECS group, or click Create ECS Group to create one. After the ECS group is created, click the refresh button.

   • Resource Tags: By adding tags to resources, you can classify resources.

     You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use predefined tags to improve tag creation and migration efficiency.

     CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag. A maximum of 5 tags can be added.

   • Agency: An agency is created by a tenant administrator on the IAM console. By creating an agency, you can share your cloud server resources with another account, or entrust a more professional person or team to manage your resources. To authorize an ECS or BMS to call cloud services, select Cloud service as the agency type, click Select, and then select ECS BMS.
   • Pre-installation Script: Enter a maximum of 1,000 characters.

     The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed. The script is usually used to format data disks.

   • Post-installation Script: Enter a maximum of 1,000 characters.

     The script will be executed after Kubernetes software is installed and will not affect the installation. The script is usually used to modify Docker parameters.

   • Subnet IP Address: Select Automatically assign IP address (recommended) or Manually assigning IP addresses.
     

     When you manually assign IPs, the master IP is randomly specified. Therefore, it may conflict with the worker node IP. If you prefer the manual operation, you are advised to select a subnet CIDR block different from that of the master node when setting worker node subnet.

5. Advanced Kubernetes Settings (optional): Click to show advanced Kubernetes settings.
   • Max Pods: maximum number of pods that can be created on a node, including the system's default pods. If the cluster uses the VPC network model, the maximum value is determined by the number of IP addresses that can be allocated to containers on each node.

     This limit prevents the node from being overloaded by managing too many pods. For details, see Maximum Number of Pods That Can Be Created on a Node.

   • Taints: This field is left blank by default. Taints allow nodes to repel a set of pods. You can add a maximum of 10 taints for each node. Each taint contains the following parameters:
     • Key: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
     • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
     • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
     

     • If taints are used, you must configure tolerations in the YAML files of pods. Otherwise, scale-up may fail or pods cannot be scheduled onto the added nodes.
     • After a node pool is created, you can click Edit to modify its configuration. The modification will be synchronized to all nodes in the node pool.
   • K8S Labels: Labels are key/value pairs that are attached to objects, such as pods. Labels are used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. For more information, see Labels and Selectors.
   • Maximum Data Space per Container: maximum data space that can be used by a container. The value ranges from 10 GB to 500 GB. If the value of this field is larger than the data disk space allocated to Docker resources, the latter will override the value specified here. Typically, 90% of the data disk space is allocated to Docker resources. This parameter is displayed only for clusters of v1.13.10-r0 and later.

6. (Optional) Click on the left to add multiple node pools. You can view the available node pool quotas under the button.
7. Click Next: Confirm to confirm the configured service parameters, fees, and specifications.
8. Click Submit.

   It takes about 6 to 10 minutes to create a node pool. You can click Back to Node Pool List to perform other operations on the node pool or click Go to Node Pool Events to view the node pool details. If the status of the node pool is Normal, the node pool is successfully created.

Viewing Node Pools in a Cluster

1. Log in to the CCE console. In the navigation pane, choose Resource Management > Node Pools.
2. In the upper right corner of the node pool list, select a cluster. All node pools in the cluster will be displayed. You can view the node type, node specifications, autoscaler status, and OS of each node pool.
   Figure 2 Viewing node pools in a cluster
   
   

   • A default node pool DefaultPool is automatically created in each cluster. The default node pool cannot be edited, deleted, or migrated. All nodes created during and after cluster creation are displayed in the default node pool.
   • To display a list of nodes in DefaultPool, click the Nodes subcard in the DefaultPool card.

3. To filter node pools by autoscaler status, select the autoscaler status in the upper right corner of the node pool list.
4. In the node pool list, click a node pool name. On the node pool details page, view the basic information, advanced ECS settings, advanced Kubernetes settings, and node list of the node pool.
   Figure 3 Node pool details