Para explicar qué son los contenedores software vamos a bajar al nivel más simple de abstracción. Buscando alguna analogía con el mundo real podemos hablar de esos containers que vemos siendo transportados en barco de un sitio a otro. No nos importa su contenido sino su forma modular para ser almacenados y transportados de un sitio a otro como cajas.
Algo parecido ocurre con los contenedores software. Dentro de ellos podemos alojar todas las dependencias que nuestra aplicación necesite para ser ejecutada: empezando por el propio código, las librerías del sistema, el entorno de ejecución o cualquier tipo de configuración. Desde fuera del contenedor no necesitamos mucho más. Dentro están aislados para ser ejecutados en cualquier lugar.
Hemos podido independizarnos en cierta medida de los sysadmin y abrazado el concepto de devops más abiertamente
Los contenedores son la solución al problema habitual, por ejemplo, de moverse entre entornos de desarrollo como puede ser una máquina local o en un entorno real de producción. Podemos probar de forma segura una aplicación sin preocuparnos de que nuestro código se comporte de forma distinta. Esto es debido a que, como nos referíamos antes, todo lo que necesitamos está dentro de ese contenedor.
Solomon Hykes, creador de Docker, lo explicaba del siguiente modo: “utilizando contenedores para ejecutar tu código solventamos el típico quebradero de cabeza de que estés usando una versión de Python 2.7 diferente en local o en el entorno de pruebas pero en producción la versión sea totalmente distinta como Python 3 u otras dependencias propia del entorno de ejecución, incluso el sistema operativo. Todo lo que necesitas está dentro del propio contenedor y es invariable”.
En definitiva, los contenedores representan un mecanismo de empaquetado lógico donde las aplicaciones tienen todo lo que necesitan para ejecutarse. Describiéndolo en un pequeño archivo de configuración. Con la ventaja de poder ser versionado, reutilizado y replicado fácilmente por otros desarrolladores o por los administradores de sistemas que tenga que escalar esa aplicaciones sin necesidad de conocer internamente cómo funciona nuestra aplicación. El fichero de Docker bastará para adecuar el entorno de ejecución y configurar el servidor dónde va a ser escalado. A partir de ese fichero se puede generar una imagen que puede ser desplegada en un servidor en segundos.
En contraposición a las máquinas virtuales, los contenedores se ejecutan sobre el mismo sistema operativo anfitrión de forma aislada también, pero sin necesidad un sistema operativo propio, ya que comparten el mismo Kernel, lo que los hace mucho más ligeros. De donde sacamos 3 máquinas virtuales probablemente podemos multiplicarlo por un gran número de contenedores software.
Un contenedor de Docker puede ocupar tan solo unas cuantas decenas de megas mientras que una máquina virtual, al tener que emular todo un sistema operativo, puede ocupar varios gigas de memoria. Lo cual representa un primer punto en el ahorro de coste.
La evolución de Docker ha sido imparable, representando actualmente uno de los mecanismos comunes para desplegar software en cualquier servidor por medio de contenedores software
Habitualmente cada aplicación en Docker va en su propio contenedor totalmente aislado, mientras que en las VMs es habitual debido al dimensionamiento tener varias aplicaciones en la misma máquina con sus propias dependencias, mucho peor para escalar de forma horizontal.
Básicamente, los contenedores se basan en dos mecanismos para aislar procesos en un mismo sistema operativo. El primero de ellos, se trata de los namespace que provee Linux, lo que permite que cada proceso solamente sea capaz de ver su propio sistema “virtual” (ficheros, procesos, interfaces de red, hostname o lo que sea). El segundo concepto son los CGroups, por el cual somos capaces de limitar los recursos que puede consumir (CPU, memoria, ancho de banda, etc)
Fuente: https://www.xataka.com/otros/docker-a-kubernetes-entendiendo-que-contenedores-que-mayores-revoluciones-industria-desarrollo