OverlayFS por dentro: por que los contenedores arrancan rapido y por que se hinchan

Un contenedor de Docker arranca en milisegundos con un sistema de ficheros que parece completo y propio. Puedes crear ficheros, reescribir paquetes y borrar directorios sin alterar el host ni la imagen de la que salio. No hay ningun disco virtual detras: lo que hace el trabajo es OverlayFS, un sistema de ficheros de union del kernel de Linux que funde varios arboles de directorios en un unico punto de montaje. Docker, containerd y Podman lo usan como base.

El problema aparece cuando se trata como un sistema de ficheros local cualquiera. Entonces llegan los picos de latencia, el disco que engorda sin motivo aparente y los cuellos de botella que nadie ve.

Cuatro rutas detras de cada contenedor

OverlayFS no gestiona bloques: se apoya en un sistema de ficheros nativo, tipicamente ext4 o xfs, y combina rutas.

• lowerdir: la pila de capas de la imagen. Es inmutable y admite hasta 128 directorios apilados, separados por dos puntos.
• upperdir: la capa escribible del contenedor. Aqui aterrizan los ficheros nuevos y las modificaciones.
• workdir: un directorio privado y vacio, en el mismo sistema de ficheros que upperdir. El kernel lo usa como banco de trabajo para que las operaciones no se queden a medias.
• merged: lo que ve el proceso. El kernel intercepta ahi las llamadas al VFS y las reparte entre upperdir y la pila de lowerdir.

La configuracion real se ve en cualquier host con contenedores en marcha consultando los montajes activos: las opciones lowerdir, upperdir y workdir aparecen tal cual en la linea que el kernel tiene montada. La documentacion del driver OverlayFS de Docker detalla esos mismos cuatro parametros.

Leer es barato, escribir no

Cuando un proceso abre un fichero en solo lectura, el kernel busca primero en upperdir. Si no esta, recorre la pila de lowerdir de la capa mas nueva a la mas antigua hasta encontrarlo y cachea la entrada de directorio apuntando al inodo fisico. Como los ficheros de lowerdir se abren directamente, sin copia, cincuenta contenedores que compartan el mismo binario de Python o de Node cargan esas paginas en RAM una sola vez. Es la razon de que compartir imagen base salga gratis.

El precio esta en la escritura. lowerdir no se puede tocar, asi que abrir un fichero existente en modo escritura dispara ovl_copy_up(). El kernel crea un inodo temporal en workdir, copia de forma sincrona todo el contenido junto con propietario, permisos, marcas de tiempo y xattrs, fuerza un fsync para que los datos esten en disco y solo entonces renombra el fichero de forma atomica a upperdir. Si el fichero del lowerdir pesa 2 GB, la primera escritura copia 2 GB. Los borrados van por la misma via: como las capas inferiores no se modifican, el kernel deja constancia en la capa escribible en lugar de eliminar nada del original.

Ahi estan los sustos de operacion. El tamano de upperdir no depende de lo que el contenedor escriba, sino de lo que suba desde abajo, y una aplicacion que abre muchos ficheros de la imagen en modo escritura paga la copia entera. Dimensionar el almacenamiento mirando solo los datos de la aplicacion es una forma rapida de llenar el disco del host.