Podman obtiene soporte de superposición sin raíces

Podman puede usar el sistema de archivos superpuesto nativo con las versiones del kernel de Linux 5.13. Hasta ahora hemos usado superposiciones de fusibles. El kernel obtuvo soporte sin raíz en el kernel 5.11, pero un error impidió que SELinux se usara con el sistema de archivos; este error se corrigió en 5.13.

Parece Fedora retroporta el parche a sus kernels 5.12, por lo que los usuarios deberían poder usarlo una vez que obtengan acceso al kernel.

Índice

    ¿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 en un espacio de nombres de usuario. Incluían tmpfs, bind mounts, procfs, sysfs y fuse. Podman usó el superposiciones de fusibles sistema de archivos montado con este soporte de montaje de fusibles en el espacio de nombres de usuario durante muchos años.

    El apilamiento de fusibles fue excelente. Sin embargo, es un sistema de archivos de espacio de usuario, lo que significa que tiene que hacer casi el doble de trabajo que el kernel. Cada lectura/escritura debe ser interpretada por el fusible antes de ser transmitida al núcleo del host. Para cargas de trabajo pesadas que golpean el sistema de archivos, el rendimiento del apilamiento de fusibles se ve afectado. Podrías ver los fusibles superpuestos volviendo a conectar la CPU. En última instancia, deberíamos ver un mejor rendimiento con superposiciones nativas, especialmente para contenedores pesados ​​de lectura/escritura en modo sin raíz. Por ejemplo, podman build . el rendimiento debe mejorar considerablemente. 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 la gente trata de correr Podman y Construido en un contenedor confinado, retiramos el CAP_SYS_ADMIN privilegios, incluso cuando se ejecuta como root. Esto requiere que usemos un espacio de nombres de usuario para poder 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 (no CAP_SYS_ADMIN), /dev/fuse ya no será necesario.

    ¿Como puedo usar lo?

    Desafortunadamente, solo podrá usar la superposición nativa con almacenamiento nuevo, lo que significa que tendrá que destruir todo el almacenamiento existente en su contenedor. Es necesario hacer un podman system reset si ya tiene imágenes/contenedores.

    La razón es que cuando se usa un programa de edición, almacenamos un archivo de bandera en el directorio de almacenamiento: $Almacenamiento/overlay/.has-mount-program. Si el archivo está presente, c/Almacenamiento ignora la compatibilidad con superposición nativa. El motivo de tal verificación es que existen diferencias en la forma en que fuse-overlayfs almacena los metadatos, incluida la eliminación de archivos en kernels más antiguos que no permitían crear el dispositivo de eliminación especial para usuarios sin privilegios, y 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. A partir de entonces, se usará la superposición nativa si es compatible con el kernel subyacente.

    En cuanto a otras distribuciones, este soporte aparecerá cuando se lance el kernel 5.13. Para el flujo de RHEL/CentOS, planeamos retroadaptar la funcionalidad para 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 funciones y luego lo discutimos con el equipo del kernel para ver si podemos integrarlas de forma nativa.

    Una característica importante que hemos agregado es la compatibilidad con el almacenamiento de atributos de seguridad de archivos en atributos de archivo extendidos (xattr). Lo necesitamos para admitir los directorios de inicio de NFS. Los servidores NFS bloquean el uso de contenedores con múltiples UID en el espacio de nombres de usuario. Esto cierra a los usuarios de NFS directorios de inicio para 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. En el contenedor en ejecución, el contenido se representa como UID/GID diferente según 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 ensambladores y almacena el UID diferente en un xattr.

    Conclusión

    Los contenedores Rootless Podman continúan 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 están respaldados para brindar un mejor soporte. Háganos saber cómo planea usar esta nueva característica.

    Artículos de interés

    Subir