Karpenter

What is karpenter image?

The karpenter image runs Karpenter, a cloud-native node autoscaler designed to dynamically provision Kubernetes worker nodes in response to pending pods. Unlike the traditional Cluster Autoscaler, Karpenter reacts directly to pod scheduling requirements such as CPU, memory, architecture, instance type, availability zone, and pricing constraints. It integrates deeply with cloud provider APIs (most commonly AWS EC2) to launch the most appropriate instances on demand, enabling faster scale-up and more efficient bin-packing of workloads. In modern Kubernetes environments, Karpenter is used to reduce infrastructure costs, improve scheduling latency, and simplify node group management by replacing static node pools with flexible, intent-driven provisioning.

How to use this image

The karpenter image is deployed as a Kubernetes controller and is not run directly with docker run. It requires cloud-provider permissions and custom resources to define provisioning behavior.

Install Karpenter using Helm (AWS EKS example):

helm repo add karpenter https://charts.karpenter.sh
helm install karpenter karpenter/karpenter \
  --namespace karpenter --create-namespace \
  --set settings.clusterName=my-cluster \
  --set settings.interruptionQueueName=my-queue

Define a NodePool and NodeClass to control provisioning:

apiVersion:karpenter.sh/v1beta1
kind:NodePool
metadata:
name:default
spec:
template:
spec:
requirements:
-key:kubernetes.io/arch
operator:In
values: ["amd64"]
-key:karpenter.sh/capacity-type
operator:In
values: ["on-demand"]
nodeClassRef:
name:default

Karpenter monitors unschedulable pods and provisions nodes automatically, then scales them down when capacity is no longer needed. Logs are written to stdout and collected via Kubernetes logging systems.

Image variants

Published under public.ecr.aws/karpenter/karpenter, the image is available as:

• karpenter:latest – Tracks the most recent stable controller build; suitable for testing.
• karpenter:<version> – Version-pinned tags (for example, 0.37.0, 0.36.2); recommended for production to ensure compatibility with Kubernetes and cloud APIs.
• Multi-architecture builds – Images are commonly published as multi-arch (amd64/arm64) to support heterogeneous clusters.

Karpenter releases are tightly coupled to Kubernetes and cloud provider API changes; production environments should pin versions and follow upgrade guides carefully.