Description

Today, cri-o supports a single storage driver at the time and the suggested/default is overlayfs for standard containers. For VM-based runtimes, the current solution is to share the container filesystem mount point using 9p or virtiofs. However, this doesn't offer the best performance, and passing a disk would be the ideal solution.

Cri-o is already able to identify and choose different runtime types based on the selected runtime class. We could use this information and select the best storage driver for each runtime type. The required changes in cri-o are the ability to enable multiple storage drivers at the same time and select one based on the runtime class.

The benefits of this enhancement are that we avoid the conflicts between standard and VM-based containers. We could get the best performance for both kind of workloads. Giving an example, kata-container could use device-mapper instead of overlays for passing the container filesystem as a device.

In the long term, this extension could also facilitate the introduction of new storage driver types for confidential computing. These new technologies come with a lot of challenges and requirements that filesystem-based storage drivers probably cannot satisfy.

I'd like to collect any feedback and ideas and check if the community would be open to such a change :)