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 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.