Karpenter v1.14 : les nouveautés et comment mettre à niveau

TLDR;

Karpenter v1.14, publié le 11 juillet 2026, ajoute trois fonctionnalités : le support de la Dynamic Resource Allocation (DRA) pour le scheduling des GPU et accélérateurs, une API CapacityBuffer en alpha pour réserver de la capacité de nœud disponible, et une nouvelle politique de consolidation Balanced qui met en balance les économies réalisées et la perturbation des pods. La consolidation Balanced est un champ stable et peut être utilisée en production sans risque ; le support DRA et CapacityBuffer n'en sont encore qu'à leurs débuts et méritent d'être testés d'abord en staging.

Karpenter v1.14 : les nouveautés et comment mettre à niveau

Karpenter v1.14 est la dernière version de l'autoscaler de nœuds Kubernetes. Elle apporte trois nouveautés principales : le support de la Dynamic Resource Allocation (DRA), une nouvelle API CapacityBuffer pour la capacité de réserve, et une nouvelle politique de consolidation Balanced. Deux d'entre elles n'en sont qu'à leurs débuts. Le support DRA n'est pas encore en GA dans Karpenter, et CapacityBuffer est en alpha et désactivée par défaut.

Les deux dépôts Karpenter ont publié la v1.14.0 le 11 juillet 2026 : le projet core et le provider AWS.

Cet article explique ce que fait chaque fonctionnalité, comment effectuer la mise à niveau et ce que vous pouvez utiliser en production dès aujourd'hui.

Un fil rouge traverse cette version. L'équipe Karpenter sait que la fiabilité et la disponibilité sont des priorités lorsque vous ajustez l'autoscaling. Personne ne veut réduire ses coûts au prix d'une interruption de service. La nouvelle politique de consolidation Balanced comme CapacityBuffer ont été conçues dans cet esprit. L'une réduit les coûts sans déplacer les nœuds que vous ne pouvez pas vous permettre de perdre. L'autre maintient de la capacité de réserve prête à l'emploi pour que les pods n'attendent pas. C'est exactement cette approche des coûts, où la fiabilité prime, que PerfectScale adopte depuis le premier jour.

Les nouveautés de Karpenter v1.14

Karpenter lance des nœuds lorsque des pods ne peuvent pas être schedulés, et supprime les nœuds devenus inutiles. La v1.14 ne change rien à cette mission. Elle rend Karpenter plus intelligent pour les workloads GPU et matériels, vous permet de garder des nœuds de réserve prêts, et ajoute une manière plus mesurée de réduire les coûts.

Trois changements se démarquent dans cette version :

a. Support DRA : Karpenter lit désormais la demande DRA d'un pod lorsqu'il choisit un nœud. C'est surtout important pour les workloads GPU et les autres workloads matériels.

b. CapacityBuffer : vous pouvez garder des nœuds de réserve prêts pour que les pods démarrent immédiatement. Cette fonctionnalité est en alpha.

c. Consolidation Balanced : une nouvelle politique qui ne supprime un nœud que lorsque l'économie réalisée vaut la perturbation.

Le support DRA dans Karpenter v1.14

DRA est un mécanisme Kubernetes pour demander du matériel spécialisé comme des GPU et d'autres accélérateurs. Au lieu de demander un nombre fixe comme nvidia.com/gpu: 1, un pod décrit le périphérique dont il a besoin avec un ResourceClaim, et le scheduler choisit le périphérique réel. Chaque nœud a besoin d'un driver DRA pour votre matériel. DRA est en GA dans Kubernetes depuis la v1.34 et est activé par défaut à partir de cette version.

Avant la v1.14, Karpenter ne lisait pas ces demandes DRA lorsqu'il planifiait de nouveaux nœuds. Un pod qui avait besoin d'un GPU via DRA pouvait donc rester bloqué, car Karpenter ne lançait pas de nœud capable de l'exécuter. Pour contourner ce problème, vous deviez router ces pods vous-même vers les bons nœuds, avec un nodeSelector ou une node affinity, de la même façon que les pods GPU sont routés avec l'ancien modèle de device plugin. Karpenter lit ces informations, mais il ne pouvait pas lire le claim DRA de lui-même. La v1.14 ajoute un allocateur DRA. Karpenter lit désormais la demande DRA du pod et s'en sert pour choisir le bon nœud. Il gère aussi les périphériques partagés et divisibles, ce qui est utile lorsque plusieurs pods se partagent un accélérateur.

Vous n'avez rien à activer. La fonctionnalité est activée par défaut. Pour que Karpenter ignore les demandes DRA, utilisez le flag --ignore-dra-requests. Mais tout cela reste récent. Si vous exécutez des workloads GPU ou accélérateurs avec DRA, testez d'abord en staging. Vous avez également besoin de Kubernetes 1.34 ou ultérieur et d'un driver DRA pour votre matériel. La référence des paramètres détaille ce flag.

Karpenter CapacityBuffer : gardez des nœuds de réserve prêts

Les nouveaux nœuds mettent du temps à démarrer et à rejoindre le cluster. Pour les workloads soumis à des pics ou qui ne peuvent pas attendre, ce délai est pénalisant. Les pods restent en attente, et votre service ne peut pas monter en charge à temps pour absorber le trafic. CapacityBuffer vous permet de garder de la capacité de réserve prête, pour que les pods soient schedulés immédiatement au lieu d'attendre un nouveau nœud.

Le mécanisme repose sur des pods virtuels de substitution. Ces pods n'existent que dans la planification de Karpenter. Ce ne sont jamais de vrais pods dans votre cluster. Ils obligent Karpenter à garder des nœuds de réserve prêts, et ils se reconstituent d'eux-mêmes lorsque vos vrais pods utilisent l'espace de réserve.

Vous définissez la taille de la capacité de réserve de deux façons :

1. podTemplateRef : pointez vers un PodTemplate qui décrit une unité de buffer, puis définissez replicas et/ou limits.
2. scalableRef : pointez vers un Deployment, StatefulSet ou ReplicaSet, puis définissez un pourcentage pour que la capacité de réserve suive ce workload.

Voici un buffer fixe de cinq unités :

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"

Ou, pour que la capacité de réserve suive un workload, pointez vers un Deployment et définissez un pourcentage. Cette configuration maintient la capacité du buffer à 20 % des replicas du Deployment api-service, de sorte que la capacité de réserve augmente et diminue au rythme de ce 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

Lorsque vous définissez plusieurs de ces valeurs, la valeur finale est min(max(replicas, percentage), limits). Replicas et percentage sont donc combinés en retenant la plus grande valeur, et limits plafonne le résultat.

Il y a une chose à savoir sur le nettoyage des nœuds. Karpenter ne supprimera pas un nœud en tant que nœud vide s'il héberge de la capacité de buffer. Les pods de buffer virtuels l'empêchent de compter comme vide, et Karpenter le marque avec la raison Node has buffer pods. Tous les autres types de nettoyage continuent de s'exécuter, et tout nœud de remplacement doit toujours pouvoir accueillir les pods de buffer, de sorte que la capacité de réserve reste au niveau requis.

CapacityBuffer est en alpha et désactivée par défaut. Vous l'activez avec la feature gate CapacityBuffer=true. Elle a été introduite en v1.13, et la v1.14 a fait évoluer son API interne et ajouté des métriques de statut, mais elle reste en alpha et l'API peut changer. Essayez-la d'abord sur un cluster de test. N'oubliez pas non plus que la capacité de réserve a un coût, car vous payez des nœuds inactifs. Dimensionnez-la selon le pic réel dont vous avez besoin.