Karpenter Node Lifecycle: NodePools, NodeClaims, Scheduling, Consolidation, and Disruption
How Karpenter provisions right-sized Kubernetes nodes for pending pods and safely manages Spot, expiration, consolidation, IAM, and production disruption on EKS.
Pod autoscaling changes replica count; node autoscaling supplies machines on which those pods can run. Karpenter watches pods the Kubernetes scheduler marks unschedulable, evaluates their requests and constraints, and asks a supported cloud provider for suitable capacity. It is more direct than maintaining many pre-shaped autoscaling groups, but it still depends on correct pod requests and cloud permissions.
NodePools, NodeClasses, and NodeClaims
A NodePool defines scheduling constraints, limits, weights, and disruption behavior. Provider-specific NodeClass resources describe infrastructure details; on AWS the current resource is EC2NodeClass. Karpenter creates immutable NodeClaim objects as capacity requests and tracks launch, registration, initialization, and termination. Older Provisioner examples should not be copied into current configurations without migration context.
Scheduling and capacity choice
Pod resource requests, architecture, zones, affinities, topology spread, node selectors, taints, and tolerations constrain viable instances. A broad NodePool lets Karpenter compare more instance types. Capacity type can include On-Demand and Spot; Spot lowers price but requires interruption-tolerant workloads and enough alternatives when a pool is unavailable.
Consolidation and disruption
Karpenter can remove empty nodes, consolidate underutilized capacity, replace drifted nodes, and expire nodes according to policy. NodePool disruption budgets rate-limit voluntary changes. Pod Disruption Budgets influence eviction but cannot guarantee availability against every involuntary failure or forced expiration. Stateful workloads, local storage, DaemonSets, and long termination periods require explicit tests.
EKS security and operations
The controller needs narrowly scoped AWS permissions and a stable place to run that does not depend on the capacity it is trying to create. Interruption handling should process Spot and maintenance events. Monitor controller logs, NodeClaim conditions, provisioning latency, unavailable instance types, voluntary disruptions, pending pods, and cost by NodePool.
Start with conservative consolidation and expiry, constrain total resources, spread critical replicas, and rehearse interruption. Karpenter can improve efficiency, but an overly broad permission set or aggressive disruption policy can replace nodes faster than workloads recover.
Sources: Karpenter concepts, NodeClaims, Karpenter getting started on EKS