Getting Started
Based on the install instructions in the
longhorn/longhornREADME.mdand the official docs (source 9). The latest release at the time of writing isv1.12.0. Commands assume a running Kubernetes cluster andkubectlconfigured against it.
Prerequisites
Per the manager README.md requirements section:
- A Kubernetes cluster with mount propagation enabled.
- On every host:
iscsiadm/open-iscsiand an NFS client (nfs-common/nfs-utils/nfs-client) installed. - A filesystem (ext4 or XFS) that supports the
file extentsfeature for data storage.
Run the official environment check before installing:
curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/master/scripts/environment_check.sh | bashInstall
Apply the bundled deployment manifest. It installs the manager, instance manager, CSI driver, and UI into the longhorn-system namespace.
kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yamlA first working setup
Wait for the control plane to come up. Every component runs in
longhorn-system.bashkubectl -n longhorn-system get pods --watchConfirm the default
StorageClasswas created. The manifest registerslonghorn.bashkubectl get storageclass longhornRequest a volume with a
PersistentVolumeClaimthat uses thelonghornclass.yamlapiVersion: v1 kind: PersistentVolumeClaim metadata: name: longhorn-demo spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 1GiApply it and confirm it binds.
bashkubectl apply -f longhorn-demo.yaml kubectl get pvc longhorn-demo
Verify it works
The claim should reach Bound, and Longhorn should report a healthy Volume CR with its replicas scheduled.
kubectl get pvc longhorn-demo
kubectl -n longhorn-system get volumes.longhorn.ioA healthy volume shows State: attached (once a pod mounts it) or detached with Robustness: healthy before use. You can also open the Longhorn UI service in longhorn-system to see the volume, its engine, and its replicas.
Where to go next
For production concerns Longhorn documents separately, see the official docs (source 9): dedicated disks and node configuration, replica count and data-locality tuning (source 12), backups to S3 or NFS, disaster recovery volumes, and the v2 (SPDK) data engine.