GKE Node Pools Explained: What They Are, When to Use Them, and How They Work

What is a GKE node pool?

In GKE, worker nodes are Compute Engine virtual machines running inside your GCP project. A node pool is a named group of those VMs that all share the same configuration: machine type, disk size, operating system image, Kubernetes node labels, and taints. When GKE adds a node to a pool, the new node is identical to every other node already in that pool.

Node pools are a GKE Standard concept. If you are using GKE Autopilot, node pools do not exist. Google manages all the infrastructure behind the scenes and you never interact with node pools directly.

When you create a Standard cluster, GKE automatically creates a default node pool for you. You can add more pools at any time without recreating the cluster.

Simple explanation for beginners

If you are new to Kubernetes, the relationship between clusters, nodes, and pools can feel abstract. Here is a concrete way to think about it.

How GKE node pools fit into a cluster

Understanding where node pools sit in the GKE hierarchy makes everything else easier:

A single cluster can have many node pools. Pools are independent in terms of machine type and scaling settings, but pods across all pools share the same Kubernetes namespaces and cluster network. A pod in the GPU pool can communicate with a pod in the standard pool without special configuration, following the same rules described in GKE networking.

Because all nodes in a pool are identical, the Kubernetes scheduler treats them as interchangeable. If you need nodes with different capabilities, you need different pools.

Why node pools exist

Node pools solve a real problem: different workloads have very different hardware needs, and putting them all on identical machines is wasteful, expensive, or technically impossible.

Cost control. Running expensive GPU nodes 24/7 when your ML training job only runs overnight wastes money. A dedicated GPU pool can autoscale to zero when not in use, so you only pay while it is active.

Workload isolation. Keeping production-critical services on their own pool means a resource-hungry batch job cannot starve them of CPU or memory.

Hardware compatibility. Some workloads cannot run on certain node types at all. Windows containers require Windows nodes. GPU workloads require nodes with attached accelerators. These cannot be mixed with standard Linux nodes in the same pool.

Independent autoscaling. Each pool has its own autoscaling settings. You can allow a batch-processing pool to scale between 0 and 50 nodes while keeping the production API pool stable at 3 to 10.

Spot VM savings. Spot VMs cost significantly less than on-demand VMs but can be reclaimed by Google with 30 seconds notice. Placing fault-tolerant batch workloads on a Spot pool captures the savings without exposing latency-sensitive services to that availability risk.

Memory-optimised workloads. In-memory caches, analytics engines, and some databases need far more RAM than a general-purpose VM provides. A high-memory pool gives those workloads what they need without forcing you to provision expensive nodes everywhere.

When to use multiple node pools

A single node pool is fine for simple applications where all workloads have similar resource needs. You need multiple pools when workloads diverge significantly.

GPU workloads. ML training and inference jobs need GPU nodes. GPUs are expensive, so you do not want non-GPU workloads accidentally landing on them. A separate GPU pool with taints ensures only GPU-requesting pods are scheduled on those nodes.

High-memory workloads. In-memory caches, analytics engines, or stateful databases may need 64 GB or more of RAM per pod. A high-memory pool handles this without over-provisioning everywhere.

Batch jobs on Spot nodes. Nightly ETL pipelines, image-processing jobs, and large-scale data tasks that can tolerate interruption are ideal for a Spot pool. Keep your always-on services on standard on-demand nodes in the same cluster.

Windows containers. Linux and Windows containers cannot share the same node. If your application has Windows-based components, they must live in a Windows Server node pool alongside your Linux pools.

Separating production from cheaper workloads. Running staging workloads in the same cluster as production is common for cost reasons. Separate pools with taints make it easy to direct staging to cheaper nodes while guaranteeing production pods are never displaced.

Independent scaling requirements. If your video transcoding service needs to burst from 0 to 40 nodes overnight, you do not want that affecting the predictable scaling of your web tier. Separate pools scale independently.

GKE node pools vs GKE Autopilot

Node pools are a Standard mode concept. In Autopilot, you do not create, configure, or manage them. If someone refers to a “node pool” in the context of GKE, they are talking about a Standard cluster.

See GKE Autopilot vs Standard Mode for a full comparison.

Node pools vs labels vs taints vs node selectors

These four concepts are related but distinct. Beginners often confuse them.

