Karpenter v1.14: What's New and How to Upgrade

TLDR;

Karpenter v1.14, released July 11, 2026, adds three features: Dynamic Resource Allocation (DRA) support for GPU and accelerator scheduling, an alpha CapacityBuffer API for reserving spare node capacity, and a new Balanced consolidation policy that weighs cost savings against pod disruption. Balanced consolidation is a stable field and safe to use in production; DRA support and CapacityBuffer are still early-stage and best tested in staging first.

Karpenter v1.14: What's New and How to Upgrade

Karpenter v1.14 is the latest release of the Kubernetes node autoscaler. It adds three main things: support for Dynamic Resource Allocation (DRA), a new CapacityBuffer API for spare capacity, and a new Balanced consolidation policy. Two of them are still early. DRA support is not GA in Karpenter yet, and CapacityBuffer is alpha and off by default.

Both Karpenter repos released v1.14.0 on 11 July 2026: the core project and the AWS provider.

This post explains what each one does, how to upgrade, and what is safe to use in production now.

There is a theme across this release. The Karpenter team knows that reliability and availability are top of mind when you tune autoscaling. Nobody wants to save cost at the price of a service outage. Both the new Balanced consolidation policy and CapacityBuffer are built with this in mind. One saves cost without moving nodes you can't afford to lose. The other keeps spare capacity ready so pods don't wait. This is the same reliability-first approach to cost that PerfectScale has taken from the start.

What's New in Karpenter v1.14?

Karpenter launches nodes when pods can't be scheduled, and removes nodes when they are no longer needed. v1.14 does not change that job. It makes Karpenter smarter about GPU and hardware workloads, gives you a way to keep spare nodes ready, and adds a gentler way to save cost.

Three changes stand out in this release:

a. DRA support: Karpenter now reads a pod's DRA request when it picks a node. This matters most for GPU and other hardware workloads.

b. CapacityBuffer: you can keep spare nodes ready so pods start right away. This one is alpha.

c. Balanced consolidation: a new policy that removes a node only when the cost saved is worth the disruption.

DRA support in Karpenter v1.14

DRA is a Kubernetes way to ask for special hardware like GPUs and other accelerators. Instead of asking for a fixed number like nvidia.com/gpu: 1, a pod describes the device it needs with a ResourceClaim, and the scheduler picks the actual device. Each node needs a DRA driver for your hardware. DRA is GA in Kubernetes since v1.34 and is on by default from that version.

Before v1.14, Karpenter did not read these DRA requests when it planned new nodes. So a pod that needed a GPU through DRA could get stuck, because Karpenter did not launch a node that could run it. To work around this, you had to send these pods to the right nodes yourself, with a nodeSelector or node affinity, the same way GPU pods are routed with the older device plugin model. Karpenter reads those, but it could not read the DRA claim on its own. v1.14 adds a DRA allocator. Karpenter now reads the pod's DRA request and uses it to pick the right node. It also handles shared and splittable devices, which helps when a few pods share one accelerator.

You do not need to turn this on. It is on by default. To make Karpenter ignore DRA requests, set the --ignore-dra-requests flag. But this is still early. If you run GPU or accelerator workloads with DRA, try it in staging first. You also need Kubernetes 1.34 or later and a DRA driver for your hardware. The Settings reference has the flag details.

Karpenter CapacityBuffer: Keep Spare Nodes Ready

New nodes take time to start and join the cluster. For workloads that spike or can't wait, that delay hurts. Pods stay pending, and your service can't scale up in time to serve the traffic. CapacityBuffer lets you keep some spare capacity ready, so pods schedule right away instead of waiting for a new node.

It works with virtual placeholder pods. These pods only live inside Karpenter's planning. They are never real pods in your cluster. They make Karpenter keep spare nodes ready, and they refill on their own when your real pods use the spare space.

You set the size of the spare capacity in one of two ways:

1. podTemplateRef: point at a PodTemplate that describes one buffer chunk, then set replicas and/or limits.
2. scalableRef: point at a Deployment, StatefulSet, or ReplicaSet, then set a percentage to keep the spare capacity in step with that workload.

Here is a fixed buffer of five chunks:

yaml

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: CapacityBuffer
metadata:
  name: web-app-buffer
  namespace: default
spec:
  provisioningStrategy: "buffer.x-k8s.io/active-capacity"
  podTemplateRef:
    name: web-buffer-template
  replicas: 5
  limits:
    cpu: "20"
    memory: "40Gi"

Or, to keep the spare capacity in step with a workload, point at a Deployment and set a percentage. This keeps buffer capacity at 20% of the api-service Deployment's replicas, so the spare capacity grows and shrinks as that Deployment scales:

yaml

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: CapacityBuffer
metadata:
  name: api-service-buffer
  namespace: default
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: api-service
  percentage: 20

When you set more than one of these, the final count is min(max(replicas, percentage), limits). So replicas and percentage are combined by taking the larger one, and limits caps the result.

There is one thing to know about node cleanup. Karpenter will not remove a node as empty if it holds buffer capacity. The virtual buffer pods stop it from counting as empty, and Karpenter marks it with the reason Node has buffer pods. Every other kind of cleanup still runs, and any replacement node must still fit the buffer pods, so the spare capacity stays topped up.

CapacityBuffer is alpha and off by default. You turn it on with the CapacityBuffer=true feature gate. It was added in v1.13, and v1.14 moved its internal API forward and added status metrics, but it is still alpha and the API can change. Try it in a test cluster first. Also remember that spare capacity costs money, because you pay for nodes that sit idle. Size it to the real burst you need.