Virtualización a nivel de sistema operativo

La virtualización a nivel de sistema operativo, también llamada virtualización basada en contenedores, contenerización^[1]​ o contenedorización,^[2]​ es un método de virtualización en el que, sobre el núcleo del sistema operativo, se ejecuta una capa de virtualización que permite que existan múltiples instancias aisladas de espacios de usuario, en lugar de solo uno. Tales instancias, las cuales son llamadas contenedores, contenedores de software, jaulas o prisiones, pueden verse y sentirse como un servidor real desde el punto de vista de sus dueños y usuarios. Al software que permite el alojamiento de distintos contenedores se le llama motor de contenedores. Además de mecanismos de aislamiento, el kernel a menudo proporciona mecanismos de administración de recursos para limitar el impacto de las actividades de un contenedor sobre otros contenedores.

Historia

Como origen de la virtualización a nivel de sistema operativo podemos señalar 1982 con la creación de chroot por parte de Bill Joy. A chroot se le pasan dos parámetros, uno que indica un directorio y el otro el comando a ejecutar. Lo que hace chroot es ejecutar el comando pasado como parámetro impidiendo que él y sus procesos hijos accedan a cualquier ruta fuera del directorio pasado también como parámetro. Se establece lo que se llama jaula chroot. Estas restricciones son relativamente fáciles de superar. ^[3]​ Lo que se persigue es crear una zona con algo más de seguridad donde poder ejecutar un programa del cual se desconfía y que puede presentar un comportamiento peligroso para la integridad del sistema.

En los años 90 Poul-Henning Kamp introduce las llamadas jaulas FreeBSD,^[4]​ a veces simplemente llamadas jaulas BSD. Son el primer ejemplo de virtualización a nivel de sistema operativo. Su objetivo es solventar la limitación de chroot de que sólo limita la parte del sistema de ficheros a la que pueden acceder los procesos dentro de la jaula. El resto de recursos del sistema (conjunto de usuarios del sistema, los procesos en ejecución, el subsistema de red,...) están compartidos entre el sistema alojado y el servidor. Las jaulas BSD extienden este modelo virtualizando no solamente el acceso al sistema de ficheros, sino al conjunto de usuarios, al subsistema de red del kernel de FreeBSD y unas cuantas cosas más.^[5]​ Para ello elimina todos los privilegios de superusuario que podría afectar a objetos que no están enteramente dentro de la jaula.^[4]​ Además cada jaula puede tener su propio conjunto de usuarios e incluso su propio usuario root (limitado al entorno de la jaula no pudiendo realizar operaciones fuera del mismo).^[5]​ Es un sistema más avanzado que crea un entorno virtual prácticamente indistinguible de una máquina real (o máquina virtual real).^[6]​ Tienen como limitación, sin embargo, la obligación de ejecutar la misma versión del núcleo del sistema.^[6]​

De manera prácticamente paralela a las jaulas FreeBSD, aparece Linux VServer un sistema de virtualización para plataformas Linux que también permite aislar los recursos (sistemas de archivos, direcciones de red, memoria,..).^[7]​ Este sistema fue añadido directamente al kernel de Linux en el año 2001. ^[7]​ Posteriormente, también para Linux, se lanzó OpenVZ y su versión comercial Virtuozzo).^[7]​

Dentro de la familia de sistemas operativos Solaris aparece una tecnología equivalente a las jaulas BSD llamada zonas Solaris. La principal diferencia con las jaulas BSD es la baja sobrecarga que le añaden al sistema operativo y el hecho de que se les puedan asignar recursos específicos.^[6]​

En 2002 se introducen en el kernel de linux los namespaces. Estos namespaces permiten particionar los recursos del kernel de modo que un grupo de procesos vea un conjunto de recursos y otro conjunto de procesos vea otro conjunto diferente de recursos. La implementación de namespaces fue mejorándose y ampliándose en versiones sucesivas del kernel.

En el año 2006 Google lanza para plataformas Linux su herramienta Process Containers que fue diseñada para limitar y aislar los accesos a recursos de la máquina como CPU, memoria, I/O de disco, red, etc., por parte de un grupo de procesos. Este proyecto fue renombrado posteriormente al nombre Grupos de control o simplemente cgroups en 2007 y finalmente se fusionó con el kernel de Linux.^[7]​

