Karpenter supplies new worker machines when Kubernetes workloads cannot fit on suitable existing capacity. It considers the workloads' requirements and the allowed node choices, then can consolidate capacity when workloads can be moved under the configured rules. It is useful when flexible provisioning fits better than a small set of fixed node groups. Resource requests, placement restrictions and disruption controls still determine what capacity can be created or removed.
Deployment and operating notes
On EKS, distinguish operating Karpenter yourself from using EKS Auto Mode's AWS-managed capabilities.
Upgrade the right layers
Inventory the controller, CRDs, NodePools, NodeClasses, node images and cloud permissions. Read the upgrade guide for every crossed compatibility boundary. Updating only the controller image does not establish that the surrounding APIs and cloud integration are ready.
Scheduling and disruption
Check resource requests, architecture, instance constraints, availability zones, storage topology and disruption budgets. A pending pod or an unconsolidated node can be the correct result of those constraints. Diagnose events and workload requirements before weakening safeguards.
Use the consolidation checklist for a bounded investigation, and the EKS comparison for ownership choices. This entry does not promise a particular cost saving.
Sources & further reading
Spotted something that needs another look?
Help improve this page →