Free tools Windows power users keep installed
One-click scans. No signup required.
Karpenter watches for pods Kubernetes has marked unschedulable, works out what node capacity could satisfy them, and provisions that capacity. It does not place pods itself: Kubernetes’ kube-scheduler makes the final assignments. Later, Karpenter can consolidate or replace nodes and gracefully drain them before terminating their cloud instances.
What Karpenter’s controller does
Karpenter is an open-source Kubernetes node lifecycle management project. Its controller responds to scheduling demand and manages the lifecycle of the nodes it provisions. The key distinction is that Karpenter supplies capacity; Kubernetes remains responsible for scheduling pods onto nodes. The Karpenter documentation describes its project scope and behavior.
How it decides what capacity to provision
It starts with unschedulable pods
When the Kubernetes scheduler finds that a pod cannot be scheduled with the available cluster capacity, Karpenter can evaluate that pod’s requirements and plan additional nodes. Pod resource requests, node selectors, affinity, tolerations, and topology spread constraints all affect which nodes would be suitable.
NodePools set infrastructure boundaries
A NodePool limits the kinds of capacity Karpenter may choose. Its requirements can constrain instance types, zones, CPU architecture, or capacity type, such as spot or on-demand. A feasible choice must satisfy both the workload’s needs and the pool’s limits, as well as what the cloud provider offers. For example, a pod requiring a zone excluded by the relevant NodePool cannot be placed using capacity from that pool.
#1 Best Overall
Karpenter simulates how pending pods might fit together on prospective nodes—often described as bin-packing—to plan what to launch. This is a planning step, not a guarantee of final placement. The Karpenter scheduling documentation explains how pod requirements and provisioning constraints interact; NodePools documentation covers pool-level requirements.
How Karpenter and kube-scheduler divide the work
Karpenter’s simulation estimates which nodes can accommodate pending pods, but it does not bind those pods to nodes. The Kubernetes kube-scheduler performs the actual placement. That division matters: if the scheduler’s eventual placement differs from Karpenter’s simulation, the resulting nodes can be less efficiently packed than planned, leaving room for later consolidation. The Kubernetes cluster architecture documentation describes the scheduler’s role.
| Component | Role |
|---|---|
| Karpenter | Evaluates unschedulable pods against NodePool constraints and plans and provisions node capacity. |
| Kubernetes kube-scheduler | Makes the actual pod-to-node placement decision. |
How Karpenter removes or replaces nodes
Provisioning is only part of the lifecycle. Karpenter can initiate voluntary disruption for consolidation or drift, while external events such as a cloud capacity interruption can also cause a node to go away. These cases are not interchangeable: voluntary actions follow Karpenter’s disruption controls, whereas an external interruption can originate outside its normal decision process.
Consolidation looks for a more efficient cluster
Consolidation can remove empty nodes, remove nodes when their workloads can run elsewhere, or replace nodes with lower-priced variants. It is constrained by scheduling feasibility, configured requirements, disruption controls, and available cloud capacity; it is not a promise that every workload will move to the cheapest possible instance. Because Karpenter’s initial packing is a simulation, consolidation may also address nodes that ended up under-packed after kube-scheduler placed pods.
Rank #3
Drift responds to changed desired configuration
Drift disruption applies when a node has diverged from the desired configuration. It is separate from consolidation: one responds to configuration divergence, while the other seeks to improve node use or cost.
Budgets and workload protections affect voluntary disruption
Before voluntary disruption, Karpenter evaluates candidates and disruption budgets, then simulates whether affected pods can be rescheduled. Budgets can limit how quickly voluntary actions begin. PodDisruptionBudgets and workload protections also matter to whether and how pods can be evicted, so a theoretically useful consolidation may not proceed immediately.
Once Karpenter selects a node for voluntary disruption, it taints the node and, when required, provisions replacement capacity and waits for it before deleting the old node. Details of consolidation, drift, budgets, and termination are in the Karpenter disruption documentation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What happens during graceful node termination
Karpenter uses a finalizer to control orderly termination. The termination controller taints the node, drains pods through Kubernetes’ Eviction API, waits for drainable volume attachments to be removed, terminates the associated NodeClaim in the cloud provider, and then removes the finalizer. This sequence gives workloads and attached storage a managed shutdown path rather than treating deletion of the Kubernetes Node object as equivalent to shutting down the machine.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
That distinction matters operationally: deleting a Node object without Karpenter’s finalizer can leave the underlying cloud instance running. The Kubernetes object and the cloud resource are related, but they are not the same thing.
Quick Recap
A practical way to reason about Karpenter
- No capacity fits: Check the pod’s requests and placement constraints, then confirm a NodePool permits matching zones, architecture, instance types, and capacity types.
- A node appears underused: Remember that Karpenter planned capacity but kube-scheduler made the final placements; consolidation may later attempt a more efficient arrangement if disruption controls allow it.
- A node does not disappear: Voluntary disruption may be constrained by budgets, rescheduling feasibility, eviction protections, or the need to wait for replacement capacity and volume detachment.
- A machine remains after a Node disappears: Verify the node termination path; deleting the Kubernetes object without the finalizer can leave its cloud instance running.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
