Docs

Volcengine Kubernetes Engine

Creating node pools

Creating managed node pools

Volcengine Kubernetes Engine (VKE) supports managed node pools, which significantly improve fault tolerance for GPU-accelerated computing resources and increase resource utilization of node pools. These pools reduce operational complexity and improve maintenance efficiency.

Recommended rules

Managed node pools support self-healing. VKE provides system-recommended check and self-healing rules for ease of use. Recommended rules provide different check items and self-healing actions depending on whether managed node pools are GPU-accelerated.

GPU-accelerated node pools

The following table describes the checks and self-healing actions that are included in recommended rules for GPU-accelerated node pools.

Check item	Required	Self-healing	Self-healing action
GPU disconnection failure	Yes	Enable	Cordon the node
GPU internal failure	Yes	Enable	Cordon the node
Recoverable GPU memory failure	Yes	Enable	Cordon the node
Unrecoverable GPU memory failure	Yes	Enable	Cordon the node
GPU runtime failure	Yes	Enable	Cordon the node
GPU runtime warning	Yes	Enable	Cordon the node
GPU link failure	Yes	Enable	Cordon the node
GPU link performance degradation	Yes	Enable	Cordon the node
GPU driver failure	Yes	Enable	Cordon the node
GPU driver warning	Yes	Enable	Cordon the node
ECS instance failure	No	-	-
kubelet failure	Yes	Enable	Restart kubelet
Runtime failure	Yes	Enable	Restart containerd
Time synchronization service error	Yes	Enable	Restart chrony
Read-only node file system	No	-	-
Node kernel failure	No	-	-
Node kernel deadlock	No	-	-

Non-GPU-accelerated node pools

The following table describes the checks and self-healing actions that are included in recommended rules for non-GPU-accelerated node pools.

Check item	Required	Self-healing	Self-healing action
GPU disconnection failure	No	-	-
GPU internal failure	No	-	-
Recoverable GPU memory failure	No	-	-
Unrecoverable GPU memory failure	No	-	-
GPU runtime failure	No	-	-
GPU runtime warning	No	-	-
GPU link failure	No	-	-
GPU link performance degradation	No	-	-
GPU driver failure	No	-	-
GPU driver warning	No	-	-
ECS instance failure	No	-	-
Node readiness	No	-	-
kubelet failure	Yes	Enable	Restart kubelet
Runtime failure	Yes	Enable	Restart containerd
Time synchronization service error	Yes	Enable	Restart chrony
Read-only node file system	No	-	-
Node kernel failure	No	-	-
Node kernel deadlock	No	-	-

Prerequisites

The target cluster is in the Running state.

(Optional) To configure the volume encryption feature, ensure that you have activated the KMS service in advance and have completed key creation. For detailed instructions, see Getting started with KMS.

Procedure

In the left navigation bar, click Cluster.

In the cluster list, click the name of the target cluster.

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

Click Create node pool above the node pool list.

Configure the relevant parameters by following the on-screen prompts and referring to the examples below.

Node pool information

