local-path-provisioner VS helm-charts

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).

https://github.com/VictoriaMetrics/helm-charts/commit/128d2a7fa23c717e780655f03df83b03e3d637ac could be the reason

There is also victoriametrics-operator and victoriametrics k8s stack helm chart.

BTW, you can use victoria-metrics-k8s-stack as a drop-in replacement for kube-prometheus-stack.

It is possible to replace kube-prom-stack with VictoriaMetrics stack in every k8s cluster - see https://github.com/VictoriaMetrics/helm-charts/blob/master/charts/victoria-metrics-k8s-stack/README.md

I'm monitoring CPU, memory, disk, network usage etc, the basic stuff available from kubernetes metrics via api. I also have a sidecar pod to send CPU temperature via opentsdb endpoint of Victoria Metrics. I run this helm chart which has operator and db - it can be added to grafana as a Prometheus data source.

There is a k8s stack Helm Chart which can provide the same functionality. Also check VictoriaMetrics Operator docs and our guides .

For metrics there is VictoriaMetrics operator and helm chart, which can be used for monitoring Kubernetes. See this guide.