Karpenter v1.14: Das ist neu – und so gelingt das Upgrade

TLDR;

Karpenter v1.14, veröffentlicht am 11. Juli 2026, bringt drei Features: Dynamic-Resource-Allocation-Support (DRA) für GPU- und Accelerator-Scheduling, eine Alpha-CapacityBuffer-API zum Vorhalten freier Node-Kapazität und eine neue Balanced-Consolidation-Policy, die Kosteneinsparungen gegen Pod-Disruption abwägt. Balanced Consolidation ist ein stabiles Feld und produktionsreif; DRA-Support und CapacityBuffer befinden sich noch in einem frühen Stadium und sollten zunächst in Staging getestet werden.

Karpenter v1.14: Was ist neu und wie gelingt das Upgrade

Karpenter v1.14 ist das neueste Release des Kubernetes-Node-Autoscalers. Es bringt drei zentrale Neuerungen: Support für Dynamic Resource Allocation (DRA), eine neue CapacityBuffer-API für Reservekapazität und eine neue Balanced-Consolidation-Policy. Zwei davon sind noch in einem frühen Stadium: Der DRA-Support ist in Karpenter noch nicht GA, und CapacityBuffer ist Alpha und standardmäßig deaktiviert.

Beide Karpenter-Repos haben v1.14.0 am 11. Juli 2026 veröffentlicht: das Core-Projekt und der AWS-Provider.

Dieser Beitrag erklärt, was die einzelnen Features leisten, wie Sie upgraden und was Sie heute bedenkenlos in Produktion einsetzen können.

Ein roter Faden zieht sich durch dieses Release: Das Karpenter-Team weiß, dass Zuverlässigkeit und Verfügbarkeit an erster Stelle stehen, wenn Sie Autoscaling feinjustieren. Niemand will Kosten sparen und dafür einen Serviceausfall riskieren. Sowohl die neue Balanced-Consolidation-Policy als auch CapacityBuffer sind mit genau diesem Gedanken entwickelt. Die Policy spart Kosten, ohne Nodes zu verschieben, auf die Sie nicht verzichten können. Der Buffer hält Reservekapazität bereit, damit Pods nicht warten müssen. Genau diesen Reliability-first-Ansatz bei den Kosten verfolgt PerfectScale von Anfang an.

Was ist neu in Karpenter v1.14?

Karpenter startet Nodes, wenn Pods nicht eingeplant werden können, und entfernt Nodes, sobald sie nicht mehr gebraucht werden. Daran ändert v1.14 nichts. Das Release macht Karpenter schlauer im Umgang mit GPU- und Hardware-Workloads, gibt Ihnen eine Möglichkeit, Reserve-Nodes bereitzuhalten, und bringt einen schonenderen Weg, Kosten zu sparen.

Drei Änderungen stechen in diesem Release hervor:

a. DRA-Support: Karpenter berücksichtigt jetzt die DRA-Anforderung eines Pods bei der Node-Auswahl. Das ist vor allem für GPU- und andere Hardware-Workloads relevant.

b. CapacityBuffer: Sie können Reserve-Nodes bereithalten, damit Pods sofort starten. Dieses Feature ist Alpha.

c. Balanced Consolidation: eine neue Policy, die einen Node nur dann entfernt, wenn die Kostenersparnis die Disruption rechtfertigt.

DRA-Support in Karpenter v1.14

DRA ist der Kubernetes-Mechanismus, um spezielle Hardware wie GPUs und andere Acceleratoren anzufordern. Statt eine feste Anzahl wie nvidia.com/gpu: 1 anzufragen, beschreibt ein Pod das benötigte Gerät mit einem ResourceClaim, und der Scheduler wählt das konkrete Gerät aus. Jeder Node benötigt einen DRA-Treiber für Ihre Hardware. DRA ist seit Kubernetes v1.34 GA und ab dieser Version standardmäßig aktiviert.