Parameter	Description
Name	The name of the node pool. A node pool name must meet the on-screen naming requirements. A node pool name must be unique within the same cluster.
Billing method	The billing method for the ECS resources within the node pool. You can select one of the following options: Pay-as-you-go: A postpaid mode in which you use resources first and pay later. Subscription: A prepaid model in which payment is made before use. After you select this billing method, you need to specify the Duration of purchase and Automatic renewal parameters. Spot instance: A postpaid mode for ECS instances. It costs a fraction of pay-as-you-go prices but has the same performance as standard ECS instances. When inventory is insufficient or the market price exceeds the defined price cap, the system will automatically release instance resources. Ensure that you have a proper data backup policy to prevent data loss. For more details, see Creating spot instance node pools. tip For ECS resource billing details, see Service billing.
Enable management	It is enabled by default. This means that the managed node pool capability provided by VKE is enabled. ‌Managed node pools deliver simpler and more efficient routine operations and maintenance, failure management, and resource utilization.
Check and auto-recovery	This parameter is displayed only after the Enable managing toggle is switched on. When the managed node pool capability is enabled, the node check and self-healing feature is enabled by default. 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 or restarts the component to prevent service disruptions. For more information, see Check and self-healing overview.
Check and auto-recovery rules	This parameter is displayed only after the Check and self-healing toggle is switched on. Configure check and self-healing rules for the node pool. The rules fall within two categories: Recommended rule - Enable the recommended check and self-healing rule for the node pool. For details, see Recommended rules. Custom rule - Select a custom check and self-healing rule from the drop-down list. If no custom rules have been configured, you can click Create check and self-healing rules to create one. For details, see Configuring node check 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.
Autoscaler	Select this checkbox to enable node pool autoscaling. The default solution is instant autoscaling (Karpenter). You need to configure the following parameters: Number of nodes: The range within which the number of nodes is dynamically adjusted during autoscaling. Valid values: 0 to 2000. You can request a node quota increase for the cluster in the Quota Center. 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. warning After you enable Autoscaling, you need to configure autoscaling rules to achieve node autoscaling. For detailed instructions, see Node autoscaling.
Availability zone	Availability Zones (AZs) are physically isolated infrastructure units within a single region, featuring independent power and networking systems. AZs communicate with each other over internal networks. Different regions have their own AZ. For details, see Regions and availability zones. Multiple availability zones: You can select this option if you need to create worker nodes in multiple random AZs. This option provides zone-level disaster recovery. A specified AZ: If you need to create all worker nodes in a single AZ, you can select an appropriate AZ. In this case, the network latency between instances is lower, but disaster recovery cannot be achieved.
Node subnet	The system will display the list of available subnets based on the selected AZ. Select one or more subnets in the AZ to provide network resources for nodes. If you select all AZs, the system will display all available subnets in those AZs. You can select one or more subnets within a single AZ or across multiple AZs. If you select a specific AZ, multi-AZ capabilities are not available. The system will display only the subnets in the AZ, and you can select one or more subnets in the AZ. tip 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 system displays a list of available instance types based on the selected subnets and defines the computing resource configuration of nodes based on the selected instance type. For detailed descriptions of instance types, see Instance specification list. If the selected subnets are in the same availability zone, only instance types available in the availability zone will be displayed. In this case, all worker nodes are created in the same AZ. If the selected subnets belong to multiple AZs, all instance types available in these AZs will be displayed. In this case, worker nodes are allocated to different AZs based on the resource conditions of each AZ and the configured subnet scheduling policy. warning When you create a node pool in a cluster that uses the VPC-CNI network model, the system automatically checks the number of supported elastic network interfaces (ENIs). You can select an appropriate instance type based on the prompts. If you select specifications that fall within the GPU Accelerated or High Performance Computing Optimized instance family and support multiple NVSwitch-compatible GPUs (such as A100 and A800), NVIDIA Fabric Manager will automatically start on the nodes within the node pool. This ensures normal network connectivity between GPUs. If NVIDIA Fabric Manager fails to start, see FAQ. The NVIDIA Fabric Manager package is already built into the public image. When you create a node by using a public image, NVIDIA Fabric Manager automatically starts to ensure NVSwitch interconnection between GPUs.
Selected Specifications	The selected instance types for nodes in the node pool. You can select up to 10 instance types. 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 autoscaling, 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 you select Spot instance for the Billing method parameter. 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 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.
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.
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. For details, see Creating HPC clusters. warning The availability zone of the selected HPC cluster must be within the availability zone of the current node pool subnet.
Buy affinity group	[Beta - apply for trial] This parameter is displayed only after an instance type that supports affinity groups is selected. An affinity group is a set of ECS instances deployed physically close to each other. Instances within the group are interconnected via a high-performance network. This is suitable for computing scenarios requiring low latency and high bandwidth communication. After you select Enable, instances are purchased as an affinity group, and you need to select the specific specification from the Affinity group size drop-down list. warning Only some ECS instance specifications support affinity groups. If you have applied for the beta permission on the VKE feature and selected an instance type, but do not see the Buy affinity group parameter, it means that the selected ECS specification does not support affinity groups. 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 later.
Number of nodes	Specify the initial number of nodes in the cluster to provide computing, storage, and other resources for running workloads. We recommend that you specify an appropriate number of nodes when you create the node pool. If you enter 0, no nodes are added to the node pool upon creation. Workloads won't run as expected in this case. You need to manually add nodes afterward to use the node pool normally. warning The expected node count behaves differently for node operations performed in VKE compared to those in ECS. For details, see FAQ.
More configuration
Container runtime	[Public beta] Select the container runtime and its version. tip VKE only supports the containerd container runtime. For more information about containerd versions, see Containerd runtime release notes.
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. Click Add new, and enter the key and value based on prompts.
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 include 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.
ECS tags	VKE adds Volcano Engine platform labels to newly added ECS instances. These labels facilitate search and management of ECS instances. Click Add new, and enter the key and value based on the on-screen prompts. tip The ECS instance label will be added to newly added nodes after the node pool is scaled out.
Deployment set	If you select the checkbox, the ECS instances that serve as nodes in the node pool will be added to the deployment set. The deployment set achieves security isolation at the physical level and distributes instances across different physical hardware, which ensures disaster recovery at the underlying layer and high availability. For details, see Overview of deployment sets.

System configuration

