Kata Containers[1] es uno de esos proyectos que llevan años en la conversación sin llegar nunca a ser la opción por defecto. La historia tiene un matiz nuevo.

El proyecto publica versiones menores de la serie 3.x casi cada mes, ya bajo el paraguas de la OpenInfra Foundation[2]. Cada una trae 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. El runtime mantiene la interfaz OCI, así que Kubernetes, containerd y el resto del ecosistema pueden 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[3], publicado a finales de 2022, 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 para los casos que requieren dispositivos adicionales: arranca más rápido que QEMU y es más completo que Firecracker. 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[4], la alternativa de Google para aislamiento fuerte de contenedores. Repasamos su enfoque en gVisor: sandboxing para 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 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 los pods se ejecutan con runc por defecto y solo los 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 dominadas por 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.

Este artículo también está disponible en inglés: Kata Containers: strong isolation with a Docker-like experience.

Fuentes:

  1. Kata Containers, sitio oficial del proyecto[1]
  2. kata-containers/kata-containers, historial de versiones en GitHub[3]
  3. gVisor, sandbox de contenedores de Google[4]
  4. OpenInfra Foundation, gobernanza del proyecto[2]

Preguntas frecuentes

¿Cuánta memoria y CPU extra cuesta ejecutar un pod con Kata en lugar de runc?

En un cluster de pruebas con nodos de 32 GB, un pod con runc consume unos 200 MB por encima de la aplicación y el mismo pod con Kata unos 450 MB. En una aplicación Java de 2 GB el diferencial es del 12 por ciento; en una aplicación Node de 100 MB dobla el coste total. En CPU la penalización es del 2 al 5 por ciento en cargas CPU-bound y sube al 10 o 15 por ciento en cargas de red dominadas por conexiones cortas.

¿Puedo mezclar pods con runc y pods con Kata en el mismo cluster de Kubernetes?

Sí. Despliegas el operador de Kata Containers, creas una RuntimeClass con nombre kata y cualquier pod que la seleccione vía spec.runtimeClassName se ejecuta aislado en su microVM, mientras el resto sigue con runc. El operador prepara el hypervisor, el kernel invitado y el agente en el nodo, y el planificador coloca los pods sensibles en los nodos etiquetados. Los problemas recurrentes son el almacenamiento NFS o CSI (virtiofs), el passthrough de GPU o FPGA y las herramientas de observabilidad que esperan ver procesos en el anfitrión.

¿Qué diferencia a Kata Containers de gVisor?

gVisor intercepta las llamadas al sistema en espacio de usuario con un kernel implementado en Go, sin hypervisor. Es más ligero, pero su aislamiento depende de que ese kernel esté libre de fallos y no soporta todas las llamadas al sistema. Kata ejecuta cada contenedor en una microVM con un kernel Linux invitado estándar, así que la compatibilidad con aplicaciones es casi total. El precio es más memoria y algo más de latencia en red y almacenamiento.

Fuentes

  1. Kata Containers
  2. OpenInfra Foundation
  3. Kata 3.0
  4. gVisor