Kata Containers: aislamiento fuerte con experiencia Docker
Actualizado: 2026-05-03
Kata Containers es uno de esos proyectos que llevan años en la conversación sin llegar nunca a ser la opción por defecto. En octubre de 2025 la historia tiene un matiz nuevo: el proyecto se acerca a la versión 3.10, ya bajo la OpenInfra Foundation, con una lista concreta de mejoras que responden a las críticas más comunes de los últimos años. Tras probarlo en serio en un cluster de pruebas, las opiniones son más claras que en intentos anteriores.
Puntos clave
- Kata ejecuta cada contenedor dentro de una microVM ligera con su propio kernel, manteniendo la interfaz OCI para Kubernetes y containerd.
- La reescritura en Rust de la versión 3.x redujo la huella de memoria del agente a la mitad y los tiempos de arranque a menos de tres segundos en la mayoría de casos.
- El soporte de contenedores confidenciales (AMD SEV-SNP, Intel TDX) lo convierte en una de las pocas opciones viables sin reescribir la aplicación.
- Un pod con Kata consume unos 450 MB frente a los 200 MB de runc; la penalización de CPU en cargas CPU-bound es del 2 al 5 por ciento.
- El caso más prometedor en 2025 no es el cluster de producción clásico sino las plataformas de ejecución de código por agentes de IA.
La idea de fondo que nunca ha cambiado
Kata Containers resuelve un problema concreto y lo resuelve siempre de la misma manera: los contenedores runc comparten kernel con el anfitrión, y eso es un vector de riesgo inaceptable para ciertos casos. La solución es ejecutar cada contenedor dentro de una máquina virtual ligera con su propio kernel invitado, pero manteniendo la interfaz OCI para que Kubernetes, containerd y el resto del ecosistema puedan usarlo como si fuera runc.
El truco está en la combinación de tres piezas:
- Un hypervisor rápido (QEMU recortado, Firecracker o Cloud Hypervisor según configuración).
- Un kernel invitado mínimo compilado para arrancar en milisegundos.
- Un agente dentro del invitado que recibe peticiones del runtime anfitrión y las traduce a llamadas locales.
El resultado es un contenedor que arranca casi igual de rápido que uno normal, consume algo más de memoria y tiene un aislamiento equivalente al de una VM.
Lo que cambia en las versiones 3.x
El salto más visible de Kata 3.0, salido a finales de 2023, fue la reescritura del runtime en Rust. El agente invitado, que antes era Go, pasó también a Rust. Ese cambio no es cosmético: reduce la huella de memoria del agente a la mitad y elimina varias clases de fallos intermitentes que afectaban a contenedores con mucha actividad de entrada y salida. Los tiempos de arranque bajaron de los seis u ocho segundos de antes a menos de tres en la mayoría de casos.
La segunda mejora importante es el soporte de contenedores confidenciales, que permite ejecutar cargas en enclaves TEE como AMD SEV-SNP o Intel TDX. Para quien necesita certificación de que ni el operador del cluster puede ver la memoria del contenedor, este soporte convierte a Kata en una de las pocas opciones viables sin reescribir la aplicación.
La tercera es el trabajo en el hypervisor. Cloud Hypervisor se ha consolidado como la opción por defecto en muchos escenarios por ser más rápido de arrancar que QEMU y más completo que Firecracker para casos que requieren dispositivos adicionales. Tener tres hypervisors intercambiables bajo la misma interfaz permite afinar según características de la carga.
Cómo se compara con gVisor y con runc
La comparación obligada es con gVisor, la alternativa de Google para aislamiento fuerte de contenedores. gVisor intercepta llamadas al sistema en espacio de usuario mediante un kernel implementado en Go, sin necesidad de hypervisor. Es más ligero que Kata pero el modelo de aislamiento es diferente: depende de que su propio kernel de usuario esté libre de fallos, y la compatibilidad con cargas reales es menor porque no soporta todas las llamadas al sistema.
Kata, al usar un kernel invitado Linux estándar, tiene compatibilidad casi total con cualquier aplicación que funcione en un contenedor. El precio es más memoria y algo más de latencia en operaciones de red y almacenamiento. Para cargas típicas de aplicaciones web o colas de trabajo, la diferencia es pequeña. Para cargas muy sensibles a latencia o a rendimiento de entrada/salida, se nota.
Frente a runc, la diferencia es la de siempre: Kata aisla más y consume más. En un cluster donde todos los contenedores son de confianza, runc es suficiente y más barato. En un cluster multi-tenant donde ejecutas código de terceros o cargas confidenciales, Kata justifica el sobrecoste.
El modelo operativo en Kubernetes
La parte que más ha madurado es la integración con Kubernetes. El operador de Kata Containers cubre el camino feliz: despliegas el operador, creas una RuntimeClass con nombre kata, y cualquier pod que la seleccione vía spec.runtimeClassName se ejecuta aislado.
Esto permite un patrón que hace tres años era solo teoría: clusters mixtos donde la mayoría de los pods se ejecutan con runc y solo los pods marcados como sensibles usan Kata. El operador se encarga de que el nodo tenga el hypervisor, el kernel invitado y el agente preparados; el planificador de Kubernetes coloca los pods sensibles en nodos con esa etiqueta y los demás donde encajen.
En práctica aparecen tres problemas recurrentes:
- Almacenamiento persistente con NFS o CSI montado desde el anfitrión (requiere cuidado con virtiofs).
- Cargas con GPU o FPGA (el passthrough funciona pero aumenta el arranque).
- Herramientas de observabilidad que esperan ver procesos en el anfitrión, cosa que no pasa con el contenedor corriendo en VM invitada.
Este último punto conecta con lo que analizamos en observabilidad de agentes de IA: la instrumentación tiene que adaptarse al modelo de ejecución, no al revés.
Coste real de memoria y rendimiento
Los números importan porque es donde más fantasía hay en las presentaciones. En un cluster de pruebas con nodos de 32 GB:
- Un pod con runc consume unos 200 MB por encima de la aplicación.
- El mismo pod con Kata consume unos 450 MB.
En una aplicación Java pesada que ya consume 2 GB, el diferencial es el 12 por ciento. En una aplicación Node de 100 MB, el diferencial dobla el coste total.
En CPU la penalización es mínima en cargas CPU-bound (2 al 5 por ciento). En cargas de red con muchas conexiones cortas sube al 10 o 15 por ciento porque cada paquete atraviesa anfitrión, hypervisor y kernel invitado.
Mi lectura
Kata Containers está en el mejor momento de su historia y sigue siendo una opción de nicho. La combinación de Rust, operador Kubernetes maduro y soporte de TEE lo convierte en una herramienta que merece estudiarse en tres escenarios: clusters multi-tenant, cargas confidenciales y entornos con requisitos regulatorios fuertes. Para el resto de casos no es la opción por defecto y probablemente nunca lo será.
Donde más interesante resulta ahora es en plataformas de agentes autónomos y de ejecución de código por modelos de lenguaje. Esos casos combinan código no confiable con necesidad de ejecutarlo rápido y desecharlo igual de rápido; Kata encaja ahí casi por diseño, y varios proveedores de sandbox llevan meses construyendo sobre él. Esta adopción puede ser la que termine consolidando el proyecto más que la de los clusters de producción clásicos.
Conclusión
Quien opera clusters pequeños sin requisitos estrictos de aislamiento puede ignorar Kata y no perderse nada. Quien opera una plataforma donde clientes externos despliegan código o donde hay separación regulatoria entre equipos, debería probarlo en serio. La inversión en aprender el modelo operativo se amortiza porque la alternativa es mantener clusters separados, más caro y más complejo.