Parameter	Description
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 instance 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. VKE allows you to specify custom images as node operating systems. For more details, see Overview of operating system images. Shared images: the images shared by other Volcano Engine accounts. You can use shared images to quickly deploy the same software environment as that of nodes created by other users, or share custom images that you have created or uploaded with other Volcano Engine accounts. 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 node pool project level.
Install cloud assistant Agent at startup	The agent is installed by default. This setting cannot be modified. The node pool uses Agent for node management, which facilitates fault monitoring and self-healing for nodes in the node pool.
Security reinforcement	Configure host security hardening. Enable (default): The host-based intrusion detection system (HIDS) detects and alerts risks such as abnormal login. Compatible with host OS, it provides security hardening features for nodes (ECS instances). These features include real-time monitoring, file monitoring, process monitoring, and system dynamic analysis. Disable: The security hardening feature is not enabled.
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 specific instance types that support local volumes, see Instance types. 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. Extra performance: Enable the additional performance feature for the cloud disk, and select the additional performance type in the pop-up window. This feature allows you to improve cloud disk performance without increasing cloud disk capacity. tip Extra performance for a data volume can be configured only in the following scenarios: The cloud disk is of the ESSD type, with a performance level of FlexPL and a capacity of at least 500 GiB. For more information, see ESSD FlexPL cloud disks. The cloud disk is of the throughput SSD type, with a performance level of TL0 and a capacity of at least 100 GiB. For more information, see Throughput SSD cloud disks. Performance burst: Enable performance bursting for a cloud disk. This allows the cloud disk to deliver I/O performance that exceeds its baseline performance for a short period, to handle peak business workloads or bursty traffic. tip This parameter is supported only when the cloud disk type is ESSD and the performance level is FlexPL. For more information, see ESSD FlexPL cloud disks. After you enable the performance bursting feature for ESSD FlexPL cloud disks, you will be charged based on the burst performance usage. For details, see Burst performance billing - ESSD FlexPL cloud disks. Encryption: Enable the data volume encryption feature and select a KMS key in the dialog box. This encrypts files stored on data disks to prevent unauthorized access at the storage level and meet data security and compliance requirements. Cloud disk encryption is supported only on certain instance types and in certain regions. For details, see Cloud disk encryption. 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

Parameter	Description
Security group	To ensure that clusters and nodes can function, VKE provides a default security group named in the <Cluster ID>-common format. If you need to add custom security group rules, ensure the new rules do not conflict with the default ones. For more information about the default security group, see Security group settings. tip A single node pool can be associated with up to 4 custom security groups.
Login methods	Specify the type of credentials for logging in to nodes in the clusters. 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. You can select key pairs from projects other than the project of the node pool. For more information about key pairs, see Key pair overview.

Advanced settings

Parameter	Description
Node labels	Labels in VKE function identically to Kubernetes labels. Labels can be used to define attributes for nodes, facilitating node operations and management. A label can be added in batches to all the nodes in the node pool. Click Add node labels and enter a key and its value. warning Custom node labels cannot be the same as system labels. For details of system labels, see System labels and taints.
Node taints	Taints allow nodes to repel specific pods and therefore prevent those pods from being scheduled to the nodes. You can add the same taint to multiple nodes in the node pool at the same time. Click Add node taints, and enter the key, value, and effect based on the prompts. You can specify one of the following effects for a taint: NoSchedule: If this taint exists on a node, the Kubernetes scheduler will not schedule Pods that cannot tolerate this taint to the node. NoExecute: Pods that do not tolerate this taint are evicted from nodes with this taint effect, while pods that tolerate it are not evicted. PreferNoSchedule: The system attempts to avoid scheduling pods to nodes with taints that are not tolerated by the pods, but it is not guaranteed. warning Custom node taints cannot be the same as 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 features that use fixed node labels to behave unexpectedly. Proceed with caution.
Kubelet configs	Specify custom kubelet parameters for nodes in the node pool to adjust node behavior. For detailed operations, see Custom kubelet parameters.
Containerd configuration	Node pools support custom containerd configuration, which includes specifying 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. 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 sopt capacity by pay-as-you-go instances	This parameter is displayed after you select Spot instance for the Billing method parameter. 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 preemptive instances.
Node distribution ratio policy	This parameter is displayed after you select Spot instance for the Billing method parameter. 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 preemptive 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 to prevent the custom names of the newly scaled-out nodes from conflicting with each other. This ensures smooth scale-out of nodes in the node pool. 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. 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-node IP-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 Only nodes that run containerd 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.
InitializeScript	Enter a shell script. After Kubernetes add-ons are deployed on the node, the script is 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.
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 types are 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.
Cordon node	Disabled by default. 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 manually run the kubectl uncordon command to uncordon the nodes. Cordoning a node reduces the remaining resource quota of its cluster. If the cluster has insufficient available resources, node cordoning will affect the scheduling of new applications and the operation of existing ones.

Click Next: Confirm configuration in the lower-right corner of the page to enter the configuration confirmation step.

Check whether the configurations meet your expectations. If you need to update the configurations, click Previous: Node pool configuration in the lower-right corner of the page.

Check the configuration cost. You can click the help icon next to the cost to view the cost details, including billable items, billing method, quantity, original price, and discounted price.

Carefully read Volcengine Kubernetes Engine Specific Terms of Service and select the checkbox to agree to the terms. Then, click Confirm in the lower-right corner of the page to create the node pool and add the related configurations.

On the Node pool page, if Running appears in the Status column for the created node pool, the node pool has been successfully created.

Last updated: 2026.09.24 15:22:31