Unos años más tarde nace para plataformas Linux el sistema LinuX Containers (LXC).^[7]​ Este sistema, apoyándose sobre namespaces y cgroups que ofrece el kernel de Linux, consiguió la primera implementación estable de un gestor de contenedores sobre Linux.^[7]​ Sobre LXC se ha construido LXD, un administrador de contenedores del sistema que proporciona una mejor experiencia de usuario. LXD ofrece un servicio similar a una máquina virtual en el sentido de que ofrece al usuario un sistema operativo completo con interfaces de red y almacenamiento pero, en este caso, con ciertas restricciones de acceso.^[8]​

Entre 2011 y 2013 surgen diversas tecnologías de gestión de contenedores como Warden, LMCTFY (siglas de Let Me Contain That For You) y Docker.^[7]​ Warden desarrolló el primer modelo cliente-servidor para administrar contenedores distribuidos en diferentes equipos. ^[7]​ LMCTFY permitía que las aplicaciones propiamente dichas tuvieran capacidad para controlar el contenedor, administrando sus propios subcontenedores o contenedores hijos.^[7]​ En 2013 surge Docker, el cual permite gestionar el ciclo de vida de los contenedores de forma sencilla en comparación con la herramientas anteriores.^[9]​ Esto provoca que Docker, y por tanto los contenedores, se empiecen a usar de forma masiva.^[7]​

La gran ventaja de Docker es que está orientado a empaquetar dentro de los contenedores aplicaciones aisladas entre sí,^[8]​ con todas las funcionalidades que necesitan para ser ejecutadas permitiendo integrarlas en los flujos de integración/distribución continua.^[9]​ De esta forma obtiene una cadena unificada desde el desarrollo de aplicaciones hasta su puesta en producción. Teniendo un modelo de único despliegue de las aplicaciones, consigue reducir los tiempos de configuración, los tiempos de despliegue,… y mejorando, en ese sentido, el tiempo de puesta en producción de las aplicaciones. ^[9]​ De esta manera independientemente del entorno en el que ejecutemos el contenedor (local, desarrollo o entornos productivos) siempre nos vamos a asegurar que se ejecuta de la misma manera.^[9]​ Para ello usa instantáneas de un contenedor, a las que llama imágenes,^[10]​ que se ejecutan instanciándolas en lo que ya sería el contenedor.^[9]​ Podremos crear tantas instancias de una imagen como queramos y en los entornos que queramos.^[9]​ Típicamente se tienen contenedores mínimos efímeros, sin estado, que normalmente no se actualizan o reconfiguran, sino que simplemente se reemplazan por completo.^[11]​ Si queremos datos persistentes se montan rutas del sistema subyacente en los contenedores por ejemplo usando los llamados volúmenes.^[12]​

Inicialmente Docker usó como entorno de ejecución por defecto LXC, sin embargo más tarde fue reemplazado por libcontainer.^[7]​^[13]​ De esta forma consiguió poder ser usado con otras tecnologías de aislamiento distintas a LXC y poder acceder directamente a las APIs del kernel del sistema operativo y así poder reducir las dependencias de librerías y aumentar la eficiencia del sistema.^[13]​ Sobre libcontainer Docker creó runC, un motor de contenedores ligero de línea de comandos^[14]​^[15]​

Aunque Docker sigue siendo, con diferencia, la solución más usada, durante estos últimos años han surgido otras alternativas como:^[7]​^[16]​^[17]​^[18]​

• rkt (antes llamado Rocket). Creado por Container Linux para proporcionar más seguridad e interoperabilidad. No obligaba a ejecutar todo como root, no tenía demonios, estaba controlado por línea de comandos CLI, y tenía comodidades como verificación criptográfica y compatibilidad completa con imágenes de Docker.^[19]​ Docker fue ganando popularidad y rkt finalmente fue abandonado.^[19]​
• Apache Mesos. Permite ejecutar frameworks sobre los cuales se ejecuta la aplicación y está especialmente orientado a entornos de Big Data^[20]​
• Windows Server Container. Las instancias de los contenedores se ejecutan a la vez sobre el mismo núcleo del anfitrión. ^[21]​
• Hyper V Container Los contenedores no comparten el mismo núcleo sino que se aísla entre cada uno utilizando la tecnología de virtualización Hyper-V.^[21]​

En 2015 se funda la Open Container Initiative (OCI), una asociación de instituciones y empresas asociadas para diseñar estándares abiertos sobre virtualización a nivel de sistema operativo para, de esta forma, asegurar que las plataformas de contenedores no estén vinculadas a ninguna empresa o proyecto concreto.^[22]​

