Karpenter Blueprints on AWS, services only

warashiba

Published Oct 9, 2026

Last modified Oct 9, 2026

The Auto Mode template cannot run five of its own blueprints

Five blueprints marked ✅ for Auto Mode say "This blueprint uses the default NodePool and requires no custom NodePool or EC2NodeClass manifests":

ha-az-nodes;
graviton;
stateful;
batch-jobs;
overprovision.

Their workloads all select nodeSelector: intent: apps.

That label is set by exactly one thing in the repository: the default NodePool in cluster/terraform/karpenter.tf, the self-managed template. The Auto Mode template, cluster/automode/main.tf, creates no NodePool. It enables only the built-in pool (node_pools = ["general-purpose"]). The EKS user guide describes that pool as:

amd64 only;
On-Demand only;
C, M and R families, generation 5 or newer;
with no intent label.

So on the cluster the repository builds for Auto Mode:

blueprint	what happens	why
ha-az-nodes, stateful, batch-jobs, overprovision	pods stay Pending	no NodePool offers intent: apps
graviton	pods stay Pending, for two reasons	no intent: apps, and workload-graviton.yaml requires kubernetes.io/arch: arm64, which the built-in pool never launches

The repository's own evidence suggests the Auto Mode results were produced on a different cluster. The overprovision README, an Auto Mode-only blueprint, shows its expected output as nodes named default-… on m6g.xlarge, a Graviton instance. The built-in pool's nodes are named after general-purpose, and it cannot launch arm64. Those results came from a cluster with a custom default NodePool, and that NodePool is not in the repository.

This is inferred from the manifests and the user guide, not run. The fix is one manifest: the Auto Mode equivalent of the self-managed template's default NodePool, applied after terraform apply in cluster/automode/:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      labels:
        intent: apps
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: eks.amazonaws.com/instance-cpu
          operator: In
          values: ["4", "8", "16", "32", "48", "64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: eks.amazonaws.com/instance-category
          operator: In
          values: ["c", "m", "r"]
      expireAfter: 336h
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

It mirrors cluster/terraform/karpenter.tf with three changes:

the eks.amazonaws.com NodeClass and label prefix;
the i and d instance categories dropped, keeping to the families the user guide documents for Auto Mode's own pools — add them back if your Region and quota allow;
expireAfter at the 336-hour limit.

The default NodeClass it references is the one Auto Mode creates when a built-in pool is enabled. Spot needs the EC2 Spot service-linked role. The README's aws iam create-service-linked-role --aws-service-name spot.amazonaws.com step applies to Auto Mode too.

Balanced consolidation: the repository and the user guide disagree

The balanced-consolidation blueprint says, in its own README:

EKS Auto Mode is not currently supported. Auto Mode ships a bundled Karpenter build that is behind OSS v1.14, so the NodePool CRD in Auto Mode does not yet list Balanced as a valid consolidationPolicy. Applying this blueprint on Auto Mode fails with Unsupported value: "Balanced"…

The EKS user guide's Create a Node Pool for EKS Auto Mode page, read on 5 October 2026:

lists Balanced among the consolidationPolicy values, as "Scores each consolidation action by weighing disruption cost against cost savings";
uses consolidationPolicy: Balanced in its example NodePool.

One of the two is out of date. The user guide is the newer and more authoritative source, and the blueprint's note reads like a statement about one point in time. The quick test is to apply the blueprint's NodePool to an Auto Mode cluster, changing nodeClassRef.group to eks.amazonaws.com as the blueprint itself instructs. If the API server accepts it, the ❌ in the table should become ✅.

The self-managed template, read for what it actually does

The README describes an older template. It says the template uses "IAM Roles for Service Accounts (IRSA)" and "configures the Karpenter node role to the aws-auth configmap". The code does neither:

cluster/terraform/karpenter.tf:19 sets create_pod_identity_association = true, so Karpenter's controller identity comes from EKS Pod Identity;
the eks-pod-identity-agent add-on is installed before_compute;
the EBS CSI driver also uses a Pod Identity association;
the EKS module is v21, which manages node access with access entries, not aws-auth.

The code is right; the README paragraph is stale.

Other things worth knowing before copying it:

line	what it does	consider
karpenter.tf amiSelectorTerms: - alias: al2023@latest	every new AL2023 AMI drifts every Karpenter node	fine for a sandbox. In production, pin a version (al2023@v2026…) and move it deliberately; the update-nodes-with-drift blueprint shows how
main.tf:116 managed node group types m4.large, t2.large, m5…, t3…	the two nodes that run Karpenter itself	m4 and t2 are previous-generation; drop them
main.tf:72 kubernetes_version = "1.34"	the tested version	EKS standard support for 1.34 ends 2 December 2026, then the cluster bills extended support unless upgraded
helm_release.karpenter webhook.enabled: false	correct for Karpenter v1	—

Versions disagree across the repository:

where	EKS module	AWS provider
README "Supported Versions"	v21.10.1	—
cluster/terraform/main.tf	~> 21.6	~> 6.23
cluster/terraform/karpenter.tf (Karpenter submodule)	21.19.1	—
cluster/automode/main.tf	20.31.0	~> 5.34

The two templates use different major versions of both the EKS module and the AWS provider. Each works on its own, since they are separate directories. The Auto Mode template, though, is one major version behind the one the README says was tested. Its argument names (cluster_name, cluster_compute_config) are the v20 names, which v21 renamed.

Which to run, for an AWS-only stack

Start with Auto Mode, plus the NodePool above. That covers the blueprints most teams need:

spreading across AZs;
splitting Spot and On-Demand;
reserved capacity;
drift updates;
disruption budgets;
GPUs and Neuron;
SOCI;
static capacity.

AWS runs the controller and ships the AMIs, the GPU and Neuron plugins, and the EBS driver.

Move to self-managed Karpenter only for a named reason from the ❌ list: a custom AMI or user data, a disk layout Auto Mode will not build, or a Karpenter feature it does not expose yet. Each of those reasons is in the table, and none is "Karpenter is more flexible" in general.

Verified, and not

Read in the repository (cloned 5 October 2026, d1d145a):

the README's Auto Mode list and supported-versions table;
the Auto Mode statements in each blueprint README, including the five "uses the default NodePool" sections and the balanced-consolidation note quoted above;
every nodeSelector: intent: apps in the workload manifests;
the absence of any NodePool or intent label in cluster/automode/;
cluster/terraform/main.tf and karpenter.tf at the lines cited;
every expireAfter in the *-automode.yaml files;
the overprovision README's sample output.

From the EKS user guide, read 5 October 2026:

Create a Node Pool for EKS Auto Mode: the default 336-hour expiry, the 10% budget, the weekly AMI drift, the consolidationPolicy values including Balanced, and the eks.amazonaws.com/instance-* labels.
Create a Node Class: the 110-pod limit and AmazonEKSAutoNodePolicy.
Built-in node pools: general-purpose is amd64 only, On-Demand only, C/M/R, generation 5+.
Kubernetes versions: 1.34's end of standard support.

Not run:

No cluster was created, and neither template was applied.
The claim that five blueprints stay Pending on the Auto Mode template is inferred from their nodeSelector and the built-in pool's documented properties.
The NodePool above was written to the documented Auto Mode schema, but was not applied to a cluster.
The claim that Auto Mode accepts Balanced comes from the user guide, not from the API server.

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Karpenter Blueprints on AWS, services only

warashiba

The Auto Mode template cannot run five of its own blueprints

Balanced consolidation: the repository and the user guide disagree

The self-managed template, read for what it actually does

Which to run, for an AWS-only stack

Verified, and not