Karpenter v1.14: o que mudou e como fazer o upgrade

TLDR;

O Karpenter v1.14, lançado em 11/07/2026, adiciona três recursos: suporte a Dynamic Resource Allocation (DRA) para agendamento de GPUs e aceleradores, a API CapacityBuffer em alpha para reservar capacidade extra de nós e uma nova política de consolidação Balanced, que coloca na balança a economia de custos e a interrupção dos pods. A consolidação Balanced é um campo estável e pode ser usada em produção com segurança; o suporte a DRA e o CapacityBuffer ainda estão em estágio inicial e é melhor testá-los primeiro em staging.

Karpenter v1.14: o que mudou e como fazer o upgrade

O Karpenter v1.14 é a versão mais recente do autoscaler de nós do Kubernetes. Ele adiciona três coisas principais: suporte a Dynamic Resource Allocation (DRA), uma nova API CapacityBuffer para capacidade extra e uma nova política de consolidação Balanced. Duas delas ainda estão em estágio inicial. O suporte a DRA ainda não é GA no Karpenter, e o CapacityBuffer está em alpha e vem desativado por padrão.

Os dois repositórios do Karpenter lançaram a v1.14.0 em 11 de julho de 2026: o projeto core e o provider da AWS.

Este post explica o que cada recurso faz, como fazer o upgrade e o que já é seguro usar em produção.

Há um tema comum nesta versão. O time do Karpenter sabe que confiabilidade e disponibilidade são prioridade quando você ajusta o autoscaling. Ninguém quer economizar ao custo de uma indisponibilidade do serviço. Tanto a nova política de consolidação Balanced quanto o CapacityBuffer foram criados com isso em mente. Um economiza sem mexer em nós que você não pode se dar ao luxo de perder. O outro mantém capacidade extra pronta para que os pods não fiquem esperando. É a mesma abordagem de custo com confiabilidade em primeiro lugar que o PerfectScale adota desde o início.

O que há de novo no Karpenter v1.14?

O Karpenter cria nós quando os pods não conseguem ser agendados e remove nós quando eles não são mais necessários. A v1.14 não muda esse trabalho. Ela torna o Karpenter mais inteligente com workloads de GPU e hardware, oferece uma forma de manter nós extras prontos e adiciona um jeito mais suave de economizar.

Três mudanças se destacam nesta versão:

a. Suporte a DRA: o Karpenter agora lê a solicitação DRA de um pod ao escolher um nó. Isso importa principalmente para workloads com GPU e outros hardwares.

b. CapacityBuffer: você pode manter nós extras prontos para que os pods iniciem imediatamente. Este recurso está em alpha.

c. Consolidação Balanced: uma nova política que só remove um nó quando o custo economizado compensa a interrupção.

Suporte a DRA no Karpenter v1.14

O DRA é a forma do Kubernetes de solicitar hardware especial, como GPUs e outros aceleradores. Em vez de pedir um número fixo como nvidia.com/gpu: 1, o pod descreve o dispositivo de que precisa com um ResourceClaim, e o scheduler escolhe o dispositivo em si. Cada nó precisa de um driver DRA para o seu hardware. O DRA é GA no Kubernetes desde a v1.34 e vem ativado por padrão a partir dessa versão.

Antes da v1.14, o Karpenter não lia essas solicitações DRA ao planejar novos nós. Assim, um pod que precisasse de uma GPU via DRA podia ficar travado, porque o Karpenter não criava um nó capaz de executá-lo. Para contornar isso, você tinha que direcionar esses pods para os nós certos manualmente, com um nodeSelector ou node affinity, do mesmo jeito que pods de GPU são roteados no modelo mais antigo de device plugin. O Karpenter lê esses campos, mas não conseguia ler o claim DRA por conta própria. A v1.14 adiciona um alocador DRA. Agora o Karpenter lê a solicitação DRA do pod e a usa para escolher o nó certo. Ele também lida com dispositivos compartilhados e divisíveis, o que ajuda quando alguns pods compartilham o mesmo acelerador.

Você não precisa ativar nada. O recurso vem ligado por padrão. Para fazer o Karpenter ignorar solicitações DRA, defina a flag --ignore-dra-requests. Mas isso ainda está em estágio inicial. Se você executa workloads de GPU ou aceleradores com DRA, teste primeiro em staging. Você também precisa do Kubernetes 1.34 ou superior e de um driver DRA para o seu hardware. A referência de Settings tem os detalhes da flag.

CapacityBuffer no Karpenter: mantenha nós extras prontos

Novos nós levam tempo para iniciar e entrar no cluster. Para workloads com picos ou que não podem esperar, esse atraso sai caro. Os pods ficam pendentes, e o seu serviço não escala a tempo de atender o tráfego. O CapacityBuffer permite manter uma capacidade extra pronta, para que os pods sejam agendados imediatamente em vez de esperar por um novo nó.

Ele funciona com pods virtuais de reserva (placeholders). Esses pods existem apenas no planejamento do Karpenter. Eles nunca são pods reais no seu cluster. Eles fazem o Karpenter manter nós extras prontos e se reabastecem sozinhos quando os seus pods reais usam o espaço extra.

Você define o tamanho da capacidade extra de duas formas:

1. podTemplateRef: aponte para um PodTemplate que descreve uma unidade de buffer e defina replicas e/ou limits.
2. scalableRef: aponte para um Deployment, StatefulSet ou ReplicaSet e defina um percentual para manter a capacidade extra acompanhando esse workload.

Veja um buffer fixo 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"

Ou, para manter a capacidade extra acompanhando um workload, aponte para um Deployment e defina um percentual. Isto mantém a capacidade do buffer em 20% das réplicas do Deployment api-service, então a capacidade extra cresce e diminui conforme esse 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

Quando você define mais de um desses campos, a contagem final é min(max(replicas, percentage), limits). Ou seja, replicas e percentage são combinados pegando o maior valor, e limits estabelece o teto do resultado.

Há um detalhe importante sobre a limpeza de nós. O Karpenter não remove um nó como vazio se ele contém capacidade de buffer. Os pods virtuais de buffer impedem que ele conte como vazio, e o Karpenter o marca com o motivo Node has buffer pods. Todos os outros tipos de limpeza continuam rodando, e qualquer nó substituto ainda precisa acomodar os pods de buffer, então a capacidade extra se mantém abastecida.

O CapacityBuffer está em alpha e vem desativado por padrão. Você o ativa com o feature gate CapacityBuffer=true. Ele foi adicionado na v1.13, e a v1.14 evoluiu sua API interna e adicionou métricas de status, mas ele ainda está em alpha e a API pode mudar. Teste primeiro em um cluster de testes. Lembre também que capacidade extra custa dinheiro, porque você paga por nós ociosos. Dimensione de acordo com o pico real que você precisa atender.