Docs

Volcengine Kubernetes Engine

Nodes and node pools

Best practices for ECS instance selection

This topic describes how to select proper ECS types for use in VKE clusters and considerations for ECS selection.

Cluster architecture

The control components of a VKE cluster are managed and deployed by the cloud platform. You do not need to worry about the selection or operation and maintenance of Kubernetes master nodes. You only need to create worker nodes. This form allows you to focus more on your applications and offers benefits such as ease of use, low cost, and high availability.

Selecting worker node specifications

Instance specification

ECS provides multiple instance families, and each instance family includes various instance types. By performance characteristics, these instance families can be classified into general-purpose, compute-optimized, memory-optimized, and other types.

An instance specification may be added or removed from the list of available instance specifications. Instances with a certain specification can also be sold out. We recommend that you check available instance specifications on the Create node pool page before you create a node for a cluster in the VKE console.

For detailed descriptions of instance families and the naming format of instance specifications, see Instance selection best practices.

Node planning

Typically, a Kubernetes cluster can be regarded as a super node abstracted over a group of standalone nodes. The total computing resources of this super node equal the sum of the resources of all its constituent nodes. However, due to factors like scheduling policies and node management overhead, the node utilization rate can vary significantly when services run on different node specifications. Therefore, choosing the right node type to run services is especially critical.

Running workloads on a small number of large-specification nodes

When the total resources are the same, you can choose a small number of large-specification ECS instances as worker nodes to run workloads. The advantages and disadvantages of this node selection strategy are shown in the following table.

Advantages and disadvantages	Description
Advantages	Lower management costs. Managing a small number of machines is obviously easier than managing a large number of machines. Lower resource costs. Fewer nodes reduce additional overhead of the operating system. Support for resource-intensive applications. For example, a machine learning app requiring 8 GB of memory can’t run on a cluster with nodes that have 1 GB of memory. However, it can run on a cluster with nodes that have 10 GB of memory.
Disadvantages	More containers run on a single node, so node failures disrupt more workloads. Higher container deployment density increases the risk of node instability. Fewer nodes make it difficult to deploy applications with anti-affinity (for high availability), indirectly reducing overall system reliability. Cluster autoscaling can easily lead to resource waste.

Running workloads on a large number of small-specification nodes

When the total resources are the same, you can choose a large number of small-specification ECS instances as worker nodes to run workloads. The advantages and disadvantages of this node selection strategy are shown in the table below:

Advantages and disadvantages	Description
Advantages	Node failures cause a smaller impact. This strategy facilitates anti-affinity deployment of applications, improving application reliability. Resource waste is less in autoscaling scenarios, although frequent scaling may cause service fluctuations. Lower container deployment density improves node stability.
Disadvantages	Increasing the number of nodes brings greater management pressure and higher management costs. More nodes lead to increased basic consumption in aspects such as kubelet, docker, cAdvisor, and log collection clients. Overall resource utilization decreases due to node resource fragmentation.

Recommendations

There is no universally applicable method for selecting the appropriate node type. To select a node type that best fits your scenario, consider your business characteristics. Evaluate the pros and cons of high-spec and low-spec large instances.

Common best practices are as follows:

Determine the total number of cores required by the cluster under normal conditions and the redundancy needed to ensure availability.

For example, if your business peak load does not exceed 144 cores and you need to retain 10% redundancy, the total core requirement is 160 cores (144 / 90%). In this case, you can choose 10 ECS instances with 16 cores each. If one ECS instance fails, the remaining ECS instances can still support normal service availability. Alternatively, you can ensure availability through auto-scaling. For details, see Node scaling overview.

Classify nodes based on your requirements for computing, storage, networking, and programming languages: Node types include compute-optimized (CPU-to-memory ratio approximately 1:2), memory-optimized (CPU-to-memory ratio 1:8), general-purpose (CPU-to-memory ratio 1:4), and more. You can also categorize your workloads as compute-intensive, IO-intensive, and so on based on their resource needs. For example, Java applications typically have high memory usage, so we recommend using memory-optimized instances with a CPU-to-memory ratio of 1:8.

Considerations for selecting instance specifications in VPC-CNI clusters

You need to pay special attention to the following considerations for selecting nodes for a cluster that uses the VPC-CNI networking model.

Scenario description

The VPC-CNI networking solution is a container networking capability in VKE based on CNI and elastic network interfaces (ENIs) of VPCs. It allocates native ENIs to pods to enable pod networking. In this network mode, the container network and node network are on the same network plane. The container IP is a secondary ENI IP allocated by the IPAMD add-on. This solution is applicable to scenarios with high latency sensitivity.

Considerations

Each ECS instance can have multiple ENIs, and each ENI can have multiple IP addresses.

ECS instances of different specifications support different numbers of ENIs and different numbers of secondary IPs per ENI.

Each pod requires an available secondary IP address. The number of pods per node is limited by the number of ENIs that can be bound to the node and the number of secondary IPs that can be bound to a single ENI. By default, the maximum number of pods per node is calculated using this formula: (maximum number of secondary ENIs that can be bound × number of secondary IPs per ENI) + 1 (the "1" is reserved for the CNI pod by the system).

For the maximum number of ENIs per ECS instance and the number of secondary IPs per ENI, see Instance specifications.

Pod count limit per node

The table below lists the specifications for the general-purpose g1ie instance family. For more information about specifications, see Instance specifications.

The ecs.g1ie.large instance has 2 ENIs (including 1 primary ENI), so the maximum number of secondary ENIs that can be bound is 1. Each ENI supports 6 private IPs. Thus, if you use an ecs.g1ie.large instance as a node, the maximum number of pods per node is: 1 (secondary ENIs) × 6 (secondary IPs per ENI) + 1 (system-reserved pod) = 7.

Instance specification	vCPU	Memory (GiB)	ENI IP count (including a primary ENI)	Private IP count per ENI
ecs.g1ie.large	2	8	2	6
ecs.g1ie.xlarge	4	16	4	10
ecs.g1ie.2xlarge	8	32	4	10
ecs.g1ie.4xlarge	16	64	8	20
ecs.g1ie.6xlarge	24	96	8	20
ecs.g1ie.8xlarge	32	128	8	20
ecs.g1ie.14xlarge	58	224	8	20

Last updated: 2026.10.16 17:40:20