Podman kann das native Overlay-Dateisystem mit den Linux-Kernel-Versionen 5.13. Bisher haben wir Fuse-Overlayfs verwendet. Der Kernel erhielt im 5.11-Kernel Rootless-Unterstützung, aber ein Fehler verhinderte die Verwendung von SELinux mit dem Dateisystem. Dieser Fehler wurde in 5.13 behoben.
Es sieht so aus, als würde Fedora den Fix in seine 5.12-Kernel zurückportieren, sodass Benutzer ihn verwenden können sollten, sobald sie Zugriff auf den Kernel erhalten.
Warum sollte es Sie interessieren?
Bis zur Version 5.11 erlaubte der Kernel Benutzern, eine begrenzte Anzahl von Dateisystemtypen einzuhängen, während sie sich in einem Benutzernamensraum befanden. Dazu gehörten tmpfs, bind mounts, procfs, sysfs und fuse. Podman hat viele Jahre lang das Fuse-Overlayfs-Dateisystem verwendet, das mit dieser Fuse-Mount-Unterstützung innerhalb des Benutzernamensraums gemountet wurde.
Das Sicherungs-Overlay war großartig. Allerdings ist es ein User-Space-Dateisystem, was bedeutet, dass es fast doppelt so viel Arbeit leisten muss wie der Kernel. Jeder Lese-/Schreibvorgang muss vom Fuse-Overlay interpretiert werden, bevor er an den Host-Kernel weitergegeben wird. Bei hohen Workloads, die das Dateisystem beeinträchtigen, leidet die Leistung von Fuse-Overlay. Sie konnten sehen, wie die Sicherungsüberlagerungen die CPU absteckten. Unterm Strich sollten wir eine bessere Leistung mit nativen Overlayfs sehen, insbesondere für Container mit hohem Lese-/Schreibzugriff im Rootless-Modus. Beispiel:podman build . Die Leistung sollte sich deutlich verbessern. Beachten Sie, dass beim Schreiben auf Volumes die Fuse-Overlayfs selten verwendet werden, sodass die Leistung nicht beeinträchtigt wird.
Ein weiterer Nachteil von fuse-overlayfs besteht darin, dass Zugriff auf /dev/fuse erforderlich ist . Wenn Leute versuchen, Podman und Buildah in einem begrenzten Container auszuführen, nehmen wir ihnen die CAP_SYS_ADMIN-Privilegien weg, selbst wenn sie als Root ausgeführt werden. Dies zwingt uns, einen Benutzernamensraum zu verwenden, damit wir Volumes mounten können. Damit dies funktioniert, müssen Benutzer /dev/fuse hinzufügen zum Behälter. Sobald wir ein natives Overlay für den Rootless-Modus haben (kein CAP_SYS_ADMIN ), /dev/fuse wird nicht mehr benötigt.
Wie kann ich es verwenden?
Leider können Sie das native Overlay nur mit frischem Speicher verwenden, was bedeutet, dass Sie den gesamten vorhandenen Speicher Ihres Containers zerstören müssen. Es ist notwendig, einen podman system reset durchzuführen wenn Sie bereits Bilder/Container haben.
Der Grund dafür ist, dass wir bei Verwendung eines Mount-Programms eine Flag-Datei im Speicherverzeichnis speichern:$STORAGE/overlay/.has-mount-program . Wenn die Datei vorhanden ist, ignoriert c/storage die native Overlay-Unterstützung. Der Grund für eine solche Prüfung ist, dass es Unterschiede in der Art und Weise gibt, wie fuse-overlayfs Metadaten speichert, einschließlich Whiteout-Dateien auf älteren Kerneln, die es nicht erlaubten, das spezielle Whiteout-Gerät für nicht privilegierte Benutzer zu erstellen, und das würde nicht funktionieren, wenn natives Overlay aktiviert ist . Das bedeutet, dass allein das Entfernen der Dateien Probleme mit Ihren vorhandenen Containern verursachen wird.
Der podman system reset Der Befehl löscht auch die Flag-Datei. Danach wird natives Overlay verwendet, wenn es vom zugrunde liegenden Kernel unterstützt wird.
Soweit es andere Distributionen betrifft, wird diese Unterstützung angezeigt, wenn Kernel 5.13 veröffentlicht wird. Für den RHEL/CentOS-Stream planen wir die Rückportierung der Funktion für die RHEL8.5-Version im Herbst.
Werden wir Sicherungsüberlagerungen weiterhin verwenden/unterstützen?
Wir planen, Sicherungsüberlagerungen weiterhin zu verwenden und sogar zu verbessern. Wir verwenden diese Plattform, um mit neuen Funktionen zu experimentieren und sie dann mit dem Kernel-Team zu diskutieren, um zu sehen, ob wir sie nativ machen können.
Eine herausragende Funktion, die wir hinzugefügt haben, ist die Unterstützung für das Speichern von Dateisicherheitsattributen in erweiterten Dateiattributen (xattrs). Wir brauchen dies, um NFS-Home-Verzeichnisse zu unterstützen. NFS-Server blockieren die Verwendung von Containern mit mehr als einer UID innerhalb des Benutzernamensraums. Dies stoppt Benutzer von NFS homedirs Podman zu verwenden, ohne zusätzlichen Speicher einzurichten. Mit fuse-overlayfs können wir alle von Podman erstellten Inhalte im Dateisystem als Eigentum des Benutzers speichern lassen, der Podman ausführt. Innerhalb des laufenden Containers wird der Inhalt basierend auf den xattrs als unterschiedliche UID/GIDs dargestellt. Wenn ein Prozess, der in diesem Modus läuft, eine Datei mit einer anderen UID erstellt, fängt Fuse-Overlay die UID-Erstellung ab, erstellt die Datei mit der UID des Mounters und speichert die andere UID in einem xattr.
[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Abschluss
Rootless Podman-Container entwickeln sich weiter und werden immer praktischer. Bei hohen Workloads sollte natives Overlayf ein viel besseres Leistungserlebnis bieten als Fuse-Overlayfs. Auch Kernel werden zurückportiert, um eine bessere Unterstützung zu bieten. Teilen Sie uns mit, wie Sie diese großartige neue Funktion nutzen möchten.