Karpenter v1.14: novedades y cómo actualizar

TLDR;

Karpenter v1.14, lanzado el 11 de julio de 2026, incorpora tres funciones: soporte de Dynamic Resource Allocation (DRA) para la programación de GPUs y aceleradores, una API CapacityBuffer en alpha para reservar capacidad extra en los nodos y una nueva política de consolidación Balanced que pondera el ahorro de costos frente a la disrupción de los pods. La consolidación Balanced es un campo estable y seguro para usar en producción; el soporte de DRA y CapacityBuffer todavía están en etapa temprana y conviene probarlos primero en staging.

Karpenter v1.14: novedades y cómo actualizar

Karpenter v1.14 es la versión más reciente del autoescalador de nodos de Kubernetes. Incorpora tres novedades principales: soporte para Dynamic Resource Allocation (DRA), una nueva API CapacityBuffer para capacidad de reserva y una nueva política de consolidación Balanced. Dos de ellas todavía están en etapa temprana. El soporte de DRA aún no es GA en Karpenter, y CapacityBuffer está en alpha y desactivada por defecto.

Ambos repositorios de Karpenter publicaron la v1.14.0 el 11 de julio de 2026: el proyecto principal y el proveedor de AWS.

En este artículo te explicamos qué hace cada una, cómo actualizar y qué puedes usar en producción hoy.

Hay un hilo conductor en esta versión. El equipo de Karpenter sabe que la confiabilidad y la disponibilidad son la prioridad cuando ajustas el autoescalado. Nadie quiere ahorrar costos a cambio de una caída del servicio. Tanto la nueva política de consolidación Balanced como CapacityBuffer se diseñaron con esto en mente. Una ahorra costos sin mover nodos que no puedes darte el lujo de perder. La otra mantiene capacidad de reserva lista para que los pods no esperen. Es el mismo enfoque de costos —con la confiabilidad como prioridad— que PerfectScale ha aplicado desde el inicio.

¿Qué hay de nuevo en Karpenter v1.14?

Karpenter lanza nodos cuando los pods no se pueden programar y los elimina cuando ya no se necesitan. La v1.14 no cambia esa función. Hace que Karpenter sea más inteligente con los workloads de GPU y hardware, te da una forma de mantener nodos de reserva listos y agrega una manera menos agresiva de ahorrar costos.

Tres cambios destacan en esta versión:

a. Soporte de DRA: Karpenter ahora lee la solicitud DRA de un pod cuando elige un nodo. Esto importa sobre todo para workloads de GPU y otro hardware.

b. CapacityBuffer: puedes mantener nodos de reserva listos para que los pods arranquen de inmediato. Esta función está en alpha.

c. Consolidación Balanced: una nueva política que elimina un nodo solo cuando el costo ahorrado justifica la disrupción.

Soporte de DRA en Karpenter v1.14

DRA es el mecanismo de Kubernetes para solicitar hardware especializado, como GPUs y otros aceleradores. En lugar de pedir un número fijo como nvidia.com/gpu: 1, el pod describe el dispositivo que necesita con un ResourceClaim y el scheduler elige el dispositivo concreto. Cada nodo necesita un driver de DRA para tu hardware. DRA es GA en Kubernetes desde la v1.34 y viene activado por defecto a partir de esa versión.

Antes de la v1.14, Karpenter no leía estas solicitudes DRA al planificar nodos nuevos. Así, un pod que necesitaba una GPU vía DRA podía quedarse atascado, porque Karpenter no lanzaba un nodo capaz de ejecutarlo. Para sortearlo, tenías que dirigir esos pods a los nodos correctos por tu cuenta, con un nodeSelector o node affinity, igual que se enrutan los pods de GPU con el modelo antiguo de device plugin. Karpenter sí lee esos valores, pero no podía leer el claim de DRA por sí solo. La v1.14 agrega un asignador de DRA. Karpenter ahora lee la solicitud DRA del pod y la usa para elegir el nodo correcto. También maneja dispositivos compartidos y divisibles, lo que ayuda cuando varios pods comparten un acelerador.

No necesitas activarlo: viene activado por defecto. Para que Karpenter ignore las solicitudes DRA, configura el flag --ignore-dra-requests. Pero esto todavía está en etapa temprana. Si ejecutas workloads de GPU o aceleradores con DRA, pruébalo primero en staging. También necesitas Kubernetes 1.34 o posterior y un driver de DRA para tu hardware. En la referencia de configuración tienes los detalles del flag.

CapacityBuffer de Karpenter: mantén nodos de reserva listos

Los nodos nuevos tardan en arrancar y unirse al clúster. Para workloads con picos o que no pueden esperar, esa demora sale cara. Los pods quedan pendientes y tu servicio no logra escalar a tiempo para atender el tráfico. CapacityBuffer te permite mantener algo de capacidad de reserva lista, para que los pods se programen de inmediato en lugar de esperar un nodo nuevo.

Funciona con pods virtuales que actúan como marcadores de posición. Estos pods solo existen dentro de la planificación de Karpenter. Nunca son pods reales en tu clúster. Hacen que Karpenter mantenga nodos de reserva listos y se reponen solos cuando tus pods reales ocupan el espacio de reserva.

Defines el tamaño de la capacidad de reserva de una de dos formas:

1. podTemplateRef: apunta a un PodTemplate que describe una unidad del buffer y luego define replicas y/o limits.
2. scalableRef: apunta a un Deployment, StatefulSet o ReplicaSet y luego define un porcentaje para que la capacidad de reserva acompañe a ese workload.

Aquí tienes un buffer fijo de cinco unidades:

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"

O, para que la capacidad de reserva acompañe a un workload, apunta a un Deployment y define un porcentaje. Esto mantiene la capacidad del buffer en el 20% de las réplicas del Deployment api-service, así la capacidad de reserva crece y se reduce a medida que ese Deployment escala:

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

Cuando defines más de uno de estos valores, la cantidad final es min(max(replicas, percentage), limits). Es decir, replicas y percentage se combinan tomando el mayor, y limits pone un tope al resultado.

Hay algo que debes saber sobre la limpieza de nodos. Karpenter no eliminará un nodo por considerarlo vacío si aloja capacidad del buffer. Los pods virtuales del buffer impiden que cuente como vacío y Karpenter lo marca con el motivo Node has buffer pods. El resto de los tipos de limpieza sigue funcionando, y cualquier nodo de reemplazo debe seguir teniendo espacio para los pods del buffer, así que la capacidad de reserva siempre se mantiene completa.

CapacityBuffer está en alpha y desactivado por defecto. Se activa con el feature gate CapacityBuffer=true. Se agregó en la v1.13, y la v1.14 avanzó su API interna y sumó métricas de estado, pero sigue en alpha y la API puede cambiar. Pruébalo primero en un clúster de pruebas. Recuerda también que la capacidad de reserva cuesta dinero, porque pagas por nodos que están ociosos. Dimensiónala según el pico real que necesitas.