8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre

Virtualización a nivel de sistema operativo

La virtualización a nivel de sistema operativo, también llamada virtualización basada en contenedores, contenerización1 ​ 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.

Índice
Historia
Usos
Características
Sobrecarga
Flexibilidad
Almacenamiento
Tipos
Comparación con la virtualización de plataforma
Orquestadores de contenedores
Contenedores y sistemas distribuidos
¿Cuál es la relación que docker y kubernetes tienen con los contenedores?
Implementaciones
Véase también
Notas
Referencias

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
https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo 1/7
8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre
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 comandos14 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 Data20 ​
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 OCI19 ​ siendo crun más ligera25 ​) 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 runC19 ​).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

https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo 2/7
8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre
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, sandboxie33 ​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 ​

https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo 3/7
8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre
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:

https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo 4/7
8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre

Características

Disponible
Sistema Aislamiento Copy- Límites Cuotas
Mecanismo Licencia desde o Cuotas de Límite de A
operativo de sistema on- de de
entre disco entrada/salida
de ficheros write memoria CPU

La mayoría de
los sistemas Cambia de acuerdo al
chroot
operativos sistema operativo
1982  Parcial39 ​  No  No  No  No  No
estilo Unix
 No  Sí (desde la
Docker Linux40 ​ Licencia Apache 2.0 2013  Sí  Sí  Sí  Sí
directamente versión 1.10)
Linux-VServer Linux,
(contexto de Windows GNU GPLv2 2001  Sí  Sí  Sí  Sí41 ​  Sí  Sí
seguridad) Server 2016

lmctfy Linux Licencia Apache 2.0 2013  Sí  Sí  Sí  Sí41 ​  Sí  Sí

LXC Linux GNU GPLv2 2008  Sí45 ​  Sí  Parcial  Parcial46 ​  Sí  Sí

 Parcial  Parcial (ver

LXD47 ​ Linux Licencia Apache 2.0 2015  Sí  Sí  Sí  Sí
(ver LXC) LXC)
 Sí
OpenVZ Linux GNU GPLv2 2005  Sí
(ZFS)
 Sí  Sí51 ​  Sí  Sí

Linux,
Virtuozzo
Windows
Propietaria 200057 ​  Sí  Sí  Sí  Sí58 ​  Sí  Sí

Contenedores illumos
 Sí
Solaris (OpenSolaris), CDDL, Propietaria 2004  Sí  Sí  Parcial62 ​  Sí  Sí
(ZFS)
(Zones) Solaris

Prisión  Sí
FreeBSD
FreeBSD Licencia BSD 200071 ​  Sí  Sí72 ​  Sí  Sí73 ​  Sí
(ZFS)

OpenBSD,  No  No  No  No  No

sysjail Licencia BSD 2006–2009  Sí
NetBSD

WPARs AIX Propietaria 2007  Sí  No  Sí  Sí  Sí  Sí

HP-UX
Containers
(SRP) (http:// HPUX Propietaria 2007  Sí  No  Parcial81 ​  Sí  Sí  Sí
www.hp.com/
go/containers)
Propietaria:
Cuentas
virtuales de Windows XP 2008  Sí  No  Sí  No  No  No
iCore
Freeware

Propietaria:
Sandboxie Windows 2004  Sí  Sí  Parcial  No  No  No
Freeware

Spoon Windows Propietaria 2012  Sí  Sí  No  No  No  No

systemd-  Sí82 ​
nspawn
Linux GNU LGPLv2.1+ 2010  Sí  Sí  Sí82 83
​ ​  Sí82 83
​ ​  Sí82 83
​ ​ 83 ​

VMware  No  No  No  No

Windows Propietaria 2008  Sí  Sí
ThinApp

Véase también
Virtualización
CoreOS
Hypervisor
Servidor Virtual Privado (VPS)

Notas