A node pool is an infrastructure-level group. When you create a pool with --node-labels and --node-taints, GKE applies those labels and taints to every node in the pool automatically.

A node label on its own does not restrict scheduling. Any pod can still land on a labelled node unless a taint is also present.

A taint actively blocks pods without a matching toleration. The NoSchedule effect prevents new pods landing on that node. NoExecute also evicts existing pods that lack a matching toleration.

A toleration in a pod spec says “this pod is allowed on nodes with that taint.” It is permissive, not directive. The pod may go there but is not forced there.

A nodeSelector or Node Affinity rule in a pod spec says “schedule me on nodes with this label.” Used alongside a toleration, this both permits the pod on the tainted node and steers it toward that node.

Practical example. A GPU node pool has a taint gpu=true:NoSchedule and label workload=gpu. Your ML training pod needs a toleration for the taint (so it is permitted on the GPU node) and a nodeSelector: workload: gpu (so it is actively placed there). Without both, the pod might end up on a standard node with no GPU.

See Kubernetes Pods Explained for more on how pod scheduling works.

How node pool autoscaling works

The GKE cluster autoscaler monitors pod scheduling and adjusts node counts in each pool automatically.

Scaling up happens when a pod cannot be scheduled because no node in the pool has enough CPU or memory. The autoscaler detects the unschedulable pod and adds a new node to the pool (up to --max-nodes). Once the node is ready, the pending pod is scheduled onto it.

Scaling down happens when a node has been underutilised for ten minutes and all its pods can safely move to other nodes. GKE cordons the node (marks it unschedulable), drains it (gracefully evicts pods, respecting PodDisruptionBudgets), then removes the node (down to --min-nodes).

Scale to zero is possible by setting --min-nodes=0. The pool runs no nodes at all when idle. When a pod needs that pool, the autoscaler provisions a new node.

Cluster autoscaler vs HPA. These two work at different layers and complement each other. The Horizontal Pod Autoscaler (HPA) scales the number of pod replicas based on CPU, memory, or custom metrics. When HPA adds more replicas than existing nodes can accommodate, the cluster autoscaler adds nodes. When load drops, HPA reduces replicas, nodes become underutilised, and the cluster autoscaler removes them. They are not alternatives to each other.

Update autoscaling settings on an existing pool:

gcloud container node-pools update batch-pool \
  --cluster=my-cluster \
  --zone=us-central1-a \
  --min-nodes=0 \
  --max-nodes=20

How to create a node pool in GKE

You must have a GKE Standard cluster running before adding node pools.

Standard general-purpose pool:

gcloud container node-pools create standard-pool \
  --cluster=my-cluster \
  --zone=us-central1-a \
  --machine-type=e2-standard-4 \
  --num-nodes=3 \
  --min-nodes=2 \
  --max-nodes=10 \
  --enable-autoscaling \
  --disk-size=100 \
  --disk-type=pd-ssd

GPU pool for ML workloads:

gcloud container node-pools create gpu-pool \
  --cluster=my-cluster \
  --zone=us-central1-a \
  --machine-type=n1-standard-4 \
  --accelerator=type=nvidia-tesla-t4,count=1 \
  --num-nodes=1 \
  --min-nodes=0 \
  --max-nodes=4 \
  --enable-autoscaling \
  --node-labels=workload=gpu \
  --node-taints=gpu=true:NoSchedule

Spot node pool for batch jobs:

gcloud container node-pools create batch-spot-pool \
  --cluster=my-cluster \
  --zone=us-central1-a \
  --machine-type=e2-standard-8 \
  --spot \
  --num-nodes=0 \
  --min-nodes=0 \
  --max-nodes=50 \
  --enable-autoscaling \
  --node-labels=workload=batch \
  --node-taints=spot=true:NoSchedule

Key flags explained:

• --machine-type — The Compute Engine machine type for every node in the pool.
• --num-nodes — Initial node count when the pool is created.
• --min-nodes and --max-nodes — The autoscaling range. Set --min-nodes=0 to allow scale to zero.
• --enable-autoscaling — Activates the cluster autoscaler for this pool.
• --node-labels — Kubernetes labels applied to every node. Used by nodeSelector in pod specs.
• --node-taints — Taints applied to every node. Pods must have a matching toleration to be scheduled here.
• --spot — Provisions Spot VMs, which cost significantly less but can be reclaimed with 30 seconds notice.
• --accelerator — Attaches GPU accelerators. Requires the NVIDIA GPU driver DaemonSet to be deployed separately.

