Karpenter — Just-in-Time Kubernetes Node Autoscaler for AWS
AWS-origin cluster autoscaler that launches the right EC2 instance shape and size for pending pods in ~30 seconds.
Installation agent prête
Cet actif peut être installé après choix du runtime, vérification du plan et exécution de la commande adaptée.
npx -y tokrepo@latest install de139dca-38ef-11f1-9bc6-00163e2b0d79 --target codexÀ exécuter après confirmation du plan en dry-run.
What it is
Karpenter is an open-source Kubernetes node autoscaler that originated at AWS and is now a CNCF project. It watches for pending pods and launches the right-sized EC2 instance type in approximately 30 seconds, bypassing the traditional Auto Scaling Group approach used by the Cluster Autoscaler.
Karpenter is designed for platform engineers and DevOps teams running EKS or self-managed Kubernetes on AWS who want faster scaling and lower compute costs.
How it saves time or tokens
The traditional Cluster Autoscaler adds nodes by scaling pre-defined Auto Scaling Groups, which forces you to choose instance types in advance. Karpenter selects the optimal instance type at scheduling time based on actual pod requirements. It also consolidates underutilized nodes, moving workloads to fewer, better-utilized instances. Teams report 30-60% compute cost reduction compared to static ASG-based scaling.
How to use
- Install Karpenter on an existing EKS cluster:
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
--namespace kube-system --version 1.0.6 \
--set "settings.clusterName=${CLUSTER}" \
--set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${ROLE_ARN}"
- Create a NodePool and EC2NodeClass:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: karpenter.k8s.aws/instance-category
operator: In
values: [c, m, r]
- key: karpenter.sh/capacity-type
operator: In
values: [on-demand, spot]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
- Deploy workloads normally; Karpenter handles node provisioning automatically.
Example
When a deployment scales up and pods are pending:
# Scale a deployment
kubectl scale deployment my-app --replicas=50
# Karpenter detects pending pods and selects optimal instances
# Watch nodes appearing:
kubectl get nodes -w
# NAME STATUS ROLES AGE
# ip-10-0-1-42.ec2.internal Ready <none> 32s
Related on TokRepo
- DevOps tools — infrastructure automation and Kubernetes management
- Automation tools — automated scaling and provisioning
Common pitfalls
- Karpenter requires IRSA (IAM Roles for Service Accounts) to be configured; without it, the controller cannot launch EC2 instances
- Setting overly broad instance-category requirements can lead to Karpenter choosing unusual instance types; constrain to c, m, r families for general workloads
- Consolidation can disrupt stateful workloads; use the
do-not-disruptannotation on pods that should not be moved
Questions fréquentes
Karpenter is primarily built for AWS and uses the EC2 API directly. There are experimental community providers for Azure and GCP, but the production-grade implementation targets EKS and self-managed Kubernetes on AWS. The CNCF project governance is working on multi-cloud support.
Cluster Autoscaler scales pre-defined Auto Scaling Groups, requiring you to choose instance types in advance. Karpenter selects the optimal instance type at scheduling time based on actual pod requirements, supports mixed instance types, and provisions nodes directly via the EC2 API without ASG overhead.
Yes. You configure capacity-type in the NodePool requirements to include spot. Karpenter automatically selects Spot instances when available and handles Spot interruption notices by draining and replacing nodes.
Karpenter identifies underutilized nodes and cordons them, allowing pods to be rescheduled to other nodes. It then terminates the empty node. The consolidationPolicy setting controls whether this happens only when nodes are empty or also when they are underutilized.
It is possible but not recommended. Running both can cause conflicts where each tries to scale nodes independently. The recommended migration path is to gradually move node groups from Cluster Autoscaler to Karpenter NodePools.
Sources citées (3)
- Karpenter GitHub— Karpenter provisions right-sized EC2 instances for pending pods
- Karpenter Docs— CNCF project for Kubernetes node autoscaling
- AWS Documentation— EKS best practices for Karpenter
En lien sur TokRepo
Fil de discussion
Actifs similaires
Goldilocks — Right-Size Kubernetes Resource Requests
Goldilocks is a Kubernetes utility by Fairwinds that uses the Vertical Pod Autoscaler to generate resource request and limit recommendations, helping teams optimize costs and prevent OOM kills.
OpenCost — Real-Time Kubernetes Cost Monitoring
Monitor and allocate Kubernetes infrastructure costs in real time. A CNCF sandbox project that gives teams visibility into cluster spend by namespace, pod, and label.
AutoGluon — AutoML for Tabular, Time-Series, Text, and Image Data
AutoGluon is AWS's AutoML toolkit. With one .fit() call it trains state-of-the-art ensembles on tabular, time-series, text, and image data — often beating hand-tuned models written by ML engineers.
Dozzle — Real-Time Container Log Viewer
Dozzle is a lightweight, self-hosted web application that streams Docker, Swarm, and Kubernetes container logs in real time through a clean browser-based UI with no database or persistent storage required.