Actualizado: 2026-07-07

Los contenedores comparten el kernel del anfitrión y esa propiedad, que explica buena parte de su ligereza, también marca su techo en entornos multi-tenant donde la confianza entre cargas es baja. gVisor nació dentro de Google precisamente para resolver ese techo: interponer un kernel escrito en Go entre el proceso del contenedor y el kernel real del anfitrión, reduciendo la superficie de llamadas al sistema expuesta y ofreciendo una forma de aislamiento intermedia entre el contenedor tradicional y la máquina virtual ligera.

Puntos clave

  • gVisor implementa el runtime runsc, compatible con OCI, que sustituye a runc interponiendo un kernel en espacio de usuario llamado Sentry.

  • El modo systrap, publicado en 2023 y convertido en opción por defecto ese mismo año, es la recomendada hoy: buen rendimiento, portable, sin requisitos especiales de hardware.

  • Para cargas de CPU el coste suele quedarse en un dígito bajo; para cargas con muchas llamadas al sistema (Redis, bases de datos con escritura constante) el impacto medido en bancos de pruebas independientes va del 50 % a más del 100 %.

  • Integrar gVisor en un clúster Kubernetes existente requiere instalar runsc y declarar una RuntimeClass; el resto de pods siguen con runc.

  • Tiene sentido para cargas multi-tenant, funciones serverless y ejecución de código de terceros; no para bases de datos pesadas o cargas con alto IOPS.

Qué es gVisor y por qué se construyó

gVisor implementa un runtime compatible con OCI llamado runsc que sustituye a runc. La diferencia decisiva es que runsc no deja al proceso del contenedor hablar con el kernel del anfitrión directamente. En su lugar, un componente llamado Sentry, un kernel de Linux reimplementado en Go en espacio de usuario, intercepta esas llamadas y responde a la mayoría por sí mismo, hablando con el anfitrión solo cuando no queda otra opción y siempre a través de un perímetro muy acotado.

El resultado es que un exploit del kernel que normalmente escalaría del contenedor al anfitrión tiene que atravesar primero la implementación de Sentry, que es mucho más pequeña y está escrita en un lenguaje con seguridad de memoria. Google abrió el código en 2018[1] y lo usa en producción para ejecutar código de clientes en App Engine, Cloud Run y Cloud Functions.

Arquitectura: Sentry, Gofer y modos de plataforma

Cuando un contenedor arranca con runsc, el runtime crea dos procesos principales en el anfitrión:

  • Sentry: el kernel en espacio de usuario que ejecuta el código del contenedor.

  • Gofer: proceso separado que actúa como intermediario para el acceso al sistema de archivos.

Esta separación es deliberada: incluso si un atacante compromete Sentry, todavía tiene que atravesar Gofer para tocar el disco, y ninguno de los dos tiene capacidades privilegiadas más allá de lo estrictamente necesario.

La intercepción de llamadas al sistema usa dos modos principales:

  • ptrace: portable pero lento, rara vez usado en producción.

  • KVM: aprovecha extensiones de virtualización de hardware para rendimiento notablemente mejor, pero requiere /dev/kvm.

  • systrap (la plataforma por defecto desde su lanzamiento en 2023[2]): usa seccomp con filtros de notificación para interceptar llamadas sin depender de KVM ni de ptrace. Buen rendimiento, portable y sin requisitos especiales de hardware.

Un detalle importante: Sentry no implementa todas las llamadas al sistema de Linux. Cubre la mayoría de lo que un programa típico necesita, pero hay llamadas oscuras que fallarán si el contenedor intenta usarlas. Esto es deliberado: cada llamada implementada es superficie de ataque potencial.

Rendimiento: dónde gana y dónde pierde

Para cargas con uso intenso de CPU y poco contacto con el kernel, gVisor está muy cerca de un contenedor nativo: la propia guía de rendimiento del proyecto[3] explica que no hay coste añadido en la ejecución bruta de instrucciones, porque Sentry no emula la CPU. Un banco de pruebas independiente de KubeBlocks[4] con Sysbench midió un sobrecoste de apenas un 4 % frente a runc, prácticamente igual que Kata.

La historia cambia con cargas que hacen muchas llamadas al sistema:

  • El mismo banco de KubeBlocks midió entre un 56 % (plataforma KVM) y un 95 % (plataforma ptrace) de degradación en operaciones de Redis, y un 125 % de sobrecoste en un banco de inserciones de SQLite, frente a un 17 % en Kata.

  • La red también tiene impacto: gVisor trae su propia pila TCP en Go (netstack), y su propia documentación[3] reconoce que los servicios web sencillos, con poco trabajo por petición, notan más el sobrecoste que las cargas que hacen bastante cómputo entre llamadas.

La lección operativa: gVisor es buena opción para APIs HTTP con trabajo real por petición, funciones serverless, trabajos por lotes y ejecución de código no confiable. Es mala opción para bases de datos con escritura constante, servir muchos archivos estáticos pequeños o cualquier carga cuya métrica principal sea IOPS o llamadas al sistema por segundo.

Comparación con Kata Containers y microVMs

La comparación obvia es con Kata Containers[5], que también busca aislamiento reforzado pero arrancando una máquina virtual pequeña con Firecracker o QEMU. Los modelos de amenaza son distintos:

  • Kata apuesta por la barrera de hardware del hipervisor.

  • gVisor apuesta por la reducción de superficie en espacio de usuario.

Kata tiende a mejor compatibilidad con cargas de E/S intensiva porque dentro de la VM corre un kernel Linux completo. gVisor tiende a arrancar más rápido y consumir menos memoria fija por contenedor porque no hay hipervisor completo que cargar. En Cloud Run, donde el arranque en frío importa, la elección de gVisor tiene sentido.

Firecracker por sí solo es un ladrillo de construcción distinto: modelo de amenaza fuerte por la separación de hipervisor, pero operar Firecracker puro implica mucha más integración con el orquestador que runsc, que se enchufa en containerd con pocas líneas de configuración.

Operación y despliegue

Integrar gVisor en un clúster existente es relativamente sencillo:

# Instalación típica en un nodo Debian
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor 
  -o /usr/share/keyrings/gvisor-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) 
  signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] 
  https://storage.googleapis.com/gvisor/releases release main" 
  | sudo tee /etc/apt/sources.list.d/gvisor.list
sudo apt update && sudo apt install -y runsc
sudo runsc install   # añade runsc a containerd
sudo systemctl restart containerd

Después se declara una RuntimeClass en Kubernetes y los Pods que la referencien arrancan con Sentry y Gofer; el resto sigue con runc. Esto permite aplicar gVisor solo a las cargas que lo necesitan sin imponer su coste a todo el clúster. Este patrón de runtime mixto encaja bien con el modelo de containerd con Wasm, donde también se conviven varios runtimes en el mismo nodo.

runsc exporta métricas en formato Prometheus con información de CPU y memoria, y los registros se integran con el stack habitual de logs. El diagnóstico cuando algo falla es más complicado que con runc porque los mensajes pueden venir de Sentry, pero la documentación ha mejorado mucho y hay una comunidad activa.

Cuándo compensa

gVisor tiene un sitio claro: cargas multi-tenant donde el aislamiento importa y el patrón de uso es intensivo en CPU y ligero en E/S.

  • Plataformas que ejecutan código de terceros.

  • Funciones serverless.

  • Entornos de pruebas donde usuarios distintos comparten nodos.

  • Clústeres educativos y laboratorios de análisis de malware.

En todos esos casos la reducción de superficie de ataque compensa de largo el pequeño coste de CPU que se pierde. Muchos operadores usan gVisor para una fracción del clúster, Kata para otra y runc para el resto, eligiendo la barrera que mejor encaja con el nivel de confianza y el perfil de rendimiento de cada carga. Esta heterogeneidad es la respuesta madura a cómo aislar contenedores en entornos con muchos actores. Donde no compensa es en cargas propias de una organización que confía en su propio código: si todos los pods los despliega el mismo equipo con el mismo pipeline, el sandbox extra rara vez justifica el coste operativo. Para esas cargas, las herramientas de observabilidad 2026 y Kubernetes 1.35 ofrecen mejoras de seguridad sin el sobrecoste de sandbox adicional.

Este artículo también está disponible en inglés: gVisor: sandboxing for multi-tenant containers.

Fuentes

  1. abrió el código en 2018
  2. lanzamiento en 2023
  3. guía de rendimiento del proyecto
  4. KubeBlocks
  5. Kata Containers