En 2016 el más importante orquestador de contenedores Kubernetes propuso Container Runtime Interface como la interfaz (API) para los motores de ejecución de contenedores, para de esta manera proponer una forma de conectarse a otros motores de ejecución distintos de Docker.^[23]​^[24]​ De esta forma podía integrarse con múltiples motores de ejecución de manera transparente.^[24]​ Poco a poco empezaron a salir motores de ejecución que cumplían la especificación de forma nativa y que a la vez soportaban las imágenes Docker.^[24]​^[23]​ Por ejemplo cri-o (por debajo utiliza típicamente runC o crun como motor de contenedores de bajo nivel, ambas implementaciones OCI^[19]​ siendo crun más ligera^[25]​) y cri-containerd (plugin añadido a containerd, el motor de ejecución de alto nivel de Docker y que por debajo utiliza típicamente runC^[19]​).^[24]​^[23]​ Sin embargo, Docker no cumplía CRI (aunque desde la versión uliliza ContainerD de forma interna) y por eso se desarrolló el componente docker-shim que hacía de interlocutor entre las dos partes para que sea posible utilizar Docker dentro de Kubernetes.^[24]​ En diciembre de 2020 Kubernetes anunció que deprecaba el soporte a Docker en la próxima versión, y que en futuras versiones solo estarían disponibles los motores de ejecución de contenedores que cumplieran CRI de manera nativa.^[24]​^[23]​

Usos

Escenarios típicos de uso de la virtualización a nivel de sistema operativo son:

• En ambientes de alojamiento virtual, permiten distribuir recursos de hardware finitos de forma segura entre un número grande de usuarios mutuamente desconfiados.
• Administradores de sistema lo usan para ahorrar hardware, moviendo servicios que se encuentran en servidores distintos hacia un mismo servidor.
• Permiten la separación de varias aplicaciones en contenedores distintos para mejorar la seguridad, independencia de hardware y brindar mecanismos de administración de recurso adicionales. La mejora de seguridad proporcionada, aun así, no es de ninguna forma infalible.
• Las implementaciones de virtualización a nivel de sistema operativo capaces de hacer migraciones en vivo pueden ser utilizadas para realizar balanceo de carga dinámico de contenedores entre nodos en un grupo.

Características

Sobrecarga

La virtualización a nivel de sistema operativo normalmente impone poca o ninguna sobrecarga, porque los programas en particiones virtuales utilizan la interfaz de llamada de sistema normal del sistema operativo y no necesitan de emulación o ser ejecutados en una máquina virtual intermedia, como es el caso con virtualizadores a sistema completo (como VMware ESXi, QEMU o Hyper-V) y paravirtualizadores (como Xen o UML). Esta forma de virtualización además no requiere soporte en hardware para actuar eficientemente.

Flexibilidad

La virtualización a nivel de sistema operativo no es tan flexible como otros enfoques de virtualización porque no puede hospedar un sistema operativo diferente del anfitrión o un kernel distinto. Por ejemplo, con Linux, no hay problemas con las distribuciones diferentes, pero otros sistemas operativos como Windows no puede ser virtualizados.

Solaris vence parcialmente la limitación descrita anteriormente con su característica de zonas marcadas, la cual proporciona la capacidad de ejecutar un entorno dentro de un contenedor que emula un Solaris versión 8 o 9 en un Solaris 10 anfitrión. Las zonas marcadas de Linux también están disponibles en sistemas Solaris basados en x86, proporcionando un espacio de usuario de Linux completo y soporte para la ejecución de aplicaciones de Linux; además, Solaris proporciona las herramientas necesarias para instalar otras distribuciones de Linux como Red Hat Enterprise Linux 3.x o CentOS 3.x dentro de zonas marcadas de Linux.^[26]​^[27]​ Sin embargo, en 2010 las zonas marcadas de Linux fueron eliminadas de Solaris; en 2014 eran reintroducidas en Illumos, la rama de código abierto de Solaris, brindando soporte a los kernels de Linux de 32-bits.^[28]​

Almacenamiento

