local-path-provisioner VS external-snapshotter

Deploy local-path-provisioner storage class but it does not support readwritemany so for high availability of your Kubernetes cluster better to use longhorn

I use this one. I'm waiting for the day it's combined with syncthing to sync across all nodes. https://github.com/rancher/local-path-provisioner

So I have this single node k3s cluster. k3s uses local-path (https://github.com/rancher/local-path-provisioner) as default SC that allows one to create dynamic volumes using nodes local storage.

Just create 1 single partition and format it with whatevery filesystem you like. And then use ranchers local-path-provisioner which will create a folder per PV (k3s has this integrated by default).

Tinkering locally with local path provisioner (https://github.com/rancher/local-path-provisioner), I find that I can delete and re-create the pod, and the data persists on disk. However, if I delete the PVC, when I recreate the PVC, a new directory on disk is created.

It is better to use https://github.com/rancher/local-path-provisioner (or similar) for this case which will do PVC on local directories because manually linking PV<>PVC will not work.

Since you only have one physical node anyway, I would just make the cluster a single-node cluster (1 VM) and use local storage on that VM. I’m biased though because this is what I do (I run K3s and use local path provisioner).

Rancher's Local Path Provisioner - From reading, seems to just use HostPath or Local PVs under the hood, but adds dynamic provisoning

With any of those tools, you'd implement a network storage on top of a network storage. I would go with mouting few volumes per node +local storage like (https://github.com/rancher/local-path-provisioner).

By the way, I got that error very often - kubernetes-csi/external-snapshotter#300 - the fix is in progress. I'm afraid about the snapshot mechanism performance. It's also a question about the GCP snapshot mechanism, so I'm gathering opinions.

VolSync is a much better option than Velero IMO, Velero was created before GitOps was a thing and it really tries to do too much when all I need is a reliable way to backup and restore PVCs. If your CSI supports volume snapshots, VolSync can use the snapshot-controller to create Volume Snapshots and then mount those as a PVC to a temporary pod to then backup that up to S3. This is really great for backing up PVCs because it's not backing them up from a running workload.

Is it required to store it to s3? If I were U i would use native approach https://kubernetes.io/docs/concepts/storage/volume-snapshots/ with https://github.com/kubernetes-csi/external-snapshotter

#Install CSI Snapshotter and CRDs kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml kubectl apply -n kube-system -f https://github.com/kubernetes-csi/external-snapshotter/raw/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml