Docs

Volcengine Kubernetes Engine

Node pool

Managing node pools

After you create node pools in a cluster, you can go to the node pool management page to manage them. This topic describes the scenarios, impacts, and procedures for node pool operations.

Editing node pools

You can modify configurations related to the node pool, including basic information, worker nodes, system, and security configurations.

tip

The default node pool vke-default-nodepool is not editable in node pool information, worker nodes, and system configurations.

Except for the parameters that are explicitly described as only effective for new nodes, the rest are either for the node pool or for both existing and new nodes. For details, see the description for each parameter.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Click Edit in the Actions column that corresponds to the target node pool to edit parameters based on the following descriptions. After you edit parameters, click Confirm.

Parameter	Description
Node pool information
Name	Modify the node pool name based on the naming rules prompted by the system. A node pool name must be unique within the same cluster.
Billing method	The billing method of the nodes in the current node pool. You can change the billing method from Subscription to Pay-as-you-go for a node pool. You can change the billing method from Pay-as-you-go to Subscription for a node pool when the following conditions are met: Autoscaling is disabled. The elastic scheduled scale-out rule is disabled. Spot instance: This billing type cannot be changed. tip After you change Pay-as-you-go to Subscription, you also need to specify the Duration of purchase parameter, the Automatic renewal parameter, and the Automatic renewal duration parameter. After you update the billing method, billing duration, or other configurations of nodes, the new configurations will only take effect on newly added nodes. For existing nodes, go to the ECS console to manually modify their configurations.
Check and self-healing	You can edit this parameter for a managed node pool. Specify whether to enable the node check and self-healing feature. Enable: By configuring node self-healing rules, the system automatically checks for kubelet and runtime failures, GPU card status, and other node failures. When a node fails, the system promptly cordons the node to prevent Pods from being scheduled to it. For more information, see Check and self-healing overview. Disable: Does not enable this feature. This is the default setting.
Check and self-healing rules	After you enable node check and self-healing, you can specify node self-healing rules. If you have not configured a self-healing rule, click Create check and self-healing rule to create one. For details, see Configuring check and self-healing for nodes in a node pool.
Autoscaler	Modify the enabling status and related configurations of the node pool. Number of nodes: the nodes in this pool will be adjusted by the autoscaler dynamically within the range you set here. Enter integers from 0 to 2000. If the nodes actually required exceed the total node quota of the cluster, you can log in to Quota center to apply for a higher node quota. Priority: When the elastic scale-out algorithm uses the priority strategy, scale-out is performed on the node pool with a higher priority. The larger the number, the higher the priority. Valid values: 0 to 100.
Node subnet	Update the subnets of the node pool by adding one or more subnets within the following scope to provide network support for the nodes: If the cluster uses the VPC-CNI network mode, all subnets in the subnet availability zone of the cluster will be displayed. If the cluster uses the Flannel network mode, all subnets in the VPC where the cluster is located are displayed. warning You cannot modify the configurations of configured subnets. You can add subnets based on existing subnets. You can drag and drop subnets to reorder them as needed. A node pool can be associated with up to eight subnets.
Instance type	The list of available instance types in the current subnet. Select an instance type based on your business requirements. For detailed descriptions of instance types, see Instance specification list. warning After you update the instance type of the node pool, new nodes will be added based on the updated instance type during scale-out. Existing nodes of the original instance type are not affected. An instance type may be unselectable for the following reasons: ECS resources of this type are no longer available for purchase. Instance types cannot span CPU/GPU categories or different GPU vendors.
Selected Specifications	The selected instance specifications for nodes in the node pool. You can select up to 10 instance specifications. tip If you select multiple instance types, the system sorts node specifications in the order in which they are selected. When Cluster Autoscaler (CA) scales nodes, it first chooses an instance specification with higher priority in the sequence of the instance specifications. When higher-priority specifications cannot be provisioned due to insufficient inventory or other failures, the system sequentially switches to lower-priority specifications for scale-out. If you use Karpenter to implement auto scaling, the node pool scales out with nodes of various specifications based on resource requirements. For details, see Configuring instant autoscaling (Karpenter). You can prioritize instance specifications in the list. To do so, hover over the icon before the sequence number of an instance specification, and then drag and drop it to the desired position.
Pricing	This parameter is displayed after Billing method is set to Spot instance. Pricing of spot instances: Auto-bid: Uses the pay-as-you-go instance type price as the upper limit. This means that the real-time market price is always used as the billing settlement price of the spot instance. When resource supply and demand change, the instance is automatically released. Back up your data in advance. Set single-instance price cap: Sets the highest price that you accept for the instance. This price only indicates your purchase intention. The market price is still used for billing settlement. After an instance is purchased, if the market price exceeds your bid or if resource supply and demand change, the instance is automatically released. Back up your data in advance. tip Updating the pricing of spot instances takes effect only for newly added nodes. Existing nodes are not affected. We recommend using this parameter together with the Spot instance compensation parameter in the Advanced settings section to perform data backup and other operations when instances are released.
High-performance computing cluster	This parameter is available if you select High Performance Computing Optimized for Instance type. Select the HPC cluster and project for the HPC-optimized nodes. If no HPC cluster is available, click Create high-performance computing cluster to create one. warning The availability zone of the selected HPC cluster must be within the availability zone of the current node pool subnet.
Project of ECS instances	Specify the owning project for the ECS instances corresponding to nodes in the node pool. This allows operations and maintenance, authorization, resource management, and other actions on the ECS instances at the project level. For more project operations and details, see Project management. warning After the update, the project only takes effect on newly added nodes in the node pool. Existing nodes still belong to the previous project.
Buy affinity group	[Beta - apply for trial] This parameter is displayed only after an instance type that supports affinity groups is selected or Buy affinity group is enabled for the node pool. You can modify the status of Buy affinity group only if no nodes exist in the node pool. When the affinity group feature is not enabled for the node pool, if the number of nodes in the node pool is 0 and you select an ECS specification that supports affinity groups, you can enable Buy affinity group. Otherwise, you cannot enable it. When the affinity group feature is enabled for the node pool, if the number of nodes in the node pool is 0 and you select an ECS specification that supports affinity groups, you can disable Buy affinity group or modify Affinity group size. Otherwise, you cannot perform the preceding operations. warning To obtain the list of ECS instance types that support affinity groups, contact your Volcano Engine account manager. Node pools purchased as an affinity group are subject to the following constraints: You cannot select multiple instance types. You cannot enable autoscaling. Only instances that use the pay-as-you-go or subscription billing methods are supported. Spot instances and elastic scheduled instances are not supported. You need to set Number of nodes to an integer multiple of Affinity group size subsequently.
More configurations
Node pool tags	Custom tags for classifying, retrieving, and aggregating node pools with similar characteristics from different dimensions. Node pool tags enable you to manage node pools more flexibly and efficiently.
Scheduling policy for multi-subnets	Specify scheduling priorities for multiple subnets in the node pool. Worker nodes are scheduled based on the subnet priority during scale-out. The following two policies are available: Balancing policy: Newly added nodes during a scale-out are evenly distributed across multiple subnets. Under this policy, the order of subnets does not matter. Subnet priority: The subnets that appear earlier in the sequence have higher priorities. During scaling, nodes are first added to subnets with higher priority.
Network communication mode	[Beta · Apply for trial] The network communication mode between nodes. Valid values: TCP communication mode and RDMA communication mode. TCP communication mode: A communication method for data transmission based on Transmission Control Protocol (TCP). RDMA communication mode: A communication method for data transmission based on Remote Direct Memory Access (RDMA). This enables faster data transmission and improved communication efficiency and is suitable for applications that require large-scale data transfer and high-performance network communication. tip Only instance types with vRDMA NICs can use the RDMA communication mode. After you update the network communication mode, the new configurations only take effect on newly added nodes.
ECS tags	VKE binds Volcano Engine platform labels to new ECS instances to facilitate searching and management. tip The updated ECS labels only take effect on nodes that are subsequently added to the node pool. The ECS labels added to existing nodes are not affected.
System configuration
Operating system	Select an operating system image for nodes based on your business requirements. Valid values: Public images, Custom images, and Shared images. Public images: official, copyrighted images provided by Volcano Engine. These images combine basic OS with initialization components, delivering security, high availability, and open access for all users. For the public images supported by VKE and the associated specification families, see Public images supported by VKE. Custom images: Images created and uploaded by you. In addition to the operating system, the images also have public or private applications pre-installed. These images are suitable for redeploying complex initialization systems or deploying multiple systems with the same configurations. Note that custom image support is in beta. To use custom images, apply for a trial first. VKE allows you to specify custom images as node operating systems. For more details, see Overview of operating system images. Shared images: images shared by other Volcano Engine users. You can use a shared image to quickly deploy a software environment the same as that created by other users. Conversely, you can share your custom image with other Volcano Engine users. warning You need to create custom images and shared images by using VKE base images. Check whether a GPU version is required based on your business requirements. Custom images are available at the Project of the node pool level. Changing the operating system only takes effect on newly added nodes, and does not affect existing nodes.
Security reinforcement	Update the status of Security reinforcement. On (default): The host-based intrusion detection system (HIDS) provides free alerting capabilities targeting risks such as abnormal login attempts. While ensuring compatibility of the operating system image, it offers security hardening features for nodes (ECS instances). These features include real-time monitoring, file monitoring, process monitoring, and dynamic system analysis. Off: The security hardening feature is not enabled. tip Changing the status of Security reinforcement only takes effect on the nodes that are subsequently added to the node pool, and does not take effect on existing nodes.
Storage	Configure storage for the node pool. You need to configure the following parameters: System volume: Provides the storage space required for the operating system and log storage. tip Available volume types may vary by region. For a list of volume types, see Volume specifications. ESSD offers multiple performance levels. Different ESSD performance levels provide varying specifications for metrics including maximum IOPS, maximum throughput, and latency. local disks: [Beta - apply for trial] Some instance specifications allow you to mount local disks. For instance specifications that support local disks, see Instance specifications. tip The data reliability of local disks depends on the reliability of the physical servers. Using local disks may introduce data loss risks. If the application layer does not include a data redundancy mechanism, we recommend using data volumes for business data storage. Data volume: Provides additional storage space required for data storage in daily operations. A single node can have up to 15 data volumes. Available volume types may vary by region. For a list of volume types, see Volume specifications. tip ESSD offers multiple performance levels. Different ESSD performance levels provide varying specifications for metrics including maximum IOPS, maximum throughput, and latency. Format and mount the volume to /var/lib/containerd and /var/lib/kubelet. By default, the first data volume supports formatting and mounting for use by the /var/lib/containerd and /var/lib/kubelet directories, which are related to containers, images, and the kubelet. If you do not select this option, the /var/lib/containerd and /var/lib/kubelet directories will be mounted to the partition in the system volume where the operating system is running. Monitor the remaining capacity in the system volume. Specify mount directory. This option is not selected by default. To mount a data volume to a specific directory, select the check box and specify the directory. For example, if the mount directory is /vke, when the first volume is formatted and mounted to the /var/lib/containerd and /var/lib/kubelet directories, the two directories will be bind-mounted to /vke/var/lib/containerd and /vke/var/lib/kubelet, respectively. Description Changing the mount directory only takes effect on newly added nodes, and does not affect existing nodes. File system: [Beta - apply for trial] Select a file system for the data volume. You can select Ext4 or Xfs. Use snapshots to create EBS: Use an existing snapshot to create a data volume. This option allows you to quickly copy the data from the snapshot to the new data volume. For more details, see Creating snapshots, Creating volumes through snapshots, and Accelerating node scale-out by using data volume snapshots. tip Only data volume snapshots in the Available state are supported.
Security configuration
Security group	The default security group of the cluster cannot be modified or deleted. The name of the security group is in the format of <cluster ID>-common. For more information on the default security group for clusters, see Security group settings. If you need to configure or modify custom security groups, make sure that they do not conflict with the default security group rules of the cluster. For recommended scopes and minimum scopes of custom access rules in security groups, see Cluster access rules. tip A single node pool can be associated with up to four custom security groups. When you configure custom security groups, you cannot select the managed security groups of VPCs. For more information about managed security groups, see Security group overview.
Node access configuration	Updating the login method for nodes that are subsequently added to the node pool does not affect existing nodes. If you select this option, it indicates that the login credentials and corresponding password or SSH key pair for subsequently added nodes will be modified. Password: You use a password to log in as a root user. If you select this option, set a root password and confirm it. SSH key pair: You use an SSH key pair (a public key and a private key) to log in to nodes. This login method is more secure and available only to Linux instances. If there are no SSH key pairs available, click Create key pair at the bottom of the Key pair dropdown menu to create one. For an introduction to key pairs, see Key pairs.
Advanced settings
Node labels	Add or remove node labels. Labels are used to define various attributes of nodes, facilitating batch filtering and other operations. warning Custom node taints cannot conflict with system taints. For details of system labels, see System labels and taints.
Node taints	Add or remove node taints. Taints allow nodes to repel specific pods and therefore prevent those pods from being scheduled to the nodes. warning Custom node taints cannot conflict with system taints. For a list of system taints, see System labels and taints.
Enable auto renew for node labels and taints	Configure automatic updating for node labels and taints. Selected (default): enables automatic updating. The labels or taints added to or modified in a node pool will be automatically synchronized to both the existing and new nodes. In addition, if you modify the labels or taints for existing nodes, the configurations of the nodes will be overwritten by the configurations of the node pool. Cleared: does not enable automatic updating. The labels or taints added to or modified in a node pool will be synchronized only to the new nodes, but not the existing ones. In addition, if you modify the labels and taints for existing nodes, the modified configurations take effect and will not be overwritten by the configurations of the node pool. warning Disabling automatic updating for node labels and taints may cause anomalies on features that use fixed node labels. You need to proceed with caution.
Kubelet configs	Specify custom kubelet parameters for nodes in the node pool to adjust node behavior. For details, see Configuring kubelet parameters for a node pool.
Containerd configuration	Node pools support custom containerd configuration, which includes the Container Registry proxy address for container images and disabling self-signed certificate verification. For detailed instructions, see Specifying the containerd parameters of node pools.
Spot instance compensation	This parameter is displayed after you select Spot instance for the Billing method parameter for the node pool. After the feature is enabled, new instances will be automatically created for replacement about 5 minutes before spot instance reclamation. For details, see Node pools of spot instances.
Supplement spot capacity by pay-as-you-go instances	This parameter is displayed after you select Spot instance for the Billing method parameter for the node pool. After the feature is enabled, pay-as-you-go instances will be used for supplementation when spot instances are insufficient due to reasons such as inventory or pricing. When pay-as-you-go instances are running, even if spot instances meet the conditions, rebalancing will not be performed. Only when the node pool is being scaled in, pay-as-you-go instances are preferentially released. For details, see Node pools of spot instances.
Node distribution ratio policy	This parameter is displayed after you select Spot instance for the Billing method parameter for the node pool. After you enable the feature, set the proportion of pay-as-you-go instances to spot instances in the node pool. For details, see Node pools of spot instances.
Custom name	Select and configure the custom name types for nodes in the node pool as needed. You can configure multiple custom name types at the same time. tip VKE provides a tool for automatically specifying custom names for all nodes in a node pool. To use the tool, click Auto generation. After custom names are automatically configured, we recommend that you click Generate random names to add random suffixes. This prevents the names of the newly scaled-out nodes from conflicting with each other and ensures smooth node scale-out. Nodes added during subsequent scale-out operations in the node pool will use the custom name set here or be named according to the custom naming rule set here. The names of existing nodes in the node pool are not affected. Node name: used to quickly identify nodes in VKE or ECS. You can use one of the following two methods to specify node names: Node name: Specify the node name based on the displayed naming rules. Two naming patterns are available: fixed-range incrementing and dynamically extended incrementing. For detailed naming formats, see Naming formats. Node name prefix: Specify the node name prefix based on the displayed naming rules. Node host name: Set the host name corresponding to the node. Two naming patterns are available: fixed-range incrementing and dynamically extended incrementing. For detailed naming formats, see Naming formats. Node metadata name: Specify the metadata name (metadata.name) of a node object in Kubernetes. The metadata name is used to identify resources in external systems such as monitoring and alerting systems. You can use one of the following two methods to specify metadata names: Use node hostname: Use the hostname of the node as the node metadata name. Set prefix and suffix for node metadata name: Specify the prefix or suffix of the node metadata name. The system generates the complete node metadata name in the prefix-nodeIP-suffix format.
Image lazy loading	[Public beta] This feature is not enabled by default. After you enable the feature, nodes in the node pool can use the container image acceleration feature on demand. For more information, see Container image lazy loading solutions. warning Updating the image lazy loading feature of the node pool only takes effect on subsequently added nodes. Existing nodes are not affected. Only the nodes with a containerd version 1.4.13-vke.3 or later can use this feature. To view containerd versions, see FAQ.
The script executed before node deployment	Enter a shell script. The script will automatically be executed before Kubernetes components are deployed on nodes. You need to implement the script commands yourself and ensure that the script supports reentrancy and retry logic. The script and the related logs can be found in the /usr/local/vke/userscripts directory on the node. This feature is typically used for preprocessing operations, such as setting environment variables and creating temporary directories. warning The updated script takes effect only for new nodes provisioned from scale-out behavior.
InitializeScript	Enter a shell script. After the node deploys the Kubernetes add-on, the script will be automatically executed. You need to implement the script commands yourself and ensure that the script supports reentrancy and retry logic. The script and the related logs can be found in the /usr/local/vke/userscripts directory on the node. This feature is commonly used in scenarios such as modifying kubelet configurations. warning The updated deployment execution script only takes effect on newly added nodes instead of existing nodes.
Bind EIP to node	Specify whether to automatically bind EIPs to nodes in the cluster. Disable: By default, the system does not automatically bind EIPs to nodes. If you need to access nodes over the public network later, see Applying for an EIP and associating it with an ECS instance. Enable: The system automatically binds EIPs to nodes in the cluster. In this case, you need to specify custom EIPs. Billing type: EIPs support Pay-as-you-go - by bandwidth limit and Pay-as-you-go - by actual traffic. Line type: Only BGP (multi-line) is supported. Shared bandwidth packet: After you select this option, select the target items and shared bandwidth package to add the public IP addresses to the package. If no shared bandwidth package is available, refer to Creating shared bandwidth packages to create one. warning An EIP address can be added to a shared bandwidth package only when ‌all of the following conditions are met: The line type of both is identical. The shared bandwidth package is of type IPv4. No security protection is configured for the shared bandwidth package. Bandwidth limit: Specify an upper bandwidth limit. tip You will be charged for using EIP. For details, see EIP billing overview. If the EIP quota is insufficient, submit an application in the EIP console. For more information, see EIP limits. When a node is deleted or removed, the associated EIP will be simultaneously released. Automatic EIP binding is supported only for new nodes added to the node pool and does not apply to existing nodes.
Cordon node	After you enable the cordon node feature, the nodes in the node pool are set to the cordoned and unschedulable status. Newly created pods cannot be scheduled to nodes in the node pool, but pods already running on the nodes are not affected. You can execute the kubectl uncordon command to disable it manually. Cordoning a node will reduce the remaining resource quota of the cluster to which the node belongs. If the cluster does not reserve sufficient available resources, node cordoning will affect the scheduling of new applications and the running of existing applications.

