Node pools are the foundation of how your Kubernetes cluster runs workloads. Understanding how they work — and how to size them correctly — is central to what RealTheory optimizes for you.
What is a Node Pool?
A node pool is a group of nodes within a Kubernetes cluster that share the same configuration — the same machine type, operating system, disk size, and resource limits. Every node in a pool is interchangeable: Kubernetes can schedule any workload onto any node in the pool without distinguishing between them.
A cluster can have one node pool or many. Multiple node pools let you run different types of workloads on hardware that is appropriately sized for each — for example, a general-purpose pool for most workloads and a memory-optimized pool for data-intensive jobs.
What Makes up a Node Pool?
The key configuration decisions for a node pool are:
- Node type — the machine or instance type that determines the CPU, memory, and storage available on each node. This is the most significant cost and performance lever.
- Node count — how many nodes are running in the pool at any given time.
- Autoscaling — whether the pool can grow or shrink automatically based on workload demand.
- Labels and taints — Kubernetes metadata that controls which workloads can or must run on nodes in this pool.
Why Node Pool Sizing Matters
Choosing the wrong node type is one of the most common sources of Kubernetes waste. An oversized node type leaves CPU and memory unused — you pay for capacity your workloads never use. An undersized node type forces Kubernetes to run more nodes than necessary, or causes workloads to be unschedulable.
The right node type depends on the actual resource profile of the workloads running on it — their CPU demand, memory demand, pod count, and any special requirements like GPUs or local storage. This is exactly what RealTheory analyses when generating a node pool recommendation.
How RealTheory Optimizes Node Pools
RealTheory evaluates the resource requirements of all workloads scheduled on a node pool and identifies the node type and node count that covers those requirements with the least waste. Recommendations account for CPU and memory headroom, pod density, architecture compatibility, and cost across available instance types in your region.
Node type preferences vary — pricing agreements, generational policies, and organizational standards all influence which node types make sense for your environment. Define which node types RealTheory can and cannot recommend in Settings > Recommendations > Nodepools > Nodepool Constraints.
RealTheory generates node pool recommendations at the pool level, not the individual node level. If a pool is running mixed workloads with very different resource profiles, splitting it into multiple purpose-specific pools might yield better results than optimizing a single pool.
Additional Resources
Each cloud provider implements node pools within their managed Kubernetes service. The concepts are consistent, but the terminology and configuration options vary. See the official documentation for your provider below.
AWS — Amazon EKS
AWS calls these managed node groups. Each node group runs EC2 instances in an Auto Scaling group managed by EKS.
Managed node groups overview
Create a managed node group
Azure — AKS
Azure calls these node pools. AKS supports both system node pools (for cluster system pods) and user node pools (for your application workloads).
Create node pools in AKS
System and user node pools
GCP — GKE
Google calls these node pools. GKE Standard clusters let you configure node pools manually; GKE Autopilot manages node pools for you automatically.