Karmada se gradúa en la CNCF y estrena la versión 1.19 con foco en IA
El proyecto de orquestación de Kubernetes sobre varios clústeres y nubes alcanza el nivel de madurez más alto de la fundación y publica una versión que mejora la planificación de cargas de entrenamiento.
La CNCF ha anunciado la graduación de Karmada, el proyecto de orquestación de Kubernetes sobre múltiples clústeres y nubes, que alcanza así el nivel de madurez más alto de la fundación. El anuncio se hizo en la KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026, en Shanghái, y coincidió con la publicación de la versión 1.19.
Para graduarse, un proyecto tiene que demostrar adopción real y procesos que aguanten una revisión externa. Karmada pasó una auditoría de seguridad de terceros, formó un comité de dirección formal, adoptó el código de conducta de la CNCF y mantiene el distintivo CII Best Practices. Desde su entrada en el Sandbox en septiembre de 2021 y su paso a Incubating en diciembre de 2023, ha crecido hasta 1.214 contribuyentes de 292 organizaciones y más de 5.600 estrellas en GitHub. En su lista de adoptores en producción aparecen Bloomberg, Wellhub, Alibaba Cloud, Huawei, Trip.com, Bilibili, iFLYTEK, JDCloud, Kuaishou, RedNote, SenseTime, Vivo, WPS y ZTO, para capacidad de nube híbrida, resiliencia entre regiones, planificación de GPU y CPU para cargas de IA y distribución de configuración en flotas enteras.
Qué trae la 1.19
La versión que acompaña al anuncio (notas de la versión) añade planificación multicomponente para trabajos de entrenamiento de IA y mueve a Beta la planificación basada en prioridades, que ahora viene activada por defecto. El contexto no es menor: la capacidad de GPU está repartida entre regiones y proveedores, ningún clúster suelto tiene aceleradores suficientes, y las cargas hay que trocearlas, planificarlas y desplazarlas entre varios sistemas.
Cómo funciona por dentro
Karmada, abreviatura de "Kubernetes Armada", no sustituye la API de Kubernetes, la extiende. Los manifiestos, controladores y herramientas que ya existan siguen funcionando sobre su plano de control, formado por un API Server, un Controller Manager y un Scheduler propios, con su propia instancia de etcd para el estado. La lógica de colocación se expresa con dos APIs personalizadas: PropagationPolicy, que asocia una política a un conjunto de cargas y define restricciones de reparto, afinidad de clúster y alta disponibilidad por región, zona, clúster o proveedor; y OverridePolicy, que permite reescribir configuración específica de cada clúster, como el prefijo de imagen por región o la StorageClass por nube, sin tocar la plantilla del recurso. Por debajo, cuatro controladores hacen la propagación: uno gestiona el ciclo de vida de los clústeres registrados, otro convierte las políticas en ResourceBinding, un tercero genera objetos Work por clúster y el último los empuja al API server de cada miembro. El proyecto exporta métricas de Prometheus desde sus componentes y publica charts de Helm, de modo que se integra en el stack de observabilidad y despliegue que ya haya montado, en lugar de exigir uno aparte.
Karmada es uno de los dos proyectos que ocuparon el hueco de KubeFed, retirado (repositorio archivado). El otro es Open Cluster Management, todavía en Sandbox, con un modelo hub-and-spoke basado en agentes centrado en inventario de clústeres y APIs de complementos; es la base de Red Hat Advanced Cluster Management y pone el acento en gobierno y distribución de políticas. Karmada se centra en la colocación de cargas y la planificación dinámica, e incluye capas de caché para consultas entre clústeres y descubrimiento de servicios multiclúster. Alrededor conviven Cluster API, que atiende el ciclo de vida del clúster y no la colocación, las ApplicationSets de Argo CD y Rancher Fleet en el terreno GitOps, y KubeFleet de Microsoft, base de Azure Kubernetes Fleet Manager.
Sobre el terreno operativo, Honghui Yue, experto de desarrollo en Trip.com, asegura que "sin cambiar las definiciones de recursos de Kubernetes existentes, nos ha permitido operar varios clústeres como un pool de recursos unificado, soportar elasticidad y failover entre clústeres, poner nuevos clústeres en producción de forma más eficiente y hacer migraciones de cargas a gran escala con una disrupción mínima".
Lo relevante para quien mantiene flotas de Kubernetes es que Karmada llega a graduación sin pedir un cambio de modelo mental: misma API, mismos manifiestos, y una capa de planificación encima. Queda por ver si esa promesa aguanta cuando el número de clústeres y de proveedores crece y las políticas de colocación empiezan a solaparse.