Algunas implementaciones de virtualización a nivel de sistema operativo proporcionan mecanismos copy-on-write a nivel de archivos. (En la mayoría de los casos, un sistema de ficheros estándar es compartido entre particiones, y aquellas particiones que cambian los archivos automáticamente crean sus propias copias). Con este sistema es más sencillo realizar copias de seguridad, además, hace un uso más eficiente del espacio en disco y resulta más sencillo de guardar en caché que los esquemas copy-on-write a nivel de bloque, comunes en virtualizadores a sistema completo. Los virtualizadores a sistema completo, sin embargo, pueden trabajar con sistemas de archivos no nativos y crear y restaurar copias del estado actual completo del sistema.

Tipos

Podemos clasificar los sistemas de virtualización de sistemas operativos según el tipo de servicios que ofrecen en:^[29]​^[11]​^[30]​

• Contenedores de infraestructura o sistema de contenedores. Ofrecen un servicio que permite ejecutar múltiples instancias de sistemas operativos de manera aislada. Ofrece todo lo necesario para que el sistema “contenido” pueda trabajar, tales como CPU, network, I/O. Es similar a una máquina virtual pero más rápido y ligero. Ejemplos de estos sistemas son LXC y LXD.
• Contenedores de procesos o Contenedores de aplicaciones. Ofrecen un sistema para empaquetar aplicaciones y todas sus dependencias y, por tanto, son muy útiles para el desarrollo y distribución de aplicaciones. Por ejemplo, en integración continua es habitual desarrollar con contenedores para eliminar las diferencias de entorno entre producción y desarrollo y facilitar la migración del entorno. Este tipo de contenedores son muy usados en la computación en la nube para distribuir las aplicaciones. Ejemplos de estos sistemas son Docker y systemd-nspawn. Típicamente se tienen contenedores mínimos efímeros, sin estado, que normalmente no se actualizan o reconfiguran, sino que simplemente se reemplazan por completo.^[11]​
• Contenedores sandbox. Enfocados en proveer aislamiento mediante un entorno que permita ejecutar contenedores en un espacio escapsulado donde tiene acceso restringido a recursos del sistema operativo o datos del usuario (sandbox). Ejemplos de estos sistemas son Firejail,^[31]​ nsroot,^[32]​ nsjail,^[32]​ FreeBSD jail, sandboxie^[33]​ y Bubblewrap.

El que un sistema esté más enfocado en proveer un tipo de servicio no quiere decir que no pueda proveer el otro. Por ejemplo Docker es un contenedor de aplicaciones pero permite proporcionar espacio aislado. Sin embargo al ser un software bastante grande y con muchas funciones, expande la superficie de ataque innecesariamente y por tanto, no es la mejor forma para proporcionar espacio aislado.^[34]​

Además se pueden combinar, por ejemplo se puede usar LXD para proporcionar sistemas Linux completos a sus usuarios que luego pueden instalar Docker dentro de su contenedor LXD para ejecutar el software que desean.^[11]​

Comparación con la virtualización de plataforma

Comparado con la virtualización de plataforma, la virtualización a nivel de sistema operativo:^[6]​^[35]​

• Es mucho más ligera. Puede llegar a tener un rendimiento en la ejecución muy próximo al nativo reduciendo, por ejemplo, el consumo de memoria por servidor virtual u optimizando su entrada y salida debido a que un solo kernel controla el acceso a los dispositivos y recursos. Esta ligereza permite un tiempo de arranque más reducido, y que la misma máquina permita admitir más contenedores que máquinas virtuales
• No requiere un hipervisor para funcionar
• No requiere ningún mecanismo hardware.
• Permite un mayor control desde fuera (desde el anfitrión) del que se pueda tener usando máquinas virtuales.
• El soporte de contenedores implica que haya que realizar diversas modificaciones en el kernel del sistema operativo anfitrión, sobre todo para hacer creer a los contenedores que son ejecutadas en un entorno exclusivo.
• Al compartir el mismo núcleo con el servidor físico anfitrión:
  • Un fallo en el kernel puede provocar la caída de la totalidad de los contenedores alojados (único punto de fallo).
  • Por lo general, los contenedores no pueden correr sistemas operativos que difieran del instalado en el sistema anfitrión, aunque en algunos casos es posible que ejecuten diferentes versiones de la misma distribución o incluso distintas distribuciones Linux. Por ejemplo, FreeBSD jails permite ejecutar diferentes versiones de FreeBSD sobre un único kernel FreeBSD, por lo tanto permitiendo tener diferentes versiones de aplicaciones, procesos, librerías, etc. Otro ejemplo: Linux V-Server, FreeVPS y OpenVZ pueden ejecutar diferentes distribuciones Linux en los servidores virtuales, aunque siempre compartiendo el mismo kernel. Con docker en Windows se pueden ejecutar contenedores Linux gracias a la capa de compatibilidad WSL que permite ejecutar ejecutables de Linux nativamente en Windows.^[36]​
  • Las librerías, herramientas, utilidades,... que ejecuten los servidores virtuales deben estar compilados para el mismo juego de instrucciones y hardware que utiliza el sistema operativo anfitrión.

