| .. | ||
| .gitignore | ||
| application-extras.yml | ||
| backup.yaml | ||
| changes.diff | ||
| README.md | ||
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/