Karpenter: node provisioning that starts from the pod, not the node group

Four steps, and the first one is watching for a scheduling failure

The README describes Karpenter in four bullets, and the order matters. It watches for pods that the Kubernetes scheduler has marked unschedulable. It evaluates the scheduling constraints those pods request, naming resource requests, node selectors, affinities, tolerations and topology spread constraints. It provisions nodes that meet the requirements. And it removes nodes when they are no longer needed.

That is the whole design, and it is the reason Karpenter behaves differently from the cluster autoscaler. Nothing is pre-declared: there is no node group with instance types listed in advance, so the shape of the capacity follows from the workload. A pod asking for four cores and a specific topology produces a node that satisfies exactly that, and a node with nothing pending on it is a candidate for removal.

The removal half is the part people underestimate. Consolidation is not just about empty nodes, since version 1.14 extended the consolidate-after window to destination nodes as well, meaning a node can be consolidated when it holds pods that could be moved elsewhere rather than only when it is empty.

The cloud-specific work is a directory of other repositories

This repository is the vendor-neutral core, and the README makes that explicit by listing implementations maintained elsewhere. AWS, Azure, Alibaba Cloud, Bizfly Cloud, Clever Cloud, Cluster API, Exoscale, GCP, Hetzner, Huawei Cloud, IBM Cloud and Proxmox each have their own repository. Oracle Cloud Infrastructure lists two, one officially maintained by Oracle and one maintained by Zoom.

The maturity labels in that list are worth reading closely, because they are the only signal the project gives about support levels. Akamai and Linode are marked Alpha, as is the UpCloud provider maintained by kubekanvas, while a second community UpCloud provider is marked Beta. Everything else carries no label at all, which means the list tells you what is experimental and leaves the rest to inference.

So the answer to whether Karpenter is tied to one cloud is no, and the answer to what Karpenter will do on your cloud is written in a repository you have not visited yet. The AWS provider is where the documentation, the NodePool examples and the bulk of the configuration surface live, and AWS is also the cloud the README's own badges still point at.

Version 1.14 is mostly about dynamic resource allocation

The 1.14.0 release, published 2026-07-11, is a feature release and its feature list is concentrated in one area. It includes a DRA allocator implementation, consumable capacity and partitionable device support, support for the CapacityBuffer API, an offering override, a zone label added to node and node claim lifecycle metrics, and the consolidation change described above.

Dynamic Resource Allocation is Kubernetes' mechanism for handing devices such as GPUs and other specialised hardware to pods through a scheduler plugin rather than through device plugins. Adding allocator support to the autoscaler is a substantial piece of work, and it is the kind of change that reads as internal until you try to schedule a pod that depends on a device claim.

The patch release v1.14.1 came on 2026-08-21 and contains a single cherry-pick, which is a normal patch. More interesting is the release list itself: v1.11.2 was published on 2026-07-08, three days before 1.14.0, and fixes a negative pod grace period in node repair termination. A maintained older line getting a fix after a newer feature release means 1.11 is still supported, and it tells you the project's fix policy spans more than the newest minor.

The badges still point at an older repository path

Every badge at the top of this README, and most of the links below it, reference `aws/karpenter-core`. The build status badge, the Go Report Card badge, the coverage badge, the license badge, the good first issue search and the help wanted search all resolve against that path. The issue triage section is the exception, and it lists meetings for both this repository and the AWS provider.

The module path tells the current story:

module sigs.k8s.io/karpenter

go 1.26.6

This is a leftover from the project's history rather than a functional problem, since GitHub redirects the old path, but it has practical consequences. A build status badge reading from the old path may reflect workflows that no longer exist, the coverage badge points at a repository whose coverage history is split across two identities, and anyone looking for issue labels from the README lands in the old tracker. The `CONTRIBUTING.md` link is relative, which is the one link in the file that cannot go stale.

Mixed Kubernetes library versions in a single module

The dependency list tells you the project's position on Kubernetes versions better than any badge does. `k8s.io/api`, `apimachinery`, `client-go` and `component-base` are all at 0.36.1, and the module targets Go 1.26.6. But a handful of dependencies sit one minor behind at 0.35.0, including `k8s.io/cloud-provider`, `k8s.io/component-helpers`, `k8s.io/csi-translation-lib` and, notably, `k8s.io/dynamic-resource-allocation`.

That last one matters given what 1.14.0 shipped. The release added a DRA allocator, and the library implementing the API is pinned a minor version behind the core Kubernetes libraries in the same module. This is not necessarily a bug, since these libraries version independently and pinning an alpha API deliberately is a reasonable choice, but it does mean DRA support here is coupled to an earlier API surface than the rest of the module.

Elsewhere the list shows the testing stack plainly: Ginkgo and Gomega for specs, `samber/lo` for generic helpers, `robfig/cron` for scheduling, and `k8s.io/autoscaler/vertical-pod-autoscaler` pulled in directly.

Tests run against simulated nodes, not cloud instances

The repository carries its own test infrastructure rather than relying on a real cloud account. There is a `kwok/` directory, a separate `dra-kwok-driver/`, and a Makefile that installs KWOK as a provider before running anything. KWOK is a toolkit for running a control plane against simulated Kubernetes nodes, which is how a project supporting a dozen clouds can run a shared test suite at all.

The Makefile also shows the shape of a development deployment, including which feature gates the project expects to be exercised:

export KARPENTER_NAMESPACE=kube-system
export KIND_CLUSTER_NAME ?= test-cluster

Its helm options enable `nodeRepair`, `capacityBuffer` and `staticCapacity`, which is a reasonable summary of what the core has been building out. Images are built with ko rather than a Dockerfile, and the presubmit target runs verification, tests, licence checks and a vulnerability scan as one gate.

Two files in the tree are unusual enough to be worth opening. `SCOPE.md` and `FEATURE_LIFECYCLE.md` suggest the project is deliberate about what belongs in core and about how features graduate, which is the sort of document that saves an integrator an hour of guessing.

Editorial conclusion

Karpenter's core is smaller than its reputation suggests, because the interesting part of the system lives in the provider you did not read. The README in this repository describes the scheduling loop and nothing else, which makes it a good place to understand the model and a poor place to configure anything. Version 1.14 shows the project shifting towards dynamic resource allocation and capacity buffering, and the mixed Kubernetes library versions in go.mod suggest that surface is still settling. Start with your cloud provider's repository and its NodePool examples rather than this one, and read the provider's own feature gate documentation before assuming a core release note applies to you.

Frequently asked questions

Official sources

1. Issues
2. kubernetes-sigs/karpenter on GitHub
3. License: Apache-2.0
4. README
5. Releases