O Karmada, projeto de orquestração multi-cluster e multi-cloud para Kubernetes, atingiu o nível de graduação da Cloud Native Computing Foundation (CNCF) em setembro de 2026, coincidindo com o lançamento da versão v1.19. O anúncio aconteceu na KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026, em Xangai, e consolida a ferramenta no mais alto nível de maturidade da fundação, reservado a projetos estáveis, amplamente adotados e prontos para produção.
A graduação coroa um trajeto iniciado em setembro de 2021, quando o projeto entrou no Sandbox da CNCF, seguido pela promoção ao estágio Incubating em dezembro de 2023. Hoje o Karmada reúne mais de 1.214 contribuidores de 292 organizações e ultrapassa 5.600 estrelas no GitHub.
O que o karmada resolve e por que a graduação importa
Karmada é um sistema de orquestração Kubernetes multi-cluster e multi-cloud que estende a API padrão do Kubernetes sem substituí-la. Rodar uma aplicação em vários clusters é uma necessidade comum para cenários de nuvem híbrida, failover regional e redução de dependência de fornecedor, e o projeto ataca exatamente esse ponto.
Antes dele, times dependiam de automação própria ou do KubeFed, projeto hoje arquivado que exigia aprender uma API federada diferente e tinha limitações de flexibilidade. O Karmada permite que manifests, controllers e ferramentas existentes funcionem sem alterações em seu control plane.
Mas por que isso ganhou urgência agora? O motivo está na inteligência artificial. Com a capacidade de GPU espalhada entre regiões e provedores, nenhum cluster isolado concentra aceleradores suficientes. Times de treinamento e inferência distribuídos precisam dividir, agendar e mover workloads entre vários sistemas, e é aí que a orquestração multi-cluster deixa de ser opcional.
# publicidade
Arquitetura: control plane dedicado e políticas declarativas
O control plane do Karmada tem três componentes: Karmada API Server, Karmada Controller Manager e Karmada Scheduler, com instância própria de etcd para estado. A lógica de posicionamento se expressa por duas APIs customizadas.
Propagationpolicy e overridepolicy
A PropagationPolicy mapeia uma política para um conjunto de workloads (1:n) e define restrições de agendamento e distribuição: afinidade de cluster, divisão e rebalanceamento multi-cluster e alta disponibilidade multidimensional por região, zona de disponibilidade, cluster ou provedor.
Já a OverridePolicy permite reescrever configurações específicas por cluster, como trocar prefixos de imagem de container por região ou StorageClass por provedor de nuvem, sem tocar no template do recurso.
Na prática, quatro controllers executam a propagação: Cluster Controller (ciclo de vida dos clusters membros), Policy Controller (liga recursos em objetos ResourceBinding), Binding Controller (converte cada binding em Work objects por cluster) e Execution Controller (envia os manifests para a API server de cada cluster membro).
O projeto ainda exporta métricas Prometheus e distribui charts Helm, conectando-se diretamente ao ecossistema de observabilidade e deploy da CNCF. O exemplo mínimo de uma política de propagação ilustra o modelo declarativo:
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
name: nginx-propagation
spec:
resourceSelectors:
- apiVersion: apps/v1
kind: Deployment
name: nginx
placement:
clusterAffinity:
clusterNames:
- cluster-east
- cluster-west
spreadConstraints:
- spreadByField: region
maxGroups: 2Versão 1.19: agendamento para jobs de treinamento de IA
A versão v1.19, lançada junto ao anúncio da graduação, melhora o agendamento multi-componente para jobs de treinamento de IA e promove a priorização de agendamento por prioridade para o estágio Beta, agora habilitada por padrão.
A lista de adotantes em produção é extensa e concentrada em grandes operações asiáticas e globais: Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, JDCloud, Kuaishou, RedNote, SenseTime, Vivo, WPS e ZTO. Os casos de uso incluem capacidade de nuvem híbrida, resiliência entre regiões, agendamento de GPU e CPU para workloads de IA e distribuição de configuração para toda a frota.
Na Trip.com, o Karmada se tornou parte crítica da infraestrutura multi-cluster, permitindo operar múltiplos clusters como um pool unificado de recursos, com elasticidade entre clusters, failover e migração de workloads em larga escala com interrupção mínima, sem mudar as definições de recursos Kubernetes existentes, segundo Honghui Yue, especialista sênior de desenvolvimento da empresa.
Chad Beaudin, TOC Sponsor do projeto, resumiu a tese da graduação: conforme as organizações escalam além de um único cluster, precisam de gestão consistente sem complexidade adicional, e o Karmada resolve isso estendendo APIs familiares do Kubernetes.
Requisitos de graduação e o cenário multi-cluster
Para se graduar, o Karmada passou por auditoria de segurança de terceiros, formou um comitê de governo formal, adotou o Código de Conduta da CNCF e mantém o selo CII Best Practices.
O Karmada é um dos dois projetos da CNCF que substituíram o aposentado KubeFed (Federation v2). O outro é o Open Cluster Management (OCM), ainda em Sandbox, com abordagem hub-and-spoke baseada em agentes, focada em inventário de clusters e governança, base do Red Hat Advanced Cluster Management. Como o Karmada se compara às alternativas do ecossistema?
Enquanto o OCM enfatiza distribuição de políticas, o Karmada foca em posicionamento de workloads e agendamento dinâmico, com camadas de cache para consultas entre clusters e descoberta de serviços multi-cluster. O cenário maior inclui ainda Cluster API (ciclo de vida de clusters), ferramentas GitOps como ApplicationSets do Argo CD e Rancher Fleet, além do KubeFleet da Microsoft, base do Azure Kubernetes Fleet Manager.
| Projeto | Estágio CNCF | Foco principal |
|---|---|---|
| Karmada | Graduated | Placement de workloads e agendamento dinâmico multi-cluster |
| Open Cluster Management | Sandbox | Governança, inventário e distribuição de políticas |
| Cluster API | Em desenvolvimento | Ciclo de vida de clusters |
| KubeFleet (Microsoft) | Fora da CNCF | Base do Azure Kubernetes Fleet Manager |
Arraste para o lado para ver toda a tabela.
Info: o anúncio da graduação foi feito em setembro de 2026, em Xangai, junto ao lançamento da v1.19, com o agendamento baseado em prioridade promovido a Beta e ativado por padrão.
Dica: se você opera mais de um cluster Kubernetes no Brasil, teste o Karmada em ambiente de homologação usando os charts Helm oficiais e valide as métricas Prometheus antes de mover workloads de IA entre regiões.
Na avaliação do Mercado de TI, a graduação chega em um momento estratégico: a escassez e a fragmentação de capacidade de GPU tornam o agendamento multi-cluster um requisito real para times de IA, e não apenas um exercício de arquitetura. Para times brasileiros que já investem em Kubernetes como control plane e enfrentam custos crescentes com cloud híbrida, o Karmada oferece um caminho maduro e com governança formal para consolidar frotas de clusters sem reescrever manifests existentes.
O próximo passo natural é observar se a v1.19 acelera adoções fora da Ásia e como o projeto responde à concorrência de alternativas gerenciadas pelos grandes provedores de nuvem.
Fonte: Infoq