• Mayor portabilidad Las aplicaciones que se ejecutan en contenedores se pueden poner en marcha fácilmente en sistemas operativos y plataformas de hardware diferentes. Funcionamiento más constante • Los equipos de DevOps saben que las aplicaciones en contenedores van a ejecutarse igual, independientemente de dónde se pongan en marcha. • Mayor eficiencia Los contenedores permiten poner en marcha, aplicar parches o escalar las aplicaciones con mayor rapidez. • Mejor desarrollo de aplicaciones Los contenedores respaldan los esfuerzos ágiles y de DevOps para acelerar los ciclos de desarrollo, prueba y producción.

Orquestadores de contenedores

Las herramientas que realizan orquestación de contenedores, llamados Orquestadores de contenedores son herramientas que dirigen el comportamiento de los contenedores pudiendo automatizar el despliegue, la gestión y el escalado de las aplicaciones basadas en contenedores.^[7]​ Estas herramientas son necesarias en entornos en los que tenemos que manejar un sistema con muchos contenedores, que dan distintos servicios (base de datos, servidor web, métricas, la propia aplicación, ...) y desplegados sobre distintos servidores. ^[7]​^[37]​ Estos contenedores atienden una demanda determinada que tiene que ser satisfecha por unos recursos los cuales se tienen que escalar, actualizar, etc. sin repercutir en el usuario de la aplicación.^[7]​ Por tanto hay que controlar y dirigir la creación de contenedores, verificar su correcta ejecución, gestionar los errores,...^[37]​

Ejemplos de orquestadores de contenedores son docker-compose, Docker Swarm, Rancher y Kubernetes.^[7]​ Algunos gestores de contenedores como Apache Mesos aportan sus propios mecanismos de orquestación y no necesitan un herramienta externa para realizar esa tarea.

Contenedores y sistemas distribuidos

Un Sistema distribuido es aquel en el que los componentes, localizados en la red se comunican y coordinan sus acciones mediante el envío de mensajes. Los Sistemas Distribuidos permiten que los recursos de la red no se encuentren centralizados en una sola máquina, pudiendo estar en varias, e incluso en lugares diferentes. Como se mencionó anteriormente, los contenedores son una forma de virtualización del sistema operativo. Estos pueden llegar a utilizarse para ejecutar cualquier cosa, desde un micro servicio hasta una aplicación de mayor nivel. La manera más sencilla de relacionarlos es tomando en cuenta que si el objetivo de los sistemas distribuidos es no centralizar los recursos en una sola máquina, los contenedores hacen más sencilla esta distribución, al requerir menos recursos que un sistema operativo completo, facilitar una mayor portabilidad al usuario, ya que como se mencionó, las aplicaciones que se ejecutan en estos se pueden poner en operación de manera más sencilla y rápida que en un sistema operativo. Otro punto fuerte es que se puede poner a operar en plataformas de hardware diferentes, facilitando aún más lo que se busca con los sistemas distribuidos.

¿Cuál es la relación que docker y kubernetes tienen con los contenedores?

Docker es un popular entorno en tiempo de ejecución que se usa para crear y construir software dentro de contenedores. Usa imágenes de Docker (instantáneas de copia en escritura) para poner en marcha aplicaciones o software en contenedores en varios entornos, desde el desarrollo hasta las pruebas y la producción. Docker se basa en estándares abiertos y funciona en la mayoría de los entornos operativos más comunes, incluidos Linux, Microsoft Windows y otras infraestructuras locales o basadas en la nube.

Sin embargo, las aplicaciones en contenedores pueden ser complicadas. Durante la producción, muchas pueden requerir cientos o miles de contenedores independientes. Es en este punto donde los entornos en tiempo de ejecución de contenedores, como Docker, se benefician del uso de otras herramientas para orquestar o gestionar todos los contenedores en funcionamiento.

Una de las herramientas más populares para este fin es Kubernetes, un orquestador de contenedores que reconoce varios entornos en tiempo de ejecución de contenedores, incluido Docker.

