Karmada virou Graduated no CNCF — e o v1.19 muda um default de scheduling

Em 8 de setembro de 2026 o CNCF anunciou o Karmada como seu mais novo projeto Graduated — o mesmo nível de maturidade de Kubernetes, Prometheus, Envoy e Istio. Pra chegar lá o projeto passou por auditoria de segurança independente, formalizou um steering committee e sustentou o CII Best Practices Badge por tempo suficiente pra provar que não depende de uma única empresa ou mantenedor.

Se você nunca usou Karmada, o resumo é: ele resolve orquestração multi-cluster e multi-cloud sem pedir que você reescreva manifests. Você aplica o YAML normal contra a karmada-apiserver e associa uma PropagationPolicy (ou ClusterPropagationPolicy, pra recursos cluster-scoped) dizendo em quais clusters membro aquilo deve rodar — com regras de failover e override por cluster. A comunicação com os clusters membro pode ser em modo push (o control plane do Karmada acessa a API dos membros diretamente, bom pra clusters na mesma rede) ou pull (um karmada-agent roda dentro do cluster membro e busca instruções no control plane, necessário quando o cluster está atrás de firewall ou é edge).

Desde que entrou no Sandbox em 2021 e passou pra Incubating em dezembro de 2023, o projeto cresceu pra mais de 1.200 contribuidores de 292 organizações, com adotantes documentados como Bloomberg e Wellhub, além de players de cloud, telecom e IA na Ásia.

A graduação coincidiu com o release do v1.19.0, publicado em 31 de agosto de 2026. E é o release — não o selo — que muda comportamento de quem já roda Karmada ou está avaliando adotar. Quatro pontos merecem atenção antes de atualizar.

Fix: rotação de credencial parava de sincronizar em silêncio

Em modo push, o Karmada mantém um watch aberto contra a API de cada cluster membro pra reagir a mudanças de status. Antes do v1.19, se o bearer token usado nesse watch fosse rotacionado — o que acontece por padrão em vários setups de service account com token de vida curta —, a conexão não era renovada automaticamente. O watch continuava “vivo” na aparência, mas parava de receber eventos novos. Sem crash, sem log óbvio de erro recorrente: só um cluster que para de refletir status atualizado até alguém reiniciar o componente manualmente.

O v1.19 implementa uma camada de transporte que renova o token no informer automaticamente quando ele rotaciona, sem exigir restart. Se você roda push mode com tokens de curta duração — comum em integrações com OIDC ou em clusters gerenciados que forçam rotação —, esse fix sozinho já justifica a atualização, porque o sintoma anterior é exatamente do tipo que passa despercebido até virar incidente.

Default novo: scheduling por prioridade vira Beta e liga sozinho

O feature gate PriorityBasedScheduling foi promovido a Beta e vem habilitado por padrão no v1.19. Na prática, isso faz o scheduler do Karmada respeitar spec.schedulePriority nas suas PropagationPolicy e agendar workloads de prioridade mais alta primeiro quando há disputa por capacidade entre clusters.

Se você nunca configurou schedulePriority, o efeito prático deve ser neutro — sem prioridade declarada, não há reordenação pra aplicar. Mas se algum manifesto seu já tem esse campo preenchido (por exemplo, copiado de um exemplo da documentação sem intenção de usar o recurso), o comportamento de scheduling muda no upgrade sem você ter pedido. Vale grepar suas policies por schedulePriority antes de atualizar. Pra manter o comportamento anterior de qualquer forma, dá pra desligar com --feature-gates=PriorityBasedScheduling=false no karmada-scheduler.

Breaking change: dois valores de PurgeMode saíram do ar

PurgeMode é o campo que controla o que acontece com a instância antiga de uma aplicação quando ela migra de cluster por failover — Directly evicta na hora (útil quando duas instâncias rodando ao mesmo tempo não pode acontecer), Gracefully espera a aplicação ficar saudável no cluster novo antes de tirar a antiga do ar.

Os valores antigos Immediately e Graciously — que já estavam deprecados — foram removidos no v1.19, não só descontinuados. Se alguma PropagationPolicy sua com regra de failover ainda usa esses nomes, ela vai falhar validação depois do upgrade do control plane. É find-and-replace simples (Immediately → Directly, Graciously → Gracefully), mas precisa ser feito antes, não depois de descobrir em produção.

Memória: mesma carga, menos RAM

Karmada estripou managedFields dos caches dos informers dinâmicos e separou melhor a responsabilidade entre o execution controller (mudanças nos clusters membro) e o work-status controller (coleta de status), eliminando reconciliação duplicada. O resultado reportado pelo projeto: pico de memória do karmada-controller-manager caindo de 5 GB pra 3.4 GB num teste distribuindo 20.000 Deployments. Se você dimensionou o control plane pro consumo do v1.18, vale reavaliar o limite depois de migrar — não porque vai faltar memória, mas porque provavelmente sobra headroom que estava sendo desperdiçado.

Quem deveria se importar com isso

Se você roda um cluster Kubernetes só, isso não muda nada pra você hoje. Karmada resolve um problema específico: aplicação distribuída em múltiplos clusters — por região, por cloud, por ambiente de produção replicado — com uma política declarativa central em vez de pipeline de CI/CD duplicando manifests por cluster. Se esse é o seu cenário e você está hoje resolvendo isso com script, Terraform aplicando N vezes, ou ArgoCD ApplicationSet puro sem lógica de failover, vale colocar Karmada na lista de avaliação — a chancela Graduated é, no mínimo, sinal de que o projeto não vai sumir nem mudar de API de forma descontrolada.

Antes de atualizar pra v1.19

Se você roda push mode: nenhuma ação necessária além de atualizar — o fix de rotação de credencial é automático.
Grep suas PropagationPolicy e ClusterPropagationPolicy por schedulePriority; se existir e não for intencional, decida se aceita o novo comportamento de scheduling ou desliga o feature gate.
Grep as mesmas policies por purgeMode: Immediately ou purgeMode: Graciously e substitua antes do upgrade do control plane, não depois.
Se você fixa limite de memória pro karmada-controller-manager via resources.limits, revalidar depois da migração — o número mudou pra baixo no benchmark do projeto, mas seu workload real pode variar.