This content originally appeared on DEV Community and was authored by Daniel German Rivera
Estudiando kubernetes gasté un tiempo considerable intentando entender muchos conceptos, por ejemplo, por todo lado se habla de OCI compliant, buscas OCI y te lleva a runtime-spec, buscas runtimes y te lleva a containerd, runc, image-spec, cgroups, namespaces, etc; puedes pasar días buscando, y mucho más cuando eres del tipo de persona que quiere entender a fondo cómo funcionan las cosas.
what the CNCF sold me VS what I really get pic.twitter.com/X5pygpSE2W
— memenetes (@memenetes) March 20, 2023
Motivado por lo anterior, me decidí a escribir este post con la idea de compartir los conceptos que logré adquirir y que me han servido para entender varias cosas del gran mundo de los containers, en algunas cosas no voy a tan bajo nivel ya que hay muchos conceptos que todavía desconozco y se pueden decir cosas equiviocadas.
Lo básico
Containers tienen como objetivo crear un ambiente virtual aislado el cual se pueda distribuir y desplegar fácilmente. Dentro del container pueden correr diferentes procesos los cuales deben estar aislados de otros corriendo en el host.
El kernel de linux ofrece distintas funcionalidades que permiten la creación de estos ambientes, hay dos componentes principales que quizás son el core de todos los containers.
Linux namespaces
Linux namespaces nos permite crear ambientes virtuales y aislados, estos particionan recursos del kernel y hacen que sean visibles solo para los procesos que corren dentro del namespace, pero no para procesos externos. En otras palabras, namespaces nos facilitan el aislamiento entre procesos.
¿Qué recursos se pueden particionar?, bueno esto va a depender del tipo de namespace que se este usando, por ejemplo, network namespaces nos permite encapsular los recursos relacionados con networking, como interfaces, tablas de rutas, etc. De esta forma podemos crear una red virtual dentro de nuestro namespace.
Este post explica un poco más en detalle los namespaces.
cgroups
Recordemos que el Linux kernel es la interfaz principal entre el hardware y los procesos, permitiendo la comunicación entre estos dos y ayudando a la gestión de recursos, por ejemplo, puede terminar procesos que consuman demasiada memoria para evitar afectar el sistema operativo. Adicionalmente pueden controlar qué procesos pueden consumir cierta cantidad de recursos.
cgroups es una funcionalidad del Linux kernel que permite organizar jerárquicamente procesos y distribuir recursos(cpu, memoria, networking, storage) dentro de dicha jerarquía.
Configurar cgroups puede ser un poco complejo, en mi caso estuve leyendo varios post acerca del tema y requiere cierto tiempo para entender por completo su funcionamiento. En esta serie de posts creados por RedHat se habla sobe cgroups y su configuración a través de systemd, pero si se desea entrar en detalle la documentación de Linux puede ser de ayuda.
cgroups y namespaces se convierten en los ingredientes secretos en la creación de containers, namespaces proveen aislamiento a nivel de recursos y cgroups permiten controlar los limites para dichos recursos.
Por suerte hoy en día con una sola linea podemos crear un container, no tenemos que entrar a configurar namespaces ni cgroups, veamos un poco de la evolución de los containers y así vamos aclarando ciertas cosas.
Un poco de historia
Docker fue el primero que popularizó los containers, era(o es) común asociar containers directamente con Docker, pero antes ya existía algo llamado LXC(Linux containers), el cual puede entenderse como un proveedor de ambientes virtuales en Linux que usa ciertos componentes del Linux-Kernel para crear ambientes aislados(containers).
LXC se encuentra dentro del user-space, es decir, nosotros interactuamos con LXC y este se encarga de interactuar con los componentes del kernel para permitir la creación de containers. Aqui un video en donde se puede ver LXC en acción.
Nota: Antes de LXC ya se habían desarrollado otros alternativas para la creación de containers como OpenVZ y Linux Vserver. LXC es mencionado inicialmente ya que es lo más cercano a Docker que es el software con el que muchos iniciamos interactuando con containers.
La llegada de Docker
Docker empaquetó LXC en una herramienta que facilitaba más la creación de containers. Al ganar popularidad se crearon mejoras y unos meses después Docker lanzó [libcontainer] el cual está escrito en Golang y básicamente reemplazaba LXC.
Docker se enfocó más en la creación de containers optimizados para el despliegue de aplicaciones mejorando la portabilidad. Este post explica más detalladamente las diferencias entre LXC y Docker.
Definiendo un estándar para containers
Como alternativa a Docker, empezaron a surgir otras opciones,CoreOS por su parte lanzó rkt(2014) proponiendo mejores de seguridad, CoreOS argumentaba que Docker había sido construido como un monolito el cual corría como root en el host, abriendo posibilidades a comprometer todo el host en el caso de un ataque.
rkt usa appc(open source container) con el fin de mejorar la operabilidad, appc tiene como propósito crear un estándar general para crear containers buscando ser vendor-independent y OS-independent.
Otras iniciativas empezaron a surgir debido a la alta popularidad de los containers, debido a esto, en 2015 se crea OCI(Open Container Initiative) para definir un estandar para containers(runtimes e imagenes).
OCI Runtime spec
Runtime spec define la configuración(archivo JSON), ambiente y ciclo de vida de un container. Las configuraciones son definidas en un archivo llamado config.json, el cual contiene la metadata necesaria para la ejecución del container, este archivo es definido de acuerdo a plataforma a usar(windows, linux, solaris, etc).
otro concepto a destacar es el filesystem bundle, este es un grupo de archivos con la data y metadata para correr un container. Los principales archivos que deben contener es el config.json mencionado anteriormente y el rootfs(linux file system), este filesystem bundle se genera a través del container image.
Todas las especificaciones para el container runtime son descritas aqui.
OCI Image spec
Docker en sus inicios ya había definido las especificaciones para la creación de imágenesImage Manifest 2 Schema Version 2, al ser el más popular, OCI partió de este para crear un estándar más general, que no estuviera asociado a un vendor en específico. Image spec define como construir y empaquetar container images, personalmente no he entendido del todo el funcionamiento pero aquí está la url del repo y un blog-post que contienen mayor información.
Haciendo uso del Image spec, se puede crear una container image la cual puede ser ejecutada por cualquier OCI Runtime, esto quiere decir que a trav'es del Image spec se puede generar el filesystem bundle, el cual es usado por el runtime para la creación y ejecución del container.
The Runtime Specification outlines how to run a "filesystem bundle" that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
Container runtimes y Kubernetes
En el 2015 se lanza el primer release de kubernetes, el cual usaba Docker como runtime.
Docker decide dividir el monolito creado, libcontainer es donado a OCI y Docker empieza a trabajar en un proyecto llamado runC, este se puede ver como una herramienta que lee OCI specifications e interactúa con libcontainer para la creación de containers. runC es independiente del Docker Engine y es donado a OCI.
runC es una low-level runtime por lo que tambi'en se desarrolla containerd el cual es como una interfaz entre el cliente y runC.
Otros eventos fueron apareciendo y nuevas herramientas fueron creadas, hasta el momento solo se ha cubierto parte del origen de los container y el origen de algunas herramientas que seguimos viendo hoy en día como runC y conteinerd. En lo que sigue del post tratar'e de exponer algunas containers runtime a alto nivel.
This content originally appeared on DEV Community and was authored by Daniel German Rivera
Daniel German Rivera | Sciencx (2023-04-24T20:38:14+00:00) Entendiendo lo que realmente son los containers – entre historia y runtimes. Retrieved from https://www.scien.cx/2023/04/24/entendiendo-lo-que-realmente-son-los-containers-entre-historia-y-runtimes/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.