Kubernetes orquesta el funcionamiento de varios contenedores juntos de forma armónica. Gestiona áreas como el uso de recursos de infraestructura subyacentes para aplicaciones en contenedores (por ejemplo, la cantidad de recursos de computación, red y almacenamiento necesarios). Las herramientas de orquestación como Kubernetes facilitan la automatización y el escalado de cargas de trabajo basadas en contenedores para entornos de producción activos.

Implementaciones

A continuación se muestra tabla con algunas implementaciones de motores de contenedores:

Mecanismo	Sistema operativo	Licencia	Disponible desde o entre	Características
				Aislamiento de sistema de ficheros	Copy-on-write	Cuotas de disco	Límite de entrada/salida	Límites de memoria	Cuotas de CPU	Aislamiento de red	Virtualización anidada	Puntos de control de particiones y migraciones en vivo	Aislamiento de privilegios de administración
chroot	La mayoría de los sistemas operativos estilo Unix	Cambia de acuerdo al sistema operativo	1982	Parcial^[39]​	No	No	No	No	No	No	Sí	No	No
Docker	Linux^[40]​	Licencia Apache 2.0	2013	Sí	Sí	No directamente	Sí (desde la versión 1.10)	Sí	Sí	Sí	Sí	No	Sí (desde la versión 1.10)
Linux-VServer (contexto de seguridad)	Linux, Windows Server 2016	GNU GPLv2	2001	Sí	Sí	Sí	Sí^[41]​	Sí	Sí	Parcial^[42]​	?	No	Partial^[44]​
lmctfy	Linux	Licencia Apache 2.0	2013	Sí	Sí	Sí	Sí^[41]​	Sí	Sí	Parcial^[42]​	?	No	Partial^[44]​
LXC	Linux	GNU GPLv2	2008	Sí^[45]​	Sí	Parcial	Parcial^[46]​	Sí	Sí	Sí	Sí	No	Sí^[45]​
LXD^[47]​	Linux	Licencia Apache 2.0	2015	Sí	Sí	Parcial (ver LXC)	Parcial (ver LXC)	Sí	Sí	Sí	Sí	Parcial^[49]​	Sí
OpenVZ	Linux	GNU GPLv2	2005	Sí	Sí (ZFS)	Sí	Sí^[51]​	Sí	Sí	Sí^[52]​	Parcial^[54]​	Sí	Yes^[56]​
Virtuozzo	Linux, Windows	Propietaria	2000^[57]​	Sí	Sí	Sí	Sí^[58]​	Sí	Sí	Sí^[52]​	Parcial^[60]​	Sí	Sí
Contenedores Solaris (Zones)	illumos (OpenSolaris), Solaris	CDDL, Propietaria	2004	Sí	Sí (ZFS)	Sí	Parcial^[62]​	Sí	Sí	Sí^[63]​^[64]​^[65]​	Parcial^[66]​	Parcial^[67]​^[68]​	Yes^[70]​
Prisión FreeBSD	FreeBSD	Licencia BSD	2000^[71]​	Sí	Sí (ZFS)	Sí^[72]​	Sí	Sí^[73]​	Sí	Sí^[74]​	Sí	Parcial^[75]​^[76]​	Sí^[77]​
sysjail	OpenBSD, NetBSD	Licencia BSD	2006–2009	Sí	No	No	No	No	No	Sí	No	No	?
WPARs	AIX	Propietaria	2007	Sí	No	Sí	Sí	Sí	Sí	Sí^[79]​	No	Sí^[80]​	?
HP-UX Containers (SRP)	HPUX	Propietaria	2007	Sí	No	Parcial^[81]​	Sí	Sí	Sí	Sí	?	Sí	?
Cuentas virtuales de iCore	Windows XP	Propietaria: Freeware	2008	Sí	No	Sí	No	No	No	No	?	No	?
Sandboxie	Windows	Propietaria: Freeware	2004	Sí	Sí	Parcial	No	No	No	Parcial	No	No	Sí
Spoon	Windows	Propietaria	2012	Sí	Sí	No	No	No	No	Sí	No	No	Sí
systemd-nspawn	Linux	GNU LGPLv2.1+	2010	Sí	Sí	Sí^[82]​^[83]​	Sí^[82]​^[83]​	Sí^[82]​^[83]​	Sí^[82]​^[83]​	Sí	?	?	Sí
VMware ThinApp	Windows	Propietaria	2008	Sí	Sí	No	No	No	No	Sí	No	No	Sí

