Disclaimer: This blog post is a deep dive in to the topic of Linux container storage, specifically looking at Netflix’s Open Source Titus container platform. Netflix happens to be my employer, but nothing in this blog post is secret or talk about anything that isn’t already open source.
In this Part 3, I’ll discuss how Titus (titus-storage) is able to separate the attaching of storage from the container lifecycle (how to attach storage after a container is running), all while respecting Linux namespaces, and while keeping the container completely unprivileged and in its user namespace.
We have a running container. We want to mount something in it. That “something” could be a network filesystem, a block device, a bind mount, overlayfs, tmpfs, who knows. Each situation requires a unique solution. We know that as soon as we try to switch into the user namespace of the container, we no longer can use the mount syscall reliably. Is there any other way to “inject” a mount?
Remember from Part 1 I decided to give up on the CSI and its limitations. Instead we are just going to build some binaries, like mount.nfs It will just be a binary that can run at any time and mount storage in a container, even after it has been created!