Vor v1.14 hat Karpenter diese DRA-Anforderungen bei der Planung neuer Nodes nicht berücksichtigt. Ein Pod, der eine GPU über DRA benötigte, konnte deshalb hängen bleiben, weil Karpenter keinen Node startete, auf dem er laufen konnte. Als Workaround mussten Sie diese Pods selbst per nodeSelector oder Node-Affinity auf die richtigen Nodes lenken – so, wie GPU-Pods im älteren Device-Plugin-Modell geroutet werden. Diese Angaben liest Karpenter zwar, den DRA-Claim konnte es aber nicht eigenständig auswerten. v1.14 ergänzt einen DRA-Allocator. Karpenter liest jetzt die DRA-Anforderung des Pods und nutzt sie, um den passenden Node auszuwählen. Auch geteilte und aufteilbare Geräte werden unterstützt, was hilft, wenn sich mehrere Pods einen Accelerator teilen.

Sie müssen nichts aktivieren – das Feature ist standardmäßig eingeschaltet. Damit Karpenter DRA-Anforderungen ignoriert, setzen Sie das Flag --ignore-dra-requests. Das Feature ist allerdings noch jung. Wenn Sie GPU- oder Accelerator-Workloads mit DRA betreiben, testen Sie es zuerst in Staging. Außerdem benötigen Sie Kubernetes 1.34 oder neuer sowie einen DRA-Treiber für Ihre Hardware. Die Details zum Flag finden Sie in der Settings-Referenz.

Karpenter CapacityBuffer: Reserve-Nodes bereithalten

Neue Nodes brauchen Zeit, um zu starten und dem Cluster beizutreten. Für Workloads mit Lastspitzen oder ohne Toleranz für Wartezeiten ist diese Verzögerung ein echtes Problem. Pods bleiben pending, und Ihr Service kann nicht rechtzeitig hochskalieren, um den Traffic zu bedienen. Mit CapacityBuffer halten Sie Reservekapazität bereit, sodass Pods sofort eingeplant werden, statt auf einen neuen Node zu warten.

Das funktioniert über virtuelle Platzhalter-Pods. Diese Pods existieren nur in Karpenters Planung – sie werden nie zu echten Pods in Ihrem Cluster. Sie sorgen dafür, dass Karpenter Reserve-Nodes bereithält, und füllen sich automatisch wieder auf, wenn Ihre echten Pods die freie Kapazität nutzen.

Die Größe der Reservekapazität legen Sie auf einem von zwei Wegen fest:

1. podTemplateRef: Verweisen Sie auf ein PodTemplate, das einen Buffer-Baustein beschreibt, und setzen Sie dann replicas und/oder limits.
2. scalableRef: Verweisen Sie auf ein Deployment, StatefulSet oder ReplicaSet und setzen Sie einen Prozentsatz, damit die Reservekapazität mit diesem Workload Schritt hält.

So sieht ein fester Buffer mit fünf Bausteinen aus:

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"

Oder Sie koppeln die Reservekapazität an einen Workload: Verweisen Sie auf ein Deployment und setzen Sie einen Prozentsatz. So bleibt die Buffer-Kapazität bei 20 % der Replicas des api-service-Deployments – die Reservekapazität wächst und schrumpft also mit diesem Deployment:

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

Wenn Sie mehrere dieser Werte setzen, ergibt sich die finale Anzahl aus min(max(replicas, percentage), limits). Replicas und Prozentsatz werden also kombiniert, indem der größere Wert genommen wird, und limits deckelt das Ergebnis.

Einen Punkt zur Node-Bereinigung sollten Sie kennen: Karpenter stuft einen Node nicht als leer ein und entfernt ihn nicht, solange er Buffer-Kapazität hält. Die virtuellen Buffer-Pods verhindern, dass er als leer zählt, und Karpenter markiert ihn mit dem Grund Node has buffer pods. Alle anderen Bereinigungsarten laufen weiter, und jeder Ersatz-Node muss die Buffer-Pods weiterhin aufnehmen können, sodass die Reservekapazität erhalten bleibt.

CapacityBuffer ist Alpha und standardmäßig deaktiviert. Sie aktivieren es mit dem Feature-Gate CapacityBuffer=true. Eingeführt wurde es in v1.13; v1.14 hat die interne API weiterentwickelt und Status-Metriken ergänzt, aber es bleibt Alpha, und die API kann sich noch ändern. Probieren Sie es zuerst in einem Test-Cluster aus. Bedenken Sie außerdem: Reservekapazität kostet Geld, denn Sie zahlen für Nodes, die ungenutzt laufen. Dimensionieren Sie sie auf den Burst, den Sie tatsächlich brauchen.