Véase también

• Virtualización
• CoreOS
• Hypervisor
• Servidor Virtual Privado (VPS)

Notas

Referencias

1. Virtualización basada en contenedores y SD-WAN. Guillermo Lopez. teldat.com. 3 octubre 2018
2. La contenerización de aplicaciones. Hector Gil. plotandesign.com. 28 de marzo de 2019
3. . 2002. Archivado desde el original el 22 de septiembre de 2013. Consultado el 7 de mayo de 2013. 
4. Building Systems to be Shared Securely. POUL-HENNING KAMP y ROBERT WATSON. ACM QUEUE Julio/Agost de 2004
5. Capítulo 15. Jaulas. Manual de FreeBSD. 1995-2010
6. Virtualización ligera usando contenedores: Introducción. Material docente para la asignatura Infraestructura Virtual. JJ Merelo. Universidad de Granada.
7. Personalización de entorno de desarrollo y despliegue sobre contenedores. Carlos Rodríguez Hernández. Trabajo Fin de Grado en Ingeniería de las Tecnologías de Telecomunicación. Universidad de Sevilla 2019
8. LXD vs Docker. Ranvir Singh. 2017
9. ¿Qué es Docker?. Víctor Cuervo. 26 de noviembre de 2019.
10. Trabajando con imágenes en Docker. Marcos Saiz. 2019
11. LXD 2.0: Introduction to LXD 1/12. Stéphane Graber. 11 de marzo de 2016
12. Volúmenes y datos persistentes en Docker. Pablo. 2 de enero de 2019
13. LXC vs. libcontainer. Anusheh Zohair Mustafeez
14. runC: The little container engine that could. Phil Estes. 15 de agosto de 2016
15. What’s Running My Containers? A review of runtimes & standards. Phil Estes
16. Una guía no tan rápida de Docker y Kubernetes. Mauricio Collazos. 19 de junio de 2018
17. Virtualización con contenedores Docker: alternativas. ionos.es. 9 de julio de 2019
18. 5 Container Alternatives to Docker. Bill Doerrfeld. 22 de enero de 2019
19. A Comprehensive Container Runtime Comparison. Evan Baker. 10 de junio de 2020
20. Apache Mesos. Viviana. 23 de julio de 2018
21. Containers con Windows Server 2016. Josep Ma Solanes. 5 de abril de 2016
22. Open Container Initiative. searchitoperations.techtarget.com. Noviembre de 2015
23. ¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker. ecardenas. 3 de diciembre de 2020
24. Kubernetes ha deprecado Docker. Iñigo Telleria 4 de diciembre de 2020
25. An introduction to crun, a fast and low-memory footprint container runtime. Dan Walsh et ali. 3 de agosto de 2020
26. «System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones, Chapter 16: Introduction to Solaris Zones». Oracle Corporation. 2010. Consultado el 2 de septiembre de 2014. 
27. «System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones, Chapter 31: About Branded Zones and the Linux Branded Zone». Oracle Corporation. 2010. Consultado el 2 de septiembre de 2014. 
28. Bryan Cantrill (28 de septiembre de 2014). «The dream is alive! Running Linux containers on an illumos kernel». slideshare.net. Consultado el 10 de octubre de 2014. 
29. Introducción a contenedores Docker. José David. 28 de septiembre de 2016
30. Bubblewrap.
31. Firejail: Putting a program in its own little container. Eli Billauer.11 de junio de 2020
32. nsroot: Minimalist Process Isolation Tool Implemented With Linux Namespaces. Inge Alexander Raknes, Bjørn Fjukstad y Lars Ailo Bongo. University of Tromsø]
33. Sandbox. cortafuegos.net
34. Sandbox your applications with Firejail. nachoparker. 29 de octubre de 2017
35. Virtualización de servidores de telefonía IP en GNU/LINUX. Introducción a la virtualización. Eugenio Villar y Julio Gómez. Universidad de Almería. Junio de 2010
36. Cómo desarrollar con Docker en Linux dentro de Windows sin arranque dual – WSL 2. Henrique Marques Fernandes. 18 de junio de 2020
37. Comparativa de orquestadores: Docker Swarm vs Kubernetes vs Apache Mesos. Carlos Iván Morales Terrer. 21 de marzo de 2019
38. «3.5. Limiting your program's environment». freebsd.org. 
39. Root user can easily escape from chroot. Chroot was never supposed to be used as a security mechanism.^[38]​
40. «Docker drops LXC as default execution environment». InfoQ. 
41. Utilizing the CFQ scheduler, there is a separate queue per guest.
42. Networking is based on isolation, not virtualization.
43. Linux-VServer Paper, Secure Capabilities
44. A total of 14 user capabilities are considered safe within a container. The rest may cannot be granted to processes within that container without allowing that process to potentially interfere with things outside that container.^[43]​
45. Graber, Stéphane (1 de enero de 2014). «LXC 1.0: Security features [6/10]». Consultado el 12 de febrero de 2014. «LXC now has support for user namespaces. [...] LXC is no longer running as root so even if an attacker manages to escape the container, he’d find himself having the privileges of a regular user on the host ». 
46. I/O rate limiting is supported when using Btrfs.
47. Kouka, Abdelmonam (2015). Ubuntu Server Essentials. Packt Publishing Ltd. p. 124. ISBN 9781785282768. Consultado el 31 de marzo de 2016. «Also known as the Linux container hypervisor, LXD is the next-generation hypervisor provided by Canonical. It combines the density of containers with the manageability of virtual machines. » 
48. «Live Migration in LXD». Ubuntu Insights Web site. 
49. In progress: Works on non-systemd OS^[48]​
50. «I/O priorities for containers». OpenVZ Virtuozzo Containers Wiki. 
51. Available since Linux kernel 2.6.18-028stable021. Implementation is based on CFQ disk I/O scheduler, but it is a two-level schema, so I/O priority is not per-process, but rather per-container.^[50]​
52. Each container can have its own IP addresses, firewall rules, routing tables and so on. Three different networking schemes are possible: route-based, bridge-based, and assigning a real network device (NIC) to a container.
53. «Docker inside CT». 
54. Docker containers can run inside OpenVZ containers.^[53]​
55. «Container». OpenVZ Virtuozzo Containers Wiki. 
56. Each container may have root access without possibly affecting other containers.^[55]​
57. «Initial public prerelease of Virtuozzo (named ASPcomplete at that time)». 
58. Available since version 4.0, January 2008.
59. «Parallels Virtuozzo Now Provides Native Support for Docker». 
60. Docker containers can run inside Virtuozzo containers.^[59]​
61. Pijewski, Bill. «Our ZFS I/O Throttle». 
62. Yes with illumos^[61]​
63. See OpenSolaris Network Virtualization and Resource Control for more details.
64. Network Virtualization and Resource Control (Crossbow) FAQ el 1 de junio de 2008 en Wayback Machine.
65. «Managing Network Virtualization and Network Resources in Oracle® Solaris 11.2». 
66. Only when top level is a KVM zone (illumos) or a kz zone (Oracle).
67. Starting in Solaris 11.3 Beta, Solaris Kernel Zones may use live migration.
68. Cold migration (shutdown-move-restart) is implemented.
69. Oracle Solaris 11.1 Administration, Oracle Solaris Zones, Oracle Solaris 10 Zones and Resource Management E29024.pdf, pp. 356–360. Available within an archive.
70. Non-global zones are restricted so they may not affect other zones via a capability-limiting approach. The global zone may administer the non-global zones.^[69]​
71. «Contain your enthusiasm - Part Two: Jails, Zones, OpenVZ, and LXC». «Jails were first introduced in FreeBSD 4.0 in 2000 ». 
72. Check the "allow.quotas" option and the "Jails and File Systems" section on the FreeBSD jail man page for details.
73. «Hierarchical_Resource_Limits - FreeBSD Wiki». Wiki.freebsd.org. 27 de octubre de 2012. Consultado el 15 de enero de 2014. 
74. «Implementing a Clonable Network Stack in the FreeBSD Kernel». usenix.org. 13 de junio de 2003. 
75. «VPS for FreeBSD». Consultado el 20 de febrero de 2016. 
76. «[Announcement] VPS // OS Virtualization // alpha release». Consultado el 20 de febrero de 2016. 
77. «3.5. Limiting your program's environment». Freebsd.org. Consultado el 15 de enero de 2014. 
78. «IBM Fix pack information for: WPAR Network Isolation - United States». ibm.com. 
79. Available since TL 02.^[78]​
80. Live Application Mobility in AIX 6.1
81. Yes with logical volumes.
82. https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--property=
83. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/sec-modifying_control_groups

•   Datos: Q2079320