Build1 publisher2 min readPublished
EKS lets teams switch its managed scheduler to MostAllocated bin-packing
Amazon EKS now lets customers set selected scheduler, controller-manager and API-server parameters, including MostAllocated bin-packing, through its API. Teams that self-host only for such tuning now need a parameter AWS has not exposed.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Kubernetes' NodeResourcesFit plugin spreads pods toward emptier nodes by default under LeastAllocated; MostAllocated instead favors busier nodes and packs pods onto fewer machines.
- EKS also exposes API-server event retention and the Horizontal Pod Autoscaler sync period, shown in the post as an eventTtl of 30m and a 10s sync.
- The post lists the NodePort range and additional scheduler settings among the other supported options.
- Which parameters are available depends on the EKS configuration and Kubernetes version, and some settings require EKS Provisioned Control Plane.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team that self-hosts its control plane only to change scheduler scoring, event retention or autoscaler timing can now make that change on EKS and hand the control plane back to AWS.
- constraint Bin-packing saves money only if Karpenter, EKS Auto Mode or another consolidation tool removes the nodes MostAllocated empties, because the setting itself never deletes a node.
- exposure The setting applies cluster-wide, so bursty services that relied on spare capacity on every node lose that headroom once the scheduler starts packing.
In a self-managed cluster, the packing strategy lives in a file. The scheduler reads a KubeSchedulerConfiguration, apiVersion kubescheduler.config.k8s.io/v1, whose profile sets the NodeResourcesFit plugin's scoringStrategy type to MostAllocated [5]. On EKS, according to a dev.to walkthrough of the feature, the same change is one CLI call [6]:
``` aws eks update-cluster-config \ --name production-cluster \ --kube-scheduler-config \ '{"nodeResourcesFit":{"scoringStrategy":{"type":"MostAllocated"}}}' ```
AWS keeps operating the control plane underneath [1]. The JSON names one plugin and one field. I think a named field is the right surface for a managed control plane. The customer picks a strategy through the API that already manages the cluster, and running the scheduler process stays with AWS [1].
The post illustrates the effect with three nodes: 40%, 35% and 30% used under LeastAllocated, and 85%, 80% and 10% under MostAllocated [11]. The columns add to 105 and 175 percentage points [18]. If the three nodes are the same size, the packed layout carries 70 points more load than the spread one [18]. A scheduler moves pods; it does not make more of them. Treat the table as a sketch of the intended shape, two hot nodes and one nearly idle. The post's own claim is narrower and holds up: the packed layout can leave some nodes with little or no workload [12].
Whether a nearly idle node becomes a smaller bill is decided outside the scheduler. The post says changing placement does not automatically reduce infrastructure costs, and that the outcome depends on workloads, resource requests and how the provisioning or consolidation system responds [15]. A savings figure from someone else's cluster transfers only if those inputs match yours. The figure worth collecting is node count before and after, on your own cluster, with your own consolidation tool running. The post's advice is the short version: "start with a real problem, change one setting, and measure the result." [16]
The post describes the old EKS bargain as giving up some settings a self-managed cluster can change, in exchange for not operating the API server, scheduler or controller manager [2]. For teams whose only reason to self-host was one of the exposed parameters, that bargain now favors EKS. The post shows examples and does not give a complete parameter list [9], so a team holding out for a specific flag still has to check it against its own cluster version [10].
What to watch
- A per-version list from AWS of exposed parameters, showing whether the flags self-managed teams actually change are covered.
- Pricing and scope for EKS Provisioned Control Plane, since it gates some of these settings.
- Before-and-after node counts from production clusters running MostAllocated alongside Karpenter or Auto Mode consolidation.