KubeVirt mira a 10 años: VMs, IA confidencial y hardware nuevo

KubeVirt nació en 2016 dentro de Red Hat con una idea sencilla pero ambiciosa: que Kubernetes pudiera ejecutar máquinas virtuales junto a contenedores. Diez años después, ese objetivo sigue vigente, pero el proyecto ha cambiado de escala. Hoy es un proyecto en incubación de la CNCF, con contribuciones de Nvidia, Microsoft, AMD, Intel, SUSE y otros actores, y la comunidad trabaja para conseguir su graduación como proyecto CNCF. La noticia que nos ocupa repasa qué traerán las próximas versiones y, sobre todo, cómo se está organizando el proyecto para no perder el rumbo mientras crece.

De una idea de 2016 a un ecosistema en expansión

El propósito original no ha cambiado: permitir que las cargas de trabajo heredadas convivan con las aplicaciones modernas en la misma plataforma. Lo que sí ha cambiado es que otros proyectos han demostrado que pueden construir sobre KubeVirt. Open Sovereign AI Cloud (OSAC) lo usa para servicios de máquinas virtuales, clústeres y bare-metal; Cluster API Provider KubeVirt (CAPK) emplea VMs de KubeVirt como nodos de Kubernetes; y Flight Control ejecuta un virt-launcher en el edge sin necesidad del plano de control completo de KubeVirt.

Ese crecimiento se refleja en los números internos del proyecto. Entre las versiones v1.6 y v1.10, la cola de propuestas pasó de un puñado de elementos a más de un centenar. Solo la v1.9 incluyó docenas de propuestas nuevas. Para que ese volumen no rompa el núcleo, el proyecto se apoya en el proceso VEP (KubeVirt Enhancement Proposal): primero el diseño, luego el código, un único tracker y responsabilidad repartida entre grupos de interés especial (SIG).

Dispositivos, DRA y hardware acelerado

Uno de los frentes más interesantes es la gestión de dispositivos. Las GPUs en máquinas virtuales ya pueden solicitarse mediante Dynamic Resource Allocation (DRA) de Kubernetes en lugar de usar device-plugins, y esa funcionalidad está en beta desde la v1.9. El mismo modelo se está extendiendo a dispositivos genéricos del host, dispositivos de red como SR-IOV y también a las CPUs. La idea es que, en un futuro cercano, una VM pueda pedir GPU, NIC y CPUs y que Kubernetes los asigne como un conjunto coordinado.

También se trabaja para que KubeVirt construya esas solicitudes a partir de la especificación de la VM y de una política del fabricante, sin obligar a cada usuario a escribir objetos ResourceClaim a mano. La filosofía de fondo es clara: preferir mecanismos nativos de Kubernetes antes que soluciones aisladas de virtualización. Eso permite mejorar la granularidad de las asignaciones y, al mismo tiempo, eliminar rutas exclusivas de KubeVirt cuando el clúster ya ofrece una alternativa.

En paralelo, ingenieros de Nvidia y otros contribuidores han trabajado para que KubeVirt funcione sobre hardware más reciente de Nvidia, como Grace Hopper, Grace Blackwell y Vera Rubin. Ese desarrollo nació en el grupo de trabajo de habilitación de infraestructura acelerada y está subiendo al proyecto principal.

VMs confidenciales: proteger datos y modelos en ejecución

El segundo gran bloque tiene que ver con la confianza. Cada vez más organizaciones quieren ejecutar aplicaciones sensibles y cargas de IA en infraestructura compartida sin exponer sus datos ni sus modelos durante la ejecución. La computación confidencial utiliza entornos de ejecución de confianza respaldados por hardware para aislar esas cargas, incluso frente a software privilegiado del host dentro del modelo de amenaza de la plataforma. La atestación remota permite al propietario de la carga evaluar las evidencias de ese entorno antes de entregarle secretos.

KubeVirt está ampliando el soporte de VMs confidenciales y explorando la integración con servicios de atestación y liberación de secretos, incluido Trustee del proyecto Confidential Containers. El trabajo abarca Intel TDX, AMD SEV y SEV-SNP, IBM Secure Execution y la arquitectura Arm CCA. En la v1.9, la puerta de funcionalidad de AMD SEV y SEV-SNP pasó a beta, el soporte de Intel TDX sigue en alpha y el de IBM Secure Execution alcanzó disponibilidad general. La habilitación de Arm CCA continúa en desarrollo.

Para la IA, el límite de confianza debe abarcar todo el recorrido de ejecución: CPUs, aceleradores y las interconexiones entre ellos. Los propietarios de cargas necesitan verificar ese entorno mediante atestación antes de liberar datos sensibles o claves de modelos.

De cara al futuro, los contribuidores exploran un descubrimiento más consistente de capacidades TEE entre los nodos del clúster, de modo que Kubernetes pueda colocar VMs confidenciales en la infraestructura adecuada. Otras propuestas abordan los datos de inicialización de la atestación, el manejo de evidencias y la integración con servicios externos de verificación y liberación de secretos. Para cargas aceleradas, la ambición se extiende a la asignación confidencial de dispositivos y a la comunicación protegida entre CPUs y aceleradores.

Qué significa esto para una pyme

A primera vista, KubeVirt puede parecer un tema de grandes infraestructuras. Pero conviene leerlo con perspectiva práctica. Si tu empresa tiene aplicaciones antiguas que no puedes reescribir de la noche a la mañana, KubeVirt ofrece un camino para mantenerlas junto a las nuevas sin montar dos plataformas separadas. Si además estás explorando IA, el avance hacia VMs confidenciales y aceleradores protegidos anticipa un futuro en el que la seguridad del dato en ejecución será parte del diseño, no un añadido.

Nuestra recomendación es no lanzarse a migrar todo de golpe. Empieza por identificar cargas heredadas que podrían convivir con contenedores y valora si tu equipo tiene ya experiencia con Kubernetes. Revisa también qué hardware tienes: las capacidades de DRA y de computación confidencial dependen del soporte del fabricante y del firmware. Y mantén un ojo en el ecosistema: proyectos como CAPK o Flight Control pueden simplificar la integración en escenarios concretos.

Si estás automatizando procesos con herramientas como n8n e IA, o comparando modelos de IA en línea, ten presente que la infraestructura subyacente también evoluciona. Un enfoque híbrido, con Kubernetes como denominador común y KubeVirt para lo que no puede contenedorizarse, reduce la fragmentación y facilita la gobernanza. Como siempre, la clave está en medir el coste operativo real antes de adoptar una pieza nueva en la arquitectura.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.