Existing node adding

In addition to the default node pool, some qualified custom node pools support adding existing ECS instances as nodes to meet business requirements such as resource reuse and node warm-up.

For operations related to adding existing nodes to the default node pool, see Adding existing nodes.

Usage limits

Only custom node pools and Elastic Compute Service (ECS) instances that meet the following conditions support this feature:

For custom node pools, the following conditions need to be met:

Autoscaling is not enabled for the node pool.

The current node pool status is running.

The current node pool billing mode is Pay-as-you-go or Subscription.

For ECS instances, the following conditions need to be met:

Running in the same VPC as the current cluster.

Be under the same project as the target node pool.

The instance has not been added to any cluster or scaling group of the Auto Scaling service.

The instance only has one network interface card.

The system volume of the instance has a capacity ≥ (image size configured for the target node pool + 10 GiB).

If you do not specify the data volumes to be mounted on the node (i.e., the option Disk mount is not selected), the instance has to include the data volume with both type and size the same as required by the target node pool. For example, if the target node pool is configured with five data volumes (including local disks), and the first data volume has "Format and mount to the container and image storage directory" enabled, while the third data volume has "Specify mount directory" enabled, then the ECS instance needs to have two data volumes (including local disks) that are the same as the first and the third ones of the target node pool in terms of type and size.