List all pools in a cluster:

gcloud container node-pools list \
  --cluster=my-cluster \
  --zone=us-central1-a

Delete a pool:

gcloud container node-pools delete gpu-pool \
  --cluster=my-cluster \
  --zone=us-central1-a

Directing pods to the right node pool

Adding taints and labels to a node pool is only half the job. You also need to configure your pod spec to match.

A pod that should run on the GPU pool needs both a toleration (permitted on the tainted node) and a nodeSelector (actively steered toward the right pool):

apiVersion: v1
kind: Pod
metadata:
  name: ml-training-job
spec:
  tolerations:
    - key: "gpu"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  nodeSelector:
    workload: gpu
  containers:
    - name: trainer
      image: my-registry/ml-trainer:latest
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"
          nvidia.com/gpu: "1"
        limits:
          nvidia.com/gpu: "1"

The tolerations field permits the pod on the tainted GPU node. The nodeSelector actively steers it there. The nvidia.com/gpu resource request ensures the scheduler only considers nodes that have a GPU device available.

See Deploying Containers with kubectl and Deployments in Kubernetes for how to structure workloads for production use. When managing secrets that workloads in specific pools might need, see Managing Secrets in Kubernetes.

Common real-world node pool patterns

Most production GKE Standard clusters end up with two to four pools. Here are the most common patterns:

Default general-purpose pool

• Machine type: e2-standard-4 or e2-standard-8
• Purpose: web servers, APIs, background workers, standard microservices
• Autoscaling: yes, minimum of 2 nodes so the cluster is never empty
• Watch out for: keep this pool lean and affordable; most workloads fit here

GPU pool

• Machine type: n1-standard-4 with NVIDIA T4 or A100
• Purpose: ML training, inference serving, video processing
• Autoscaling: scale to zero when idle, max 4 to 8 nodes
• Watch out for: always add a NoSchedule taint; without it, general pods land on expensive GPU nodes

Spot batch pool

• Machine type: e2-standard-8 or n2-standard-8 with --spot
• Purpose: data pipelines, nightly ETL, image processing, large-scale jobs
• Autoscaling: scale to zero when idle, high maximum (20 to 100 nodes)
• Watch out for: workloads must handle interruption cleanly and must never be stateful

High-memory pool

• Machine type: n2-highmem-8 or n2-highmem-16
• Purpose: in-memory databases, analytics engines, workloads needing large RAM per pod
• Autoscaling: limited range to control costs
• Watch out for: confirm persistent volumes are configured correctly before this pool scales down

Windows pool

• Machine type: any compatible Windows Server node image
• Purpose: Windows containers, legacy .NET workloads requiring Windows runtime
• Watch out for: Linux and Windows pods cannot share nodes; a Linux pool must exist alongside it for any Linux workloads

Node pool upgrades

When a new Kubernetes version becomes available, both the control plane and node pools need upgrading separately. GKE performs surge upgrades by default: it adds a temporary extra node, migrates pods from the node being upgraded to the surge node, upgrades the original node, then removes the surge node. Pods stay running throughout.

Trigger a manual node pool upgrade:

gcloud container clusters upgrade my-cluster \
  --node-pool=standard-pool \
  --zone=us-central1-a

See Upgrading GKE Clusters Safely for the full upgrade playbook, including PodDisruptionBudgets and blue-green strategies.

Single pool vs multiple pools

Not every cluster needs multiple pools. Here is when to keep things simple and when the extra complexity is worth it:

The extra complexity of multiple pools pays off when the hardware or isolation requirement is real. Do not add pools for organisational tidiness — labels and namespaces handle logical separation without additional infrastructure. For more on how GKE compares to other container options, see GKE vs Cloud Run.

Monitoring and logging for node pools

Node pool health feeds directly into cluster observability. Nodes under pressure (high CPU, memory pressure, disk pressure) show status conditions visible via kubectl describe node. GKE also exposes these signals in Cloud Monitoring.

See Monitoring GKE Clusters for how to set up alerts on node pool utilisation, and Logging in Kubernetes for surfacing application logs from pods across pools.

For security-specific concerns around node pool configuration — including workload identity, network policies, and node hardening — see Securing GKE Clusters and Private GKE Clusters.