Implementing a Node Pool Recommendation

When RealTheory generates a node pool recommendation, it identifies the optimal node type and node count for your workloads based on a deep analysis that includes resource demand, overhead, scheduling constraints, and cost. This article explains what changes a recommendation typically involves and how to implement those changes in AWS, Azure, and GCP.

See Understanding Node Pools

What a Node Pool Recommendation Changes

RealTheory node pool recommendations address two things:

• Node type — the machine or instance type that determines the CPU, memory, and other capabilities of each node in the pool. RealTheory selects the type that best fits your workload profile at the lowest cost.
• Node count — the number of nodes needed to run your workloads with appropriate headroom. RealTheory calculates the minimum node count required based on limiting factors such as CPU, memory, and pod scheduling capacity.

Before you Implement

Before you make any changes, confirm the following:

• Review the recommendation confidence level. High confidence means RealTheory has sufficient data to make a reliable recommendation. Medium or Low confidence means less data was available — verify against known resource patterns or consider waiting for more metrics before acting.
• Check for autoscaling. If your node pool uses autoscaling, changing the node count might conflict with your autoscaler configuration. Review your min/max settings after implementing the recommendation.
• Plan for disruption. Changing the node type requires replacing nodes, which involves draining workloads and rescheduling them. Plan this during a low-traffic window and ensure you have sufficient replicas to maintain availability during the transition.

Important: Changing node type is not an in-place operation on any cloud provider. It always requires creating new nodes and migrating workloads from the old ones. The process varies by provider — see the sections below for details.

Implementing the Recommendation by Provider

AWS — Amazon EKS

Changing node count

Node count changes can be made directly by updating the scaling configuration of your managed node group. This does not require node replacement and takes effect quickly.

Update a managed node group

Changing instance type

EKS managed node groups do not support changing the instance type in place. The recommended approach is to create a new node group with the recommended instance type, allow it to reach a ready state, then delete the old node group. EKS will drain pods from the old nodes before terminating them.

Managed node groups overview
Create a managed node group

Azure — AKS

Changing node count

Node count can be updated directly using the Azure CLI or Azure Portal without replacing nodes.

Scale node pools in AKS
Manually scale nodes in an AKS cluster

Changing VM size

AKS does not support changing the VM size of an existing node pool after creation. To change the VM size, you must create a new node pool with the recommended VM size, cordon and drain the existing nodes to migrate workloads, then delete the old node pool.

Resize node pools in AKS

GCP — GKE

Changing node count

Node count can be updated directly using the Google Cloud Console or gcloud CLI. If autoscaling is enabled, update your min/max node count settings accordingly.

Add and manage node pools in GKE

Changing machine type

GKE Standard clusters support updating the machine type of an existing node pool directly. GKE will automatically recreate the nodes using the configured upgrade strategy — by default, a rolling update — which minimises disruption to running workloads. If you use the blue-green upgrade strategy, you can migrate workloads progressively and roll back if needed.

Note: This machine type update triggers an immediate node recreation regardless of active maintenance policies. Plan accordingly.
Update node pool machine attributes in GKE
About node pools in GKE

After Implementing Node Pool Changes

• Monitor your cluster for a period after the change to confirm workloads are performing as expected on the new node type.
• Check back in RealTheory — as new metrics are collected against the updated configuration, recommendations will reflect the latest observed behavior.
• If you have autoscaling configured, verify that your min/max node count settings align with the recommended node count.

See Also
Understanding Node Pools
Understanding Recommendation Confidence in RealTheory