Procedure

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Find the target node pool and in the Actions column, click ... > Add existing node.

In the All Servers list, select the nodes that need to be added to the node pool, and add them to the Selected servers list.

Parameter	Description
All servers	The list displays all ECS instances within the same VPC as the cluster and in the same project as the current node pool. Select the ECS instances as needed. warning If Buy affinity group (beta) is enabled for the current node pool, the selected ECS instances must meet the following conditions at the same time: Consistent size: The affinity group sizes of the selected ECS instances and the node pool must be consistent. Add the entire group: You must select all ECS instances in the affinity group. For example, if the affinity group size of the node pool is 4, you need to select one or more affinity groups with the same size of 4 and select all ECS instances in the groups. To change the affinity group size of the node pool, see Managing node pools. If Buy affinity group (beta) is not enabled for the current node pool, but you select ECS instances added to affinity groups, unexpected behavior may occur. We recommend not selecting ECS instances added to affinity groups for node pools for which Buy affinity group is not enabled.
Selected servers	This list displays the ECS instances that you have selected.
Keep ECS instance name	Keep ECS instance name Enable: will keep the original ECS instance name. tip If the names retained contain any Chinese characters, the system label cluster.vke.volcengine.com/node-name for that node will become invalid. Therefore, you need to avoid using the cluster.vke.volcengine.com/node-name label in scenarios such as affinity-based scheduling. Disable: will not keep the original ECS instance name. VKE will rename the node based on the current node pool configuration.
Disk mount	If enabled, you need to specify the mount directory so that the data volume of the node can be mounted to this directory. Before specifying the mount directory, carefully read the prompts displayed on the page.
Reinstall OS	If you select this option, the operating system (OS) of the ECS instance will be reinstalled using the OS configuration of the current node pool. The existing data on the system volume of the instance will be cleared and cannot be restored. If you do not select this option, the ECS instance will retain its existing operating system and system volume data. warning If you continue to use the existing operating system and system volume data of the ECS instance, make sure that the ECS instance meets the following requirements. Otherwise, the node will fail to be added. The ECS instance must be in the RUNNING state. The ECS instance must have the Cloud Assistant Agent installed, and the Cloud Assistant Agent must be in the Running state. Go to the ECS console to view the status of the ECS instance and its related resources. If you do not reinstall the operating system for an ECS instance, existing data on the ECS instance may result in node adding failures or other unknown issues. We strongly recommend that you reinstall the operating system.
Restart now to install cloud assistant Agent	The Agent is installed by default and cannot be modified. Using Agent to manage nodes can facilitate fault monitoring and self-healing.

