NodePool says which nodes are acceptable; EC2NodeClass says how AWS builds them.

That separation lets several pools share one infrastructure recipe, or one pool target different recipes.

NodePool (scheduling policy)

apiVersion: karpenter.sh/v1
kind: NodePool
metadata: {name: general}
spec:
  template:
    spec:
      requirements:
      - {key: karpenter.sh/capacity-type, operator: In, values: [spot, on-demand]}
      - {key: kubernetes.io/arch, operator: In, values: [amd64, arm64]}
      - {key: karpenter.k8s.aws/instance-category, operator: In, values: [c, m, r]}
      nodeClassRef: {group: karpenter.k8s.aws, kind: EC2NodeClass, name: default}
      expireAfter: 720h
  limits: {cpu: "1000"}
  disruption: {consolidationPolicy: WhenEmptyOrUnderutilized, consolidateAfter: 1m}

EC2NodeClass (infrastructure)

kind: EC2NodeClass
metadata: {name: default}
spec:
  amiSelectorTerms: [{alias: al2023@latest}]
  role: KarpenterNodeRole-shop-eu
  subnetSelectorTerms: [{tags: {karpenter.sh/discovery: shop-eu}}]
  securityGroupSelectorTerms: [{tags: {karpenter.sh/discovery: shop-eu}}]

Limits cap the bill

limits.cpu stops a runaway scale-up from launching unlimited nodes.

Check your version

Field names changed between Karpenter releases. This is the v1 API shape; confirm against the docs for your installed version.

NodePool and EC2NodeClass: what may launch, and how

Karpenter splits its configuration into two custom resources. The NodePool expresses scheduling policy using the same vocabulary you know from Pod affinity: which capacity types (Spot, On-Demand), architectures (amd64, arm64 for Graviton), instance categories and sizes are acceptable, plus limits on total capacity, disruption behaviour and node lifetime. The EC2NodeClass describes the AWS infrastructure: which AMI, which subnets and security groups (usually selected by tag), and which instance IAM role.

Why split them? One infrastructure recipe, for example the AMI and subnets of your private network, can back several NodePools such as a general pool, a Spot batch pool and a GPU pool, each with different requirements and taints. You can also swap the recipe, say moving to a new AMI, without touching scheduling policy.

The settings with the most operational impact are limits (a hard ceiling on provisioned CPU or memory), the disruption block (how aggressively to consolidate), and expireAfter (nodes are recycled after a lifetime so they pick up new AMIs). Keep the pool broad: the more instance types Karpenter may choose from, the better its price and Spot availability.

Version note: the API changed in Karpenter 1.0, for example how AMIs are selected. The YAML here follows the v1 shape. Always read the upgrade guide for your version before applying examples copied from older blog posts.