Podman può utilizzare il file system di overlay nativo con le versioni del kernel Linux 5.13. Finora abbiamo usato fuse-overlayfs. Il kernel ha ottenuto il supporto rootless nel kernel 5.11, ma un bug ha impedito l'uso di SELinux con il file system; questo bug è stato corretto in 5.13.
Sembra che Fedora stia effettuando il backport della correzione nei suoi kernel 5.12, quindi gli utenti dovrebbero essere in grado di usarlo una volta ottenuto l'accesso al kernel.
Perché dovrebbe interessarti?
Fino alla versione 5.11, il kernel consentiva agli utenti di montare un numero limitato di tipi di file system mentre si trovavano in uno spazio dei nomi utente. Includevano tmpfs, bind mount, procfs, sysfs e fuse. Podman ha utilizzato per molti anni il file system fuse-overlayfs montato utilizzando questo supporto per il montaggio del fusibile all'interno dello spazio dei nomi utente.
Il fusibile è stato fantastico. Tuttavia, è un file system dello spazio utente, il che significa che deve fare quasi il doppio del lavoro del kernel. Ogni lettura/scrittura deve essere interpretata dal fuse-overlay prima di essere passata al kernel host. Per carichi di lavoro pesanti che intaccano il file system, le prestazioni del fuse-overlay ne risentono. Potresti vedere i fuse-overlayfs che bloccano la CPU. In conclusione, dovremmo vedere prestazioni migliori con overlayf nativi, specialmente per contenitori di lettura/scrittura pesanti in modalità rootless. Ad esempio, podman build . le prestazioni dovrebbero migliorare notevolmente. Tieni presente che quando scrivi sui volumi, il fuse-overlayfs viene utilizzato raramente, quindi le prestazioni non ne risentiranno.
Un altro svantaggio di fuse-overlayfs è che richiede l'accesso a /dev/fuse . Quando le persone cercano di eseguire Podman e Buildah all'interno di un container confinato, togliamo i privilegi di CAP_SYS_ADMIN, anche quando si esegue come root. Questo ci costringe a utilizzare uno spazio dei nomi utente in modo da poter montare i volumi. Per farlo funzionare, gli utenti devono aggiungere /dev/fuse al contenitore. Una volta che abbiamo l'overlay nativo per la modalità rootless (nessun CAP_SYS_ADMIN ), /dev/fuse non sarà più richiesto.
Come posso usarlo?
Purtroppo, sarai in grado di utilizzare l'overlay nativo solo con un nuovo spazio di archiviazione, il che significa che dovrai distruggere tutto lo spazio di archiviazione esistente del tuo contenitore. È necessario eseguire un podman system reset se hai già immagini/contenitori.
Il motivo è che quando viene utilizzato un programma di montaggio, memorizziamo un file flag nella directory di archiviazione:$STORAGE/overlay/.has-mount-program . Se il file è presente, c/storage ignora il supporto per la sovrapposizione nativa. Il motivo di tale controllo è che ci sono differenze nel modo in cui fuse-overlayfs ha archiviato i metadati, inclusi i file di whiteout sui kernel più vecchi che non consentivano di creare il dispositivo di whiteout speciale per gli utenti non privilegiati e che non funzionerebbero se la sovrapposizione nativa è abilitata . Ciò significa che la semplice rimozione dei file causerà problemi con i contenitori esistenti.
Il podman system reset comando elimina anche il file flag. Successivamente, verrà utilizzato l'overlay nativo se supportato dal kernel sottostante.
Per quanto riguarda le altre distribuzioni, questo supporto apparirà quando verrà rilasciato il kernel 5.13. Per RHEL/CentOS Stream, prevediamo di eseguire il backport della funzionalità per la versione RHEL8.5 in autunno.
Continueremo a utilizzare/supportare fuse-overlayfs?
Abbiamo in programma di continuare a utilizzare e persino migliorare le sovrapposizioni di micce. Usiamo questa piattaforma per sperimentare nuove funzionalità e poi discuterne con il team del kernel per vedere se riusciamo a farle diventare native.
Una caratteristica importante che abbiamo aggiunto è il supporto per la memorizzazione degli attributi di sicurezza dei file in attributi di file estesi (xattr). Ne abbiamo bisogno per supportare le home directory di NFS. I server NFS bloccano l'uso di contenitori con più di un UID all'interno dello spazio dei nomi utente. Questo blocca gli utenti di homedir NFS dall'utilizzo di Podman senza configurare spazio di archiviazione aggiuntivo. Con fuse-overlayfs, possiamo avere tutti i contenuti creati da Podman archiviati nel file system come di proprietà dell'utente che esegue Podman. All'interno del contenitore in esecuzione, il contenuto è rappresentato come UID/GID diversi basati su xattrs. Quando un processo in esecuzione in questa modalità crea un file con un UID diverso, fuse-overlay intercetta la creazione dell'UID, crea il file con l'UID del mounter e memorizza il diverso UID in un xattr.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
I contenitori Rootless Podman continuano ad evolversi e diventano sempre più pratici. Per carichi di lavoro pesanti, overlayf nativo dovrebbe fornire un'esperienza di prestazioni molto migliore rispetto a fuse-overlayfs. Anche i kernel vengono sottoposti a backport per fornire un supporto migliore. Facci sapere come intendi utilizzare questa fantastica nuova funzionalità.