Click Confirm.

Cloning node pools

VKE supports cloning node pools. You can create different node pools with similar configurations to serve multiple upper-layer services.

tip

The default node pool does not support cloning.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Find the target node pool and click ... > Clone.

On the Clone node pool page, set the node pool name and node login password/SSH key pair. The rest of the parameters can be configured as needed. For parameter descriptions, see Editing node pools described at the beginning of this topic.

Click Next: Confirm configuration. And then click Confirm if you checked the configurations on the page and ticked the checkbox for I have read and agree at the bottom.

Removing node pools

You can remove the node pools no longer needed, as well as the associated nodes, provided that normal business operations are not affected.

warning

When you remove a node pool, all nodes within it will be removed from the current container cluster and cannot be restored. Proceed with caution.

The pods on all nodes in the node pool will be deleted, which may trigger rescheduling. If rescheduling fails, your business may be affected. Make sure that the cluster has sufficient resources for rescheduling.

After you remove the node pool and synchronously destroy ECS instances, the data on ECS system volumes and data volumes will be deleted and cannot be restored. Proceed with caution.

You can destroy only pay-as-you-go and spot ECS instances instead of subscription ECS instances. To destroy subscription ECS instances, go to the ECS console to cancel the subscription.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Find the target node pool and click ... > Remove in the Actions column.

