Learn Karpenter - Pre-Requisite Skills & Environment Setup

#Introduction

Welcome to the Learn Karpenter series. This series is designed for Platform Engineers, DevOps Engineers, SREs, and Kubernetes Administrators who want to build fast, efficient, and cost-effective node autoscaling for Kubernetes clusters on AWS. Throughout the series we will cover architecture, NodePool and NodeClass, consolidation, drift detection, all the way to production deployment.

Episode 0 is the gateway. Before you can run Karpenter, two things must be prepared: the skills that serve as prerequisites and the environment where Karpenter runs. If either one is missing, the hands-on episodes that follow will feel heavy. That's why this episode does not go deep into Karpenter yet — its focus is on making sure your foundation is solid first.

#Basic Skills You Must Have

Karpenter is a scheduling-aware controller that interacts directly with the Kubernetes API and AWS. There are three groups of skills you must possess.

#Kubernetes: Pods, Nodes, and Scheduling

Understand the pod lifecycle — from Pending, Running, to Completed — especially the Unschedulable condition, which is the main trigger for Karpenter. You should also be familiar with taints and tolerations as well as nodeSelector. Without these three, it's hard to understand how Karpenter decides what kind of node to create.

#AWS: EKS, EC2, and IAM

Karpenter calls the AWS API directly to launch instances. You need to understand: EKS as the control plane, EC2 instance types and AMIs, security groups, subnets inside a VPC, and IAM roles. All of these concepts will keep showing up — especially in episode 5 when we discuss EC2NodeClass.

#kubectl and Helm

Karpenter is installed via a Helm chart and managed with kubectl. You also need to understand how a pod is rejected by the scheduler when no matching node exists — for example, through the output of kubectl describe pod. This habit of reading events and statuses will help you a lot when debugging Karpenter.

#Software Tools to Prepare

Here's the list of tools that must be installed on your local machine.

Verify each one with the following commands:

eksctl version
aws --version
kubectl version --client
helm version
docker version

Make sure your AWS credentials are configured and have permission to create EKS, EC2, and IAM resources. Run aws sts get-caller-identity to confirm your session is valid before continuing.

#Creating an EKS Cluster

Karpenter 1.14.0 supports Kubernetes 1.29 to 1.36. Create an EKS cluster with one small vended nodegroup — this nodegroup will only run system components, while workloads will later be handled by Karpenter.

eksctl create cluster \
  --name learn-karpenter \
  --version 1.32 \
  --region ap-southeast-1 \
  --nodegroup-name system \
  --node-type m5.large \
  --nodes 1 \
  --managed

This process usually takes 10-15 minutes. Once finished, the kubeconfig is updated automatically. Verify with kubectl cluster-info and kubectl get nodes until all nodes report Ready.

#Creating the IAM Role for Karpenter

Karpenter needs permissions to launch instances, create security groups, and manage EC2 resources. The best practice is to use IRSA (IAM Roles for Service Accounts) with a minimal policy — instead of storing AWS access keys inside the cluster.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateFleet",
        "ec2:TerminateInstances",
        "ec2:DescribeInstances",
        "ec2:DescribeSubnets"
      ],
      "Resource": "*"
    }
  ]
}

Once the policy is created, attach it to the Karpenter service account with eksctl:

eksctl create iamserviceaccount \
  --cluster learn-karpenter \
  --namespace karpenter \
  --name karpenter \
  --role-name karpenter-irsa \
  --attach-policy-arn arn:aws:iam::ACCOUNT_ID:policy/KarpenterControllerPolicy \
  --approve

Replace ACCOUNT_ID with your AWS account number. Terraform or CloudFormation can also be used to create this role — the key principle remains the same: least privilege.

#Installing Karpenter 1.14.0

Karpenter is installed via the karpenter Helm chart distributed from the OCI registry at ghcr.io. This chart also installs the NodePool and EC2NodeClass CRDs.

helm upgrade --install karpenter oci://ghcr.io/aws/karpenter/charts/karpenter \
  --namespace karpenter \
  --create-namespace \
  --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=arn:aws:iam::ACCOUNT_ID:role/karpenter-irsa \
  --version 1.14.0

#Verifying the Installation

Make sure the controller is running and its version is correct:

kubectl get pods -n karpenter
kubectl logs -n karpenter deployment/karpenter --tail=20

If healthy, you'll see the controller pod in Running status. Also confirm the CRDs are registered:

kubectl get crd nodepools.karpenter.sh
kubectl get crd ec2nodeclasses.karpenter.k8s.aws

Finally, prepare a test workload for use in the upcoming episodes:

kubectl create deployment nginx --image=nginx
kubectl rollout status deployment/nginx

#Closing

Episode 0 equips you with the skill and environment foundation. You've checked your local tools, created an EKS cluster with eksctl, built an IAM role on the least-privilege principle, installed Karpenter 1.14.0 via Helm, and verified that the controller and CRDs are running correctly.

Key takeaways:

• Prerequisite skills — Kubernetes scheduling, taints/tolerations, and AWS fundamentals are absolute requirements for understanding Karpenter.
• EKS environment — a 1.29-1.36 cluster with one system nodegroup is ready as a playground for Karpenter.
• IAM role — IRSA with a minimal policy is safer than static access keys inside the cluster.
• Helm installation — the karpenter chart version 1.14.0 is installed along with the NodePool and EC2NodeClass CRDs.
• Verification — a healthy kubectl get pods -n karpenter means the controller is ready to work.

In episode 1 we'll step back for a moment and answer the big question: why Karpenter exists. We'll trace the history of node autoscaling, compare Cluster Autoscaler with Karpenter, and look at the latency, cost, and complexity problems it aims to solve. See you in the next episode!