Best practice for configMaps with local provisioner

[az-z]

Hello,
im attempting to enable dynamic local storage provisioning using provided "built-in" local storage provider.
It appears that it ( the provider, residing in the kube-system namespace) uses the local-path-config configmap from "kube-system" namespace and ignores the configmap I apply into "default" namespace.

What is the proper way to enable local dynamic volume management? Do i just update the kube-system/local-path-config configmap or i should do something else?
Thank you
AZ

[brandond]

You can set --default-local-storage-path=/my/path on servers to alter the default path. Beyond that you'd need to start k3s with --disable=local-storage and deploy your own version of that manifest, as the default configmap will come back every time k3s is restarted.

[brandond]

You can do as they document, or just copy the local-storage.yaml that comes with k3s to another file before disabling it, and make your changes to that.

[az-z]

The custom :) install worked - now I have the volume at the location i specified: /tmp/blah, but the provisioned creates a subdirectory as follows:

time="2025-02-11T23:04:26Z" level=info msg="Volume pvc-5fba263c-3fb9-45a6-bb9e-cad89d8cb41c has been created on dell5000:/tmp/blah/pvc-5fba263c-3fb9-45a6-bb9e-cad89d8cb41c │
│ time="2025-02-11T23:04:26Z" level=info msg="Start of helper-pod-create-pvc-5fba263c-3fb9-45a6-bb9e-cad89d8cb41c logs" 

all I'm trying to achieve is to mount the existing directory to the node. What am i doing wrong ?

[brandond]

You don't need local-path provisioner if you're trying to mount existing directories into a pod. Local-path provisioner is for creating NEW directories on the host as a PersistentVolume to back a PersistentVolumeClaim. Its basically a "fake" PV, where normally you would have some "real" storage provider like EBS or Longhorn providing PersistentVolumes.

If you have a path on the host that you want to mount into a pod, just do that.

[az-z]

right, that is what I initially did. But now I need to be able to share the volume across several pods. And since this is POC, i do not have nfs of S3 to mount on all/several nodes, all I need is to mount host's directory on one mode and share it (RW) across several pods.

[brandond]

I'm still not understanding what the problem is. You can mount a host path into as many pods or containers as you want. LocalPath PVs should work the same as long as you ask for it to be RWX (ReadWriteMulti).

[az-z]

Right. I was just thinking to have a single pvc and mount it in pods, vs hardcode th3 directory again and again...

…

On Tue, Feb 11, 2025, 7:32 PM Brad Davidson ***@***.***> wrote: I'm still not understanding what the problem is. You can mount a host path into as many pods or containers as you want. LocalPath PVs should work the same as long as you ask for it to be RWX (ReadWriteMulti). — Reply to this email directly, view it on GitHub <#11771 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGHHXL26KGNZW5PVHR7ZTT2PKJB5AVCNFSM6AAAAABW6DFJUGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJVGY4TINQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[brandond]

Yeah but if you have a specific directory that you want mounted, that is not what local path provisioner is for. It PROVISIONS new directories in response to an unbound claim.

If you have an existing directory to use, create a HostPath PV and mount that in your pods. You only need to define the volume once.

[az-z]

Brad, thank you for breaking this down to me. I created PV/PVC pairs for each directory with an affiliation check. From the manual labor perspective, it is 300% more work, but when I decide to move out of the POC stage, this solution will pay off.