In the pop-up window, select Simultaneously destroy ECS instances as needed, then click Remove to start.

Diagnosis

Node pool troubleshooting helps users identify potential risks in node pools within a VKE cluster based on different information, including abnormal node pool status, CA add-on status, node quota status, and ECS inventory.

tip

The default node pool does not support diagnosis.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

You have two options for initiating a diagnosis on a node pool and nodes within the node pool.

Node pool details page
Diagnosis page
On the Node pool page, click the name of the target node pool to go to the node pool details page.
On the Diagnosis tab, click the corresponding button to initiate a diagnosis on the current node pool and its nodes.
Node pool diagnosis: Initiate a diagnosis on the current node pool. When the diagnosis is complete, you can view the result. For details, see Node pool diagnosis.
Node diagnosis: Select a node within the node pool to initiate a diagnosis on that node. For details, see Node diagnosis.
On the Node pool page, find the target node pool, and in the Actions column, click ... > Diagnosis.
On the Create diagnosis job page, configure a diagnosis task for the node pool. For details, see Node pool diagnosis and Node diagnosis.

Runtime upgrade

VKE has supported containerd 2.1.x since Kubernetes v1.34 and will no longer support nodes or node configurations using containerd 1.x after Kubernetes v1.36. You can use the Runtime upgrade feature to upgrade the containerd version on the nodes.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Find the target node pool and click ... > Runtime upgrade.

