_Update: AWS ended support for EKS-optimized Amazon Linux 2 AMIs in November 2025; use Amazon Linux 2023 or Bottlerocket for new node groups._
Correction, September 23, 2026: this post previously said kube-proxy stayed on the managed node group; kube-proxy is a DaemonSet that runs on every node, including Karpenter-managed nodes.
Running production Kubernetes workloads in a cloud-native SaaS environment demands scalable infrastructure that adapts to changing demands. Manual node scaling quickly becomes impractical as workloads grow, making automated solutions essential for sustainable infrastructure management.
The Starting Point
PointFive initially deployed EKS with a single Managed Node Group using Amazon Linux 2 AMI nodes. This group handled both application pods and Kubernetes add-ons (CoreDNS, kube-proxy, and similar system components). As the pod population expanded with increasing memory and CPU requirements, the limitations of this static approach became clear.
The team established two priorities for the next iteration:
- Scaling with Simplicity -- efficient worker node scaling without manual instance type management
- FinOps Focus -- cost-effective instance selection while maintaining the performance characteristics workloads required
Karpenter vs. Kubernetes Cluster Autoscaler
Karpenter and Cluster Autoscaler both automate node capacity, but use different provisioning models.
Provisioning: Karpenter selects capacity within NodePool requirements. On AWS, Cluster Autoscaler changes the size of configured node groups; mixed-instance groups are supported, with documented requirements for consistent scheduling assumptions.
Scale-down: Cluster Autoscaler can remove nonempty, underutilized nodes when their pods can be rescheduled and applicable constraints allow it. It is not limited to empty nodes. Karpenter consolidation can remove nodes or replace capacity, subject to scheduling constraints and disruption controls.
Performance and cost: Provisioning latency and savings depend on workload requirements, available capacity, configuration, and disruption tolerance. Neither architecture guarantees a faster start or the lowest price in every environment.
Sources: Cluster Autoscaler FAQ and Karpenter disruption documentation, checked September 17, 2026.
Implementation Architecture
Dedicated Scheduling Strategy
The team adopted a split-responsibility approach:
- Cluster add-on Deployments such as CoreDNS remained on the EKS Managed Node Group for stability (DaemonSets such as kube-proxy run on every node)
- Application workloads were delegated entirely to Karpenter-managed nodes
This separation ensures that system-critical components run on predictable, stable infrastructure while application pods benefit from Karpenter's dynamic scaling and cost optimization.
NodePool Configuration
A single primary NodePool defined the provisioning blueprint. Key configuration parameters included:
- Consolidation Policy:
WhenEmptyOrUnderutilized-- Karpenter identifies and disrupts nodes that are empty or not efficiently packed - Resource Limits: 1000 CPU and 1000Gi memory as upper bounds for the NodePool
- Architecture: arm64 for cost efficiency
- Instance Categories: c (compute), m (general purpose), and r (memory-optimized) families, generation 2 and above
- Availability Zones: us-east-1a, us-east-1b, us-east-1c for distribution
Key Lessons and Best Practices
Minimize NodePools
A single NodePool can serve multiple teams and workloads effectively. Additional NodePools should only be created when there are concrete requirements for billing isolation, specific hardware constraints, or distinct disruption policies.
Set Node Expiration
Configuring an expireAfter value ensures regular node cycling. Replacement nodes use the AMI selected by the node configuration; expiration alone does not guarantee the latest patched image. Maintain and validate that configuration separately.
Maintain a Broad Instance Type Range
Keeping instance type requirements flexible allows Karpenter to select the most cost-effective and available options that match workload demands. Overly constraining instance types defeats the purpose of dynamic provisioning.
Enable Consolidation
The WhenEmptyOrUnderutilized consolidation policy permits consideration of underutilized nodes. Choose disruption settings around workload availability requirements and validate the resulting cost and reliability changes.
Scaling Up Without Scaling Out of Control
Karpenter is an evolving tool that continues to add capabilities. For organizations running EKS at scale, it provides a path to efficient, cost-optimized Kubernetes infrastructure that adapts dynamically to workload demands. The combination of automatic instance selection, active consolidation, and simplified configuration means teams can focus on their applications rather than managing node groups manually.