Karpenter is an open-source Kubernetes node autoscaler, originally developed by AWS and donated to the CNCF, that provisions and deprovisions EC2 nodes on demand by interacting directly with cloud provider APIs rather than through static node groups. Unlike the traditional Cluster Autoscaler, Karpenter takes a groupless, just-in-time approach: it watches for unschedulable pods, batches them, simulates scheduling requirements, and calls the EC2 Fleet API to launch precisely right-sized nodes within seconds. The key mental model is that Karpenter manages the full node lifecycle — provisioning, bin-packing, consolidation, drift, expiration, and interruption handling — using two CRDs: the provider-agnostic NodePool and the AWS-specific EC2NodeClass.
What This Cheat Sheet Covers
This topic spans 18 focused tables and 149 indexed concepts, 102 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Core Architecture and Components
Karpenter's architecture separates provisioning policy from cloud-specific configuration into two CRDs, and uses a controller that watches Kubernetes API events to drive all node lifecycle decisions. Understanding the relationship between these components is the foundation for configuring and troubleshooting Karpenter effectively.
| Component | Example | Description | |
|---|---|---|---|
apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: default spec: template: spec: nodeClassRef: group: karpenter.k8s.aws kind: EC2NodeClass name: default | • Provider-agnostic CRD that defines scheduling constraints, capacity limits, disruption policy, and node expiration • every NodePool must reference an EC2NodeClass | ||
apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: default spec: amiSelectorTerms: - alias: al2023 role: "KarpenterNodeRole-my-cluster" | • AWS-specific CRD that defines AMI selection, subnets, security groups, IAM role, kubelet config, and user data • multiple NodePools can share one EC2NodeClass | ||
apiVersion: karpenter.sh/v1 kind: NodeClaim spec: requirements: - key: node.kubernetes.io/instance-type operator: In values: ["c5.large"] - key: karpenter.sh/capacity-type operator: In values: ["spot"] | • Karpenter-internal CRD representing a single requested node • created automatically during provisioning and tracks the node from request through registration | ||
kubectl logs -n kube-system -l app.kubernetes.io/name=karpenter | Kubernetes controller that watches unschedulable pods, runs scheduling simulations, creates NodeClaims, calls the EC2 Fleet API, and drives all disruption workflows. | ||
Direct API call (no ASG) | Karpenter bypasses Auto Scaling Groups and calls EC2 Fleet directly, enabling millisecond-level provisioning decisions and support for flexible instance type lists. | ||
Cloud provider → NodePool → Pod spec | Karpenter intersects three layers of constraints — cloud provider, cluster admin (NodePool/EC2NodeClass), and pod spec — to determine the final node configuration. | ||
Tracks NodeClaims before node is Ready | Karpenter tracks nodes already requested (via NodeClaims) before they appear in the cluster, preventing duplicate provisioning when multiple pods arrive simultaneously. | ||
Runs internally before NodeClaim creation | Before requesting an instance, Karpenter simulates scheduling all pending pods against its NodePools to pick the most efficient instance type(s) for the batch. |