---
title: "What is a node pool?"
canonical: https://enum.co/learn/what-is-a-node-pool
locale: en
topic: Kubernetes
publishedAt: 2026-10-17
updatedAt: 2026-10-17
author: "Max Heyer"
summary: "A node pool is a group of Kubernetes worker nodes with the same machine type and settings, managed as one unit for sizing, upgrades and workload placement."
---

# What is a node pool?

A node pool is a group of Kubernetes worker nodes with the same machine type and settings, managed as one unit for sizing, upgrades and workload placement.

After reading this you will be able to:

- Explain what a node pool is and why clusters use several
- Steer pods onto the right pool with labels and taints
- Plan pool size, upgrades and node failures

## What is a node pool?

A node pool is a group of worker nodes in a Kubernetes cluster that share one machine type, one set of labels and one configuration. You resize, upgrade and replace the pool as a unit instead of handling each node by hand. A cluster can have one pool or several, each sized for a different kind of workload.

Think of a delivery company's fleet. Vans, trucks and cargo bikes each form their own group, with the same model and the same servicing schedule. A parcel goes to the group that suits it, and you add vehicles to the group that runs short.

Kubernetes itself only knows nodes. The pool is a layer the platform adds on top, and each node carries labels that say which pool it belongs to.

## Why run more than one node pool?

One pool is fine for a small cluster. Several pools help once workloads have different needs:

- A general pool for web services and background workers.
- A GPU pool for inference or training, so normal pods do not take up expensive hardware.
- A separate pool for a critical service, so a noisy neighbour in the same cluster cannot starve it.

## How do pods land on the right pool?

### Labels and node selectors

A pod with a `nodeSelector` is scheduled only onto nodes that have every label it lists. Node affinity does the same with more expressive rules, and it can be a hard requirement or a soft preference.

### Taints and tolerations

Selectors pull pods onto a pool, taints push them away. A `NoSchedule` taint on a GPU pool keeps out every pod without a matching toleration. Use both together: the taint keeps other pods away, and the selector pulls the right pods in.

## What happens during upgrades and failures?

Upgrades usually go node by node. Each node is drained, which evicts its pods while respecting your PodDisruptionBudgets, and the pods start again on the other nodes in the pool. That only works if the pool has spare room while one node is out.

A pool with too few nodes also hurts when a node fails. Pods that cannot fit anywhere else stay pending until capacity comes back, so leave headroom in each pool.

## How enum handles node pools

On [enum Kubernetes Engine](/kubernetes-engine) your worker nodes are virtual machines spread across servers and failure domains in one zone, and failed nodes are replaced automatically. There is no node autoscaling today, so you size node pools for your peak. GPU node pools are available on request, and minor upgrades run node by node.

## FAQ

**Is a node pool a Kubernetes object?**
No. Kubernetes has Node objects but no pool object. The platform creates and manages the group, and marks each node with labels so you can target the pool from your pod specs.

**Can I change a pool's machine type in place?**
Usually not. The common approach is to add a new pool with the new machine type, move the workloads over by draining the old nodes, and then remove the old pool.

**How many nodes should a pool have?**
Enough to carry your peak load with one node out of service. That covers both rolling upgrades and a single node failure without pods getting stuck in pending.