[ofrzeta]

Local volumes don't use the storage driver. Therefore there should be no performance penalty as far as I know.

EDIT: There's probably some overhead with the implementation of namespaces and cgroups but I have not found any reliable sources about the quantities. As a side not if you are using memory limits you will have a performance penalty: "Memory and swap accounting incur an overhead of about 1% of the total available memory and a 10% overall performance degradation, even if Docker is not running." (from the Docker docs). This will probably affect databases running in containers as well.

[gnufied]

Yeah this can't be stressed enough. Persistent volumes in Kubernetes are simply bind mounts that exist in your container's namespace. They don't go through docker's storage driver at all. There should be zero penalty for using persistent volumes this way within containers.

[cpuguy83]

Sorry, this seems to insinuate that Docker is slowing down (or using slow) storage... this is completely false.

Volumes in docker are just host bind mounts.

Now depending on your driver/opts (similar to K8s PV backends) this storage can come from anywhere and performance of the volume is totally dependent on the type of storage being used.

Now, the container fs that docker sets up is (usually) using a CoW filesystem, and as there is overhead there... but volumes are specifically designed to bypass the container fs.

[gnufied]

Hmm, sorry I did not mean to imply that. It is indeed true that both docker volumes and k8s PVs are just host bind mounts.

However I did mean to clarify that - k8s does not uses docker volumes. Whatever performance issues one notices could either be associated with storage provider or container writable layer.