On the Node Kubernetes upgrade page, upgrade the containerd version on the nodes. For detailed parameter configurations and upgrade considerations, see Upgrading nodes.

Edit runtime

VKE supports updating the containerd configuration of nodes in a node pool.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Find the target node pool and click ... > Edit runtime.

In the Edit container runtime dialog box, select the target runtime version and click Confirm. For runtime version details, see Runtime release notes.

Enable or disable managing

You can convert a normal node pool to a managed node pool. You can also convert a managed node pool to a normal node pool by disabling management mode.

Click the target cluster name. In the left navigation bar of the cluster management page, click Nodes > Node pool.

Find the target node pool and click ... > Disable managing or Enable managing.

Enable management

Disable management

In the Check and self-healing settings dialog box, specify parameters based on the on-screen prompt and then click Confirm. For more information about managed node pools, see Creating managed node pools.

Parameter	Description
Check and self-healing	Specify whether to enable the node check and self-healing feature. On: Enables the feature. The system automatically checks node health. It cordons a node or restarts node components in case of a node failure based on the configured check and self-healing rules. Off: Does not enable this feature. This is the default setting.
Check and self-healing rules	Configure check and self-healing rules for the node pool. This feature is in the beta stage. The rules fall within two categories: Recommended rule - Enables the recommended check and self-healing rule for the node pool. For details, see Recommended rules. Custom rule - a custom check and self-healing rule. If no custom rules have been configured, you can click Create check and self-healing rules to create one. For details, see Node checking and self-healing. tip If you select Recommendation rule, the system automatically generates a check and self-healing rule in one of the following formats: GPU node pool self-healing rule-{node pool name}-{random number} for a GPU node pool. node pool self-healing rule-{node pool name}-{random number} for a non-GPU node pool.

Last updated: 2026.09.24 15:22:31