Podman puede usar un sistema de archivos de superposición nativo con las versiones del kernel de Linux 5.13. Hasta ahora, hemos estado usando fuse-overlayfs. El kernel obtuvo soporte sin raíz en el kernel 5.11, pero un error impidió el uso de SELinux con el sistema de archivos; este error se solucionó en 5.13.
Parece que Fedora está adaptando la solución a sus kernels 5.12, por lo que los usuarios deberían poder usarla una vez que obtengan acceso al kernel.
¿Por qué debería importarte?
Hasta la versión 5.11, el kernel permitía a los usuarios montar una cantidad limitada de tipos de sistemas de archivos mientras se encontraban en un espacio de nombres de usuario. Incluían tmpfs, bind mounts, procfs, sysfs y fuse. Podman usó el sistema de archivos fuse-overlayfs montado con este soporte de montaje de fusible dentro del espacio de nombres de usuario durante muchos años.
La superposición de fusibles ha sido genial. Sin embargo, es un sistema de archivos de espacio de usuario, lo que significa que necesita hacer casi el doble de trabajo que el kernel. Cada lectura/escritura debe ser interpretada por la superposición de fusibles antes de pasar al kernel del host. Para cargas de trabajo pesadas que golpean el sistema de archivos, el rendimiento de la superposición de fusibles se ve afectado. Podrías ver los fusibles superpuestos conectando la CPU. En pocas palabras, deberíamos ver un mejor rendimiento con overlayfs nativos, especialmente para contenedores pesados de lectura/escritura en modo sin raíz. Por ejemplo, podman build . el rendimiento debe mejorar significativamente. Tenga en cuenta que al escribir en volúmenes, rara vez se usa fuse-overlayfs, por lo que el rendimiento no se verá afectado.
Otra desventaja de fuse-overlayfs es que requiere acceso a /dev/fuse . Cuando las personas intentan ejecutar Podman y Buildah dentro de un contenedor confinado, les quitamos los privilegios CAP_SYS_ADMIN, incluso cuando se ejecutan como root. Esto nos obliga a usar un espacio de nombres de usuario para que podamos montar volúmenes. Para que esto funcione, los usuarios deben agregar /dev/fuse al contenedor. Una vez que tengamos una superposición nativa para el modo sin raíz (sin CAP_SYS_ADMIN ), /dev/fuse ya no será necesario.
¿Cómo puedo usarlo?
Lamentablemente, solo podrá usar la superposición nativa con almacenamiento nuevo, lo que significa que deberá destruir todo el almacenamiento existente de su contenedor. Es necesario hacer un podman system reset si ya tiene imágenes/contenedores.
La razón de esto es que cuando se usa un programa de montaje, almacenamos un archivo de marca en el directorio de almacenamiento:$STORAGE/overlay/.has-mount-program . Si el archivo está presente, c/storage ignora la compatibilidad con superposición nativa. El motivo de tal verificación es que existen diferencias en la forma en que fuse-overlayfs almacenó los metadatos, incluidos los archivos de exclusión en kernels más antiguos que no permitían crear el dispositivo de exclusión especial para usuarios sin privilegios, y eso no funcionaría si la superposición nativa está habilitada. . Esto significa que simplemente eliminar los archivos causará problemas con sus contenedores existentes.
El podman system reset El comando también elimina el archivo de bandera. Posteriormente, se usará la superposición nativa si es compatible con el kernel subyacente.
En lo que respecta a otras distribuciones, este soporte aparecerá cuando se lance el kernel 5.13. Para RHEL/CentOS Stream, planeamos respaldar la característica para el lanzamiento de RHEL8.5 en el otoño.
¿Seguiremos usando/soportando fuse-overlayfs?
Planeamos continuar usando e incluso mejorar las superposiciones de fusibles. Usamos esta plataforma para experimentar con nuevas características y luego las discutimos con el equipo del kernel para ver si podemos incorporarlas de forma nativa.
Una característica destacada que hemos agregado es la compatibilidad con el almacenamiento de atributos de seguridad de archivos en atributos de archivos extendidos (xattrs). Necesitamos esto para admitir los directorios principales de NFS. Los servidores NFS bloquean el uso de contenedores con más de un UID dentro del espacio de nombres de usuario. Esto detiene a los usuarios de NFS homedirs de usar Podman sin configurar almacenamiento adicional. Con fuse-overlayfs, podemos tener todo el contenido creado por Podman almacenado en el sistema de archivos como propiedad del usuario que ejecuta Podman. Dentro del contenedor en ejecución, el contenido se representa como diferentes UID/GID según los xattrs. Cuando un proceso que se ejecuta en este modo crea un archivo con un UID diferente, fuse-overlay intercepta la creación del UID, crea el archivo con el UID de los montadores y almacena el UID diferente en un xattr.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Resumir
Los contenedores Rootless Podman siguen evolucionando y se vuelven cada vez más prácticos. Para cargas de trabajo pesadas, el overlayf nativo debería proporcionar una experiencia de rendimiento mucho mejor que con fuse-overlayfs. Los núcleos también se están adaptando para brindar un mejor soporte. Háganos saber cómo pretende utilizar esta nueva función.