Referencias
1. Virtualización basada en contenedores y SD-WAN (https://www.teldat.
com/blog/es/contenedores-contenerizacion-virtualizacion-de-sistema-
operativo-sd-wan/). Guillermo Lopez. teldat.com. 3 octubre 2018
2. La contenerización de aplicaciones (http://www.plotandesign.com/sist
emas/contenerizacion-de-aplicaciones/). Hector Gil.
plotandesign.com. 28 de marzo de 2019
3. «How to break out of a chroot() jail» (https://web.archive.org/web/201
30922050941/http://www.bpfh.net/computing/docs/chroot-break.html).
2002. Archivado desde el original (http://www.bpfh.net/computing/doc
s/chroot-break.html) el 22 de septiembre de 2013. Consultado el 7 de
mayo de 2013.
4. Building Systems to be Shared Securely (https://dl.acm.org/doi/pdf/10.
1145/1016998.1017001). POUL-HENNING KAMP y ROBERT
https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo
WATSON. ACM QUEUE Julio/Agost de 2004
5. Capítulo 15. Jaulas (https://www.freebsd.org/doc/es_ES.ISO8859-1/b
ooks/handbook/jails.html). Manual de FreeBSD. 1995-2010
6. Virtualización ligera usando contenedores: Introducción (http://jj.githu
b.io/IV/documentos/temas/Intro_contenedores). Material docente para
la asignatura Infraestructura Virtual. JJ Merelo. Universidad de
Granada.
7. Personalización de entorno de desarrollo y despliegue sobre
contenedores (https://idus.us.es/bitstream/handle/11441/91381/TFG-2
669-RODRIGUEZ.pdf). 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 (https://linuxhint.com/lxd-vs-docker/). Ranvir Singh.
2017
5/7
8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre
9. ¿Qué es Docker? (http://www.arquitectoit.com/docker/que-es-docke
r/). Víctor Cuervo. 26 de noviembre de 2019.
10. Trabajando con imágenes en Docker (https://clouding.io/hc/es/article
s/360010283060-Trabajando-con-im%C3%A1genes-en-Docker).
Marcos Saiz. 2019
11. LXD 2.0: Introduction to LXD 1/12 (https://stgraber.org/2016/03/11/lxd-
2-0-introduction-to-lxd-112/). Stéphane Graber. 11 de marzo de 2016
12. Volúmenes y datos persistentes en Docker (https://welcomedeveloper
s.es/docker/volumenes-y-datos-persistentes-en-docker/). Pablo. 2 de
enero de 2019
13. LXC vs. libcontainer (https://www.educative.io/edpresso/lxc-vs-libcont
ainer). Anusheh Zohair Mustafeez
14. runC: The little container engine that could (https://opensource.com/lif
e/16/8/runc-little-container-engine-could). Phil Estes. 15 de agosto de
2016
15. What’s Running My Containers? A review of runtimes & standards (htt
ps://events19.linuxfoundation.org/wp-content/uploads/2018/07/OSLS_
-Container-runtimes-and-standards.pdf). Phil Estes
16. Una guía no tan rápida de Docker y Kubernetes (https://medium.com/i
ngenier%C3%ADa-en-tranqui-finanzas/una-gu%C3%ADa-no-tan-r%C
3%A1pida-de-docker-y-kubernetes-933f5b6709df). Mauricio Collazos.
19 de junio de 2018
17. Virtualización con contenedores Docker: alternativas (https://www.ion
os.es/digitalguide/servidores/know-how/alternativas-a-los-contenedor
es-en-docker/). ionos.es. 9 de julio de 2019
18. 5 Container Alternatives to Docker (https://containerjournal.com/topic
s/container-ecosystems/5-container-alternatives-to-docker/). Bill
Doerrfeld. 22 de enero de 2019
19. A Comprehensive Container Runtime Comparison (https://www.capital
one.com/tech/cloud/container-runtime/). Evan Baker. 10 de junio de
2020
20. Apache Mesos (https://guiadev.com/apache-mesos/). Viviana. 23 de
julio de 2018
21. Containers con Windows Server 2016 (https://www.jmsolanes.net/es/c
ontainers-windows-server-2016/). Josep Ma Solanes. 5 de abril de
2016
22. Open Container Initiative (https://searchitoperations.techtarget.com/de
finition/Open-Container-Initiative). searchitoperations.techtarget.com.
Noviembre de 2015
23. ¿Psicosociales en el mundo de los contenedores? Kubernetes
depreca a Docker (https://www.consultorinternet.com/2020/12/psicoso
ciales-en-el-mundo-de-los-contenedores-kubernetes-depreca-a-docke
r.html). ecardenas. 3 de diciembre de 2020
24. Kubernetes ha deprecado Docker (https://blog.arima.eu/es/2020/12/0
4/kubernetes-is-deprecating-docker.html). Iñigo Telleria 4 de
diciembre de 2020
25. An introduction to crun, a fast and low-memory footprint container
runtime (https://www.redhat.com/sysadmin/introduction-crun). 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» (http://docs.oracle.com/cd/E19044-01/sol.containers/8
17-1592/zones.intro-1/index.html). 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» (http://docs.oracle.com/cd/E190
44-01/sol.containers/817-1592/gchhy/index.html). 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» (https://www.slideshar
e.net/bcantrill/illumos-lx). slideshare.net. Consultado el 10 de octubre
de 2014.
29. Introducción a contenedores Docker (http://www.dmartin.es/2016/09/i
ntroduccion-contenedores-docker/). José David. 28 de septiembre de
2016
30. Bubblewrap (https://github.com/containers/bubblewrap).
31. Firejail: Putting a program in its own little container (http://billauer.co.il/
blog/2020/06/firejail-cgroups/). Eli Billauer.11 de junio de 2020
32. nsroot: Minimalist Process Isolation Tool Implemented With Linux
Namespaces (https://arxiv.org/pdf/1609.03750.pdf). Inge Alexander
Raknes, Bjørn Fjukstad y Lars Ailo Bongo. University of Tromsø]
33. Sandbox (https://cortafuegos.net/blog/articulos/sandbox).
cortafuegos.net
34. Sandbox your applications with Firejail (https://ownyourbits.com/2017/
10/29/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 (http://www.adminso.es/recursos/Proye
ctos/PFC/PFC_eugenio.pdf). Eugenio Villar y Julio Gómez.
Universidad de Almería. Junio de 2010
https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo
36. Cómo desarrollar con Docker en Linux dentro de Windows sin
arranque dual – WSL 2 (https://marquesfernandes.com/es/tecnologia-
es/how-to-develop-with-docker-no-linux-within-windows-without-dual-
boot-wsl-2/). Henrique Marques Fernandes. 18 de junio de 2020
37. Comparativa de orquestadores: Docker Swarm vs Kubernetes vs
Apache Mesos (https://profile.es/blog/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» (http://www.freebsd.org/d
oc/en/books/developers-handbook/secure-chroot.html). 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» (http://www.inf
oq.com/news/2014/03/docker_0_9). 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 (http://linux-vserver.org/Pap
er#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]» (https://www.stgraber.org/2014/01/01/lxc-1-0-security-feature
s/). 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 (https://books.
google.com/books?id=TPWoCwAAQBAJ). 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» (https://insights.ubuntu.com/2015/05/06/live-
migration-in-lxd/). Ubuntu Insights Web site.
49. In progress: Works on non-systemd OS48 ​
50. «I/O priorities for containers» (https://wiki.openvz.org/I/O_priorities_for
_VE). 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» (https://openvz.org/Docker_inside_CT).
54. Docker containers can run inside OpenVZ containers.53 ​
55. «Container» (https://wiki.openvz.org/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)» (http://www.paul.sladen.org/vserver/aspcomplete/2000-08-25/v
e-0.4.2-for-2.4.0-test6.diff.gz).
58. Available since version 4.0, January 2008.
59. «Parallels Virtuozzo Now Provides Native Support for Docker» (http://
www.odin.com/news/pr/release/article/parallels-virtuozzo-now-provide
s-native-support-for-docker/).
60. Docker containers can run inside Virtuozzo containers.59 ​
61. Pijewski, Bill. «Our ZFS I/O Throttle» (http://dtrace.org/blogs/wdp/201
1/03/our-zfs-io-throttle/).
62. Yes with illumos61 ​
63. See OpenSolaris Network Virtualization and Resource Control for
more details.
64. Network Virtualization and Resource Control (Crossbow) FAQ (http://
www.opensolaris.org/os/project/crossbow/faq/) Archivado (https://web.
archive.org/web/20080601182802/http://www.opensolaris.org/os/proje
ct/crossbow/faq/) el 1 de junio de 2008 en Wayback Machine.
65. «Managing Network Virtualization and Network Resources in Oracle®
Solaris 11.2» (http://docs.oracle.com/cd/E36784_01/html/E36813/inde
x.html).
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.
6/7
8/3/23, 23:17 Virtualización a nivel de sistema operativo - Wikipedia, la enciclopedia libre
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 (http://www.oracle.com/technetwork/d
ocumentation/solaris-11-192991.html).
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» (http://www.cybera.ca/news-and-events/tech-radar/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 (http://www.freebsd.org/cgi/ma
n.cgi?query=jail&sektion=8) for details.
73. «Hierarchical_Resource_Limits - FreeBSD Wiki» (http://wiki.freebsd.o
rg/Hierarchical_Resource_Limits). 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» (htt
p://static.usenix.org/publications/library/proceedings/usenix03/tech/fre
enix03/full_papers/zec/zec.pdf). usenix.org. 13 de junio de 2003.
75. «VPS for FreeBSD» (http://www.7he.at/freebsd/vps/). Consultado el
20 de febrero de 2016.
76. «[Announcement] VPS // OS Virtualization // alpha release» (https://fo
rums.freebsd.org/threads/34284/). Consultado el 20 de febrero de
2016.
77. «3.5. Limiting your program's environment» (http://www.freebsd.org/d
oc/en/books/developers-handbook/secure-chroot.html). Freebsd.org.
Consultado el 15 de enero de 2014.
78. «IBM Fix pack information for: WPAR Network Isolation - United
States» (http://www-01.ibm.com/support/docview.wss?uid=isg1fixinfo
109461). ibm.com.
79. Available since TL 02.78 ​
80. Live Application Mobility in AIX 6.1 (http://www.ibm.com/developerwor
ks/aix/library/au-aix61mobility/?ca=dgr-btw77liveappmobile61&S_TAC
T=105AGX59&S_CMP=GR)
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

Obtenido de «https://es.wikipedia.org/w/index.php?title=Virtualización_a_nivel_de_sistema_operativo&oldid=149708434»

Esta página se editó por última vez el 6 mar 2023 a las 14:17.

El texto está disponible bajo la Licencia Creative Commons Atribución Compartir Igual 3.0; pueden aplicarse cláusulas adicionales. Al usar este sitio, usted acepta nuestros
términos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de la Fundación Wikimedia, Inc., una organización sin ánimo de lucro.

https://es.wikipedia.org/wiki/Virtualización_a_nivel_de_sistema_operativo 7/7