[QUESTION/HELP] help me understand purpose of mapping host directory to /var/lib/rancher/k3s/storage

[bayeslearner]

Question / Where do you need Help?

Help understand whether mapping some host dir to node path /var/lib/rancher/k3s/storage is needed.

Is my following understanding correct?

• If no mapping is done when creating a cluster, pods using local-path volumes will still persist upon deletion/recreation.

• pods using this type of volume do not share storage with each other when scaled up, aka each copy has its own storage.

• If no mapping is done when creating a cluster, pods using this type of volume will lose data if the cluster is stopped and restarted. This is because the /var/lib/rancher/k3s/storage path of a node is used by the local-path storage provisioner to provide this feature, when not mapping to a host path, it is lost when the cluster is stopped.

[iwilltry42]

Hi @bayeslearner , thanks for starting this discussion!

If no mapping is done when creating a cluster, pods using local-path volumes will still persist upon deletion/recreation.

Not sure if we're referring to the same thing here, but if you create a PersistentVolume using the local-path storageClass and then have a Pod that uses it via some PVC, then yes, you can delete the pod and have the new replica re-use the same PVC/PV with the data in it.

pods using this type of volume do not share storage with each other when scaled up, aka each copy has its own storage.

Yes, it's a classic RWO storageClass. For more info, see https://rancher.com/docs/k3s/latest/en/storage/#setting-up-the-local-storage-provider and https://github.com/rancher/local-path-provisioner.

If no mapping is done when creating a cluster, pods using this type of volume will lose data if the cluster is stopped and restarted. This is because the /var/lib/rancher/k3s/storage path of a node is used by the local-path storage provisioner to provide this feature, when not mapping to a host path, it is lost when the cluster is stopped.

I'm actually fairly sure that it won't be lost if you only stop/start the cluster (i.e. k3d cluster stop && k3d cluster start), as the data should be stored in the containers' overlayfs for their lifetime, meaning that the data is only lost once you k3d cluster delete the cluster (or the related containers).
So mapping this to a host path is used to persist the data "forever" on your disk, no matter what you do to your cluster, e.g. to potentially re-use it in a new cluster or to copy it somewhere else.