kube/longhorn-system

Longhorn distributed block storage system

For users

You should really avoid using Longhorn as it has over time proven to be unreliable system. Prefer using remote databases in your application via the Kubernetes operator pattern.

Use Longhorn for applications that need persistent storage, but are unable to provide replication in the application layer:

• Applications that insist writing into filesystem
• Applications that serve Git repositories (eg Gitea)
• Applications that check out Git repositories (eg Woodpecker, Drone and CI systems)
• Applications that need to use SQLite

Instead of using built-in longhorn storage class, please add new storage class with suitable replication, data locality parameters and reclaim policy here

Longhorn backups are made once per day and it's configured to be uploaded to the Minio S3 bucket hosted at nas.k-space.ee

For administrators

Longhorn was last upgraded with following snippet:

wget https://raw.githubusercontent.com/longhorn/longhorn/v1.6.2/deploy/longhorn.yaml
patch -p0 < changes.diff
kubectl -n longhorn-system apply -f longhorn.yml -f application-extras.yml -f backup.yaml

After initial deployment dedicated=storage:NoSchedule was specified for Kubernetes Taint Toleration under Setting -> General on Longhorn Dashboard. Suitable nodes were tagged with storage and Longhorn scheduling was disabled on others. This is to prevent scheduling Longhorn data on arbitrary Kubernetes nodes as storage[1-4].kube.k-space.ee nodes are the ones which have additional 200G volume mounted at /mnt/persistent/