Karpenter went from v1.0 to v1.15 in two years: static capacity, NodeOverlay for pricing and capacity overrides, NodePool node limits, a grace period for do-not-disrupt, a Balanced consolidation policy, CapacityBuffer and DRA for GPUs. What each is for, a production NodePool, and the case for letting EKS Auto Mode run it.
Karpenter watches for pods that cannot be scheduled, chooses instances that fit them from the whole EC2 catalogue, launches them in seconds and removes nodes that are no longer needed. The v1 APIs (NodePool, EC2NodeClass, NodeClaim) have been stable since August 2024, and releases since have filled in the gaps people used to work around.
From the kubernetes-sigs/karpenter release notes.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Static capacity (alpha): a NodePool with a fixed replica count, for workloads that need a set number of nodes regardless of pending pods. It replaces the managed node group many teams kept beside Karpenter for exactly this.
NodeOverlay: override what Karpenter believes an instance costs or offers. Useful when you have a Savings Plan or Reserved Instances that make one family cheaper than list price, or extended resources Karpenter cannot discover.
Node limits per NodePool: cap node count, not only CPU and memory, which is how licensing and IP-address constraints are usually expressed.
Do-not-disrupt grace period: the annotation protects a pod for a bounded time instead of forever, so one long-running pod no longer blocks consolidation and upgrades indefinitely.
Balanced consolidation: weighs the saving against the disruption, rather than consolidating whenever a cheaper arrangement exists. A better default for clusters where restarts are expensive.
CapacityBuffer (alpha): keeps spare capacity warm so scale-out does not wait for an instance launch.
Allow a wide set of instance families and sizes, both arm64 and amd64 if your images are multi-arch. Breadth is what lets Spot and consolidation find savings.
Separate NodePools for Spot-tolerant and on-demand-only workloads, selected by labels or taints, with weights so the cheaper pool is tried first.
expireAfter set (for example 30 days), so nodes are replaced regularly and pick up new AMIs; drift handles AMI changes in between.
Disruption budgets that limit how many nodes are replaced at once, and a schedule that blocks disruption during business-critical hours.
PodDisruptionBudgets on every service with more than one replica. Karpenter respects them; without them, consolidation can take all replicas down at once.
Bottlerocket or AL2023 AMIs. Amazon Linux 2 reached end of life in June 2026.
EKS Auto Mode runs Karpenter for you, off-cluster, along with the load balancer controller, EBS CSI driver and node OS. You pay a per-instance management fee on top of EC2 (for example $0.02064 an hour on an m5a.xlarge), and AWS chooses the Karpenter version and AMI.
Choose Auto Mode when the team does not want to own Karpenter upgrades, controller IAM and AMI choice, and the fee is small relative to engineering time.
Run Karpenter yourself when you need features as soon as they ship (static capacity, overlays, CapacityBuffer), custom AMIs or a large fleet where the fee adds up.
You can mix them: Auto Mode for general workloads, self-managed Karpenter NodePools for GPUs or specialised capacity.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
An EKS Reference Architecture for 2026, With Diagrams: The Small-Team Version and the Regulated Version
What a production EKS setup looks like in 2026, layer by layer: edge, entry, cluster, platform add-ons, data, security and observability. A lean version for a small team on Auto Mode, and a regulated version with separate node pools, network policies and audit logging, with the choices behind each box.
Read
EKS Spend Control: Where Kubernetes Money Leaks, and How to See It Per Team
EKS bills are mostly nodes, and nodes are sized by what pods request, not what they use. The leaks we find most (inflated requests, half-empty nodes, cross-AZ chatter, one load balancer per service, clusters on extended support) and how split cost allocation data puts a price on every namespace in the Cost and Usage Report.
Read
As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.