Nanos – Un unikernel

Beneficios percibidos y casos de uso

• Nanos se considera una buena opción para:
  • Cargas de trabajo en la nube de alto rendimiento y baja variabilidad, y HPC.
  • Pedagogía, investigación de SO/sistemas/arquitectura de CPU.
  • Sistemas embebidos que necesitan un modelo de procesos similar al de Linux.
• Principales ventajas citadas:
  • Imagen de SO muy pequeña, de propósito único, con una superficie de ataque reducida.
  • Mayor rendimiento (los benchmarks muestran ~1.6x frente a Linux para contenido estático).
  • Modelo mental: “tu app + kernel mínimo + hipervisor”, nada más.

Arquitectura, bare metal y sistemas de archivos

• Nanos está diseñado explícitamente para ejecutarse como una VM sobre un hipervisor, no sobre bare metal arbitrario.
• Está orientado a entornos paravirtualizados (p. ej., dispositivos KVM), evitando controladores de hardware diversos.
• Sí tiene sistemas de archivos; lo que falta es un userland interactivo multiusuario.

Depuración, registros y preocupaciones operativas

• Varios comentaristas tienen dificultades con la ausencia de un shell y de herramientas tradicionales dentro de la imagen.
• Normalmente los registros se exportan mediante syslog o logging en la nube (p. ej., CloudWatch), de forma similar a las prácticas de Kubernetes.
• Algunos temen un entorno “anémico” cuando algo sale mal; otros sostienen que los logs remotos y los depuradores conectables son suficientes.
• Se elogia la documentación por el detalle sobre Nanos en sí, pero se critica que la guía sobre administración, despliegue y pruebas sea escasa.

Despliegue, orquestación e integración con la nube

• El CLI ops puede construir imágenes y lanzar VMs en AWS; hay un proveedor de Terraform y ejemplos.
• La estrategia es depender de primitivas de la nube (ELB, ASGs, servicios de almacenamiento) en lugar de replicar una orquestación al estilo Kubernetes.
• ops no es un sistema de orquestación; para despliegues grandes se sugiere Terraform o herramientas de nube.
• Existe confusión en torno a la configuración en tiempo de ejecución (p. ej., variables de entorno) frente a incrustar la configuración en las imágenes.

Comparación con contenedores, Alpine y Kubernetes

• Muchos señalan que Alpine + contenedores “ganó” por la madurez del ecosistema, la familiaridad y la orquestación (Kubernetes).
• Los contenedores se consideran “suficientemente buenos” para aislamiento y rendimiento, y más fáciles de depurar (shell, instalación de paquetes).
• Algunos argumentan que los unikernels eliminan un SO multiusuario completo y funciones innecesarias del kernel; otros ven pérdida de comodidad y de transferencia de habilidades.

Discusión de seguridad

• Los defensores enfatizan que las VMs proporcionan un límite de aislamiento fuerte; los contenedores no, como muestran los frecuentes escapes de contenedores.
• Ejecutar unikernels bajo Kubernetes se dice que reduce los beneficios de seguridad porque reaparecen las capas de Linux/contenedores.
• Se critica la instalación mediante curl | sh y checksums MD5 por irresponsable; los críticos piden compilaciones firmadas y reproducibles, y verificación multiparte. Los representantes del proyecto señalan opciones alternativas de descarga, pero las preocupaciones persisten.

Lenguaje, investigación y verificación

• Se expresa el deseo de un unikernel basado en Rust; otros defienden C por su estabilidad y simplicidad cuando está cuidadosamente escrito.
• Nanos es agnóstico al lenguaje y, según se informa, se usa con aplicaciones Rust.
• Ecosistema más amplio de unikernels: menciones de MirageOS y de sus componentes parcialmente derivados formalmente.
• Algunos piensan que la investigación en SO se ha desacelerado, pero aún ven grandes problemas abiertos en distribución, seguridad y en replantear la “capa bajo la nube”.

Ecosistema y herramientas

• Tres componentes principales generan confusión:
  • nanos.org: el kernel/la tecnología.
  • nanovms.com: la empresa/productos.
  • ops.city: paquetes y el CLI ops.
• El modelo de empaquetado se compara con Docker: los paquetes base (p. ej., nginx) se amplían mediante configuración (archivos/directorios/mapeos); los usuarios ya están publicando sus propios paquetes.
• Se debate la estrategia de espacio comunitario (sin chat oficial vs deseo de un espacio central, buscable y respetuoso con la privacidad).