Entendiendo lo que realmente son los containers - entre historia y runtimes

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 das buscando, y mucho ms cuando eres del tipo de persona que quiere entender a fondo cmo 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 todava desconozco y se pueden decir cosas equiviocadas.

Lo bsico

Containers tienen como objetivo crear un ambiente virtual aislado el cual se pueda distribuir y desplegar fcilmente. 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 creacin de estos ambientes, hay dos componentes principales que quizs 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 ms en detalle los namespaces.

cgroups

Recordemos que el Linux kernel es la interfaz principal entre el hardware y los procesos, permitiendo la comunicacin entre estos dos y ayudando a la gestin 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 jerrquicamente procesos y distribuir recursos(cpu, memoria, networking, storage) dentro de dicha jerarqua.

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 configuracin a travs de systemd, pero si se desea entrar en detalle la documentacin de Linux puede ser de ayuda.

cgroups y namespaces se convierten en los ingredientes secretos en la creacin de containers, namespaces proveen aislamiento a nivel de recursos y cgroups permiten controlar los limites para dichos recursos.

Por suerte hoy en da con una sola linea podemos crear un container, no tenemos que entrar a configurar namespaces ni cgroups, veamos un poco de la evolucin de los containers y as vamos aclarando ciertas cosas.

Un poco de historia

Docker fue el primero que populariz los containers, era(o es) comn asociar containers directamente con Docker, pero antes ya exista 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 creacin de containers. Aqui un video en donde se puede ver LXC en accin.

Nota: Antes de LXC ya se haban desarrollado otros alternativas para la creacin de containers como OpenVZ y Linux Vserver. LXC es mencionado inicialmente ya que es lo ms 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 ms la creacin de containers. Al ganar popularidad se crearon mejoras y unos meses despus Docker lanz [libcontainer] el cual est escrito en Golang y bsicamente reemplazaba LXC.

Docker se enfoc ms en la creacin de containers optimizados para el despliegue de aplicaciones mejorando la portabilidad. Este post explica ms detalladamente las diferencias entre LXC y Docker.

Definiendo un estndar 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 haba sido construido como un monolito el cual corra 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 propsito crear un estndar 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 configuracin(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 ejecucin 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 travs del container image.

Todas las especificaciones para el container runtime son descritas aqui.

OCI Image spec

Docker en sus inicios ya haba definido las especificaciones para la creacin de imgenesImage Manifest 2 Schema Version 2, al ser el ms popular, OCI parti de este para crear un estndar ms general, que no estuviera asociado a un vendor en especfico. 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 informacin.

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 creacin y ejecucin 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 interacta con libcontainer para la creacin 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 da como runC y conteinerd. En lo que sigue del post tratar'e de exponer algunas containers runtime a alto nivel.