Karpenter

Karpenter evaluates pod scheduling constraints directly rather than relying on predefined node group abstractions. It groups unschedulable pods by their combined affinity, topology spread, and resource requests, then launches the optimal instance type in real-time.

• Bin-packing: Consolidates pods onto fewer nodes to minimize waste
• Diverse instance selection: Automatically chooses from hundreds of instance types across families
• Taint handling: Respects node taints and tolerations without manual configuration

Unlike traditional cluster autoscalers that operate on a 10-60 second polling loop, Karpenter reacts to pod events within milliseconds. When a pod enters the scheduling queue and is marked unschedulable, Karpenter immediately calculates the required capacity and initiates a cloud provider RunInstances API call.

• Sub-second reaction: Provisions nodes as soon as pods are pending
• No node group pre-warming: Eliminates idle capacity costs
• Direct API integration: Bypasses Auto Scaling Group delays

Karpenter continuously evaluates the cluster for optimization opportunities. When it identifies that pods can be rescheduled onto fewer or cheaper nodes, it cordons and drains the underutilized node, then terminates it.

• Consolidation: Replaces multiple low-utilization nodes with a single node
• Drift detection: Replaces nodes when their AMI or userdata changes
• TTL-based expiry: Automatically recycles nodes after a configurable lifetime to enforce security hygiene

Karpenter separates core scheduling logic from cloud-specific implementation through a well-defined provider interface. The AWS provider is the reference implementation, but the architecture supports any cloud or on-premises environment.

• NodeClass CRD: Defines provider-specific configuration like subnets, security groups, and AMI families
• NodePool CRD: Defines scheduling constraints, resource limits, and disruption policies
• Extensible design: Community providers exist for Azure, GCP, and bare-metal via MaaS

Karpenter monitors provisioned nodes against their declared NodePool and NodeClass specifications. When it detects a configuration mismatch—such as an outdated AMI, changed security group, or modified subnet—it marks the node for graceful replacement.

• AMI drift: Automatically rolls nodes when a new AMI is published
• UserData drift: Replaces nodes when bootstrap scripts change
• Feature drift: Reacts to changes in instance profile or launch template settings
• Zero-downtime replacement: Respects PodDisruptionBudgets during node rotation

Karpenter provides granular disruption controls to prevent service impact during node consolidation and replacement. Administrators define budgets that limit the rate and scope of voluntary disruptions.

• NodePool-level budgets: Control how many nodes can be disrupted simultaneously
• Schedule-based policies: Define maintenance windows for disruptive operations
• Reason-specific controls: Set separate budgets for consolidation, drift, and expiration events
• PodDisruptionBudget awareness: Respects application-level availability guarantees