Add ECS instances to a registered cluster

更新时间:
复制 MD 格式

To facilitate the grouping, management, and operation of cloud-based ECS nodes, ACK One registered clusters provide the node pool feature that helps you manage Elastic Compute Service (ECS) instances that are added to the clusters in groups. A node pool is a logical collection of one or multiple nodes. You can manage and maintain the nodes in a node pool in a centralized manner. For example, you can centrally upgrade and configure auto scaling for the nodes in a node pool. You can also group computing resources into different node pools to achieve resource isolation. For example, you can create separate node pools for different types of workloads or create different node pools to manage nodes with different attributes.

Node pool

You can consider a node pool as a configuration template that is applied to all nodes that are added to the node pool. You can create one or more node pools of different types and configurations in a Container Service for Kubernetes (ACK) cluster. The configurations of a node pool consist of node attributes, such as the node specifications, zones, operating system, labels, and taints. You can configure node attributes when you create a node pool or modify node attributes after the node pool is created. For more information, see Create a node pool.

image

You can use a single node pool to reduce management and configuration complexity. You can also use multiple node pools to implement fine-grained resource isolation and manage mixed deployments of different node types.

Single node pool

Multiple node pools

Manage computing resources for multiple teams or workloads with a single node pool to simplify operations and maintenance. A single node pool supports the following features.

  • Manage computing resources for multiple teams at the same time.

  • Configure multiple instance types, such as regular ECS instances, GPU-accelerated instances, ECS Bare Metal Instances, and HPC-optimized instances, to meet the needs of different workloads.

  • Distribute nodes across multiple zones to improve high availability.

Mixing instances with different operating systems or CPU architectures (Arm and x86) is not supported.

Create multiple node pools to provide separate computing resources for different workloads or teams. This helps prevent resource contention and potential security risks. This approach is suitable for the following scenarios.

  • Isolate tenants to provide separate computing resources for different teams and simplify billing management.

  • Isolate machines with different device specifications, such as CPU architecture, GPU, and FPGA, to ensure rational allocation of hardware resources.

  • Enhance security isolation for sensitive applications.

  • Deploy different operating systems.

When you use multiple node pools, you can use scheduling policies to define the priority of different node pools to optimize resource and cost management. Examples include the following scenarios.

  • Control the priority of computing resources with different costs, such as spot instances and subscription instances, to reduce costs.

  • Allocate different types of instances based on workload requirements, such as the usage ratio of x86 and Arm architectures.

Node pool creation procedure

image

Basic features of node pools

The node pools in ACK One registered clusters provide the following features to facilitate node management.

Feature

Description

Create custom scripts for node pools

  • A custom script ensures that the node pool in a registered cluster can synchronize node status as normal for cloud resource scheduling.

  • A custom script must obtain environment variables issued by the registered cluster.

Create and manage node pools

  • Create node pools in the console and configure basic information, network settings, instance specifications, storage settings, and the number of expected nodes.

  • Modify some configurations of existing node pools. For more information about the editable configuration items and notes, see the referenced document.

  • Delete node pools when they are no longer needed. The behavior of node release is affected by whether the expected number of nodes is enabled for the node pool and the billing method of the nodes.

  • View the details of a node pool, including basic configuration information, resource monitoring dashboards, node lists, and scaling activities.

Manually scale node pools

  • Manually adjust the expected number of nodes in a node pool to scale it in or out. This keeps the number of nodes at the desired level and saves resource costs.

    Some non-standard removal, modification, or release operations may prevent the node pool from scaling out as expected. For more information, see the referenced document.

  • Configure an automatic scaling solution for nodes. This automatically scales node resources when the cluster's capacity planning cannot meet application pod scheduling needs.

Manage node labels and taints

You can use labels and taints to manage and schedule resources in Kubernetes clusters. Labels can be used to identify and classify Kubernetes resources, such as nodes. Taints can be used by nodes to repel specific pods.

Remove nodes from a node pool

You can remove nodes that are no longer needed from a node pool. To prevent unexpected issues during node removal, we recommend that you remove nodes based on the standard removal procedure.

Node pool billing

Node pools and their automated O&M capabilities are free of charge. However, you are charged for the cloud resources within the node pool, such as ECS instances, by the corresponding cloud services.

  • For more information about ECS instance billing, see Billing overview.

    To change the billing method of existing nodes in a node pool, see Convert pay-as-you-go to subscription. Changing the billing method of a node pool affects only new nodes added by scaling out. It does not change the billing method of existing nodes in the node pool.

  • For more information about Auto Scaling group billing, see Auto Scaling billing.

Glossary

Before you use node pools for the first time, familiarize yourself with the following related terms.

  • Scaling group: When you scale a node pool in or out, ACK sends scale-out and node removal operations through the Auto Scaling (ESS) service. Each node pool corresponds to one Auto Scaling scaling group instance. A scaling group is a collection of one or more ECS instances (worker nodes).

  • Scaling configuration: A node pool uses a scaling configuration to manage node configurations. An ESS scaling configuration is a template used for ECS instances during elastic scaling. When a scaling activity is triggered, Auto Scaling uses this scaling configuration as a template to automatically create ECS instances.

  • Scaling activity: Each scale-in, scale-out, node addition, or node removal operation in a node pool triggers a scaling activity. After a scaling activity is triggered, all scale-out and scale-in actions are automatically completed by the system, and relevant records are generated. You can view the historical scaling activity records of a node pool.

  • Replace the system disk: Some node pool operations, such as automatically adding existing nodes and changing the container runtime, initialize nodes by replacing the node's system disk. The instance properties of the node, such as the node name, instance ID, and IP address, do not change. However, data on the node's system disk is deleted. Data disks that are attached to the node are not affected.

    When ACK replaces a system disk, it drains the node. It evicts the pods on the node to other available nodes while respecting the Pod Disruption Budget (PDB). To ensure high service availability, use a multi-replica deployment strategy to distribute workloads across multiple nodes. Also, configure PDBs for critical services to control the number of pods that can be disrupted at the same time.

  • In-place upgrade: An upgrade method that is an alternative to replacing the system disk. It directly updates and replaces the required components on the original node. An in-place upgrade does not replace the system disk or re-initialize the node. Data on the original node is not affected.