Longhorn ist ein verteilter Blockspeicher für Kubernetes: Es nimmt die lokalen Platten deiner Nodes, legt darauf Volumes an und hält von jedem Volume mehrere synchrone Kopien auf verschiedenen Nodes. Fällt eine Node aus, läuft dein Pod mit einer der verbleibenden Kopien weiter. Longhorn lohnt sich vor allem für kleine Cluster ab drei Nodes auf eigener Hardware, auf Bare Metal oder bei Anbietern ohne guten Blockspeicher. Wer bereits replizierten Cloud-Speicher über einen CSI-Treiber hat, braucht es meistens nicht. Aktuell ist Longhorn 1.13.0 (Stand 30.10.2026), installiert per Helm, mit open-iscsi auf jeder Node als wichtigster Voraussetzung.
Ich bin Kubestronaut der CNCF und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben. Damit du das hier richtig einordnest: Auf meinem eigenen Produktionscluster auf Hetzner läuft nicht Longhorn, sondern der Hetzner-CSI-Treiber mit der StorageClass hcloud-volumes. Dieser Beitrag stützt sich deshalb auf die offizielle Longhorn-Dokumentation zur Version 1.13.0, nicht auf eigenen Longhorn-Betrieb. Alle Beiträge zum Thema findest du auf der Seite Kubernetes.
Longhorn in Kubernetes: so funktioniert die Architektur
Longhorn trennt Steuerung und Datenpfad. Der Longhorn Manager läuft als DaemonSet auf jeder Node und arbeitet wie ein Operator: Er beobachtet eigene Custom Resources und legt daraus Volumes an (das Muster erkläre ich in Kubernetes Operator und CRD erklärt).
Den Datenpfad übernimmt die Longhorn Engine. Jedes Volume bekommt seinen eigenen kleinen Storage-Controller, und der läuft immer auf der Node, auf der auch der Pod läuft. Die Engine schreibt jeden Block synchron auf alle Replikas, die auf verschiedenen Nodes liegen. Stürzt ein Controller ab, betrifft das nur dieses eine Volume. Bei N Replikas verkraftet ein Volume laut Dokumentation höchstens N minus 1 ausgefallene Replikas, weil mindestens eine gesunde Kopie übrig bleiben muss.
Engine und Replikas laufen als Prozesse im Instance Manager, einem Pod pro Node in longhorn-system. Startet er neu, sind alle Volumes betroffen, die er auf der Node bedient. Deshalb reserviert Longhorn ihm CPU und schützt ihn mit einem PodDisruptionBudget. Die neuere V2 Data Engine braucht rohe Blockgeräte, Huge Pages und einen eigenen CPU-Kern pro Node; für kleine Cluster bleibst du beim Standard V1.
Replikas: wie viele Kopien bei drei Nodes
Die StorageClass longhorn, die das Helm-Chart anlegt, verwendet drei Replikas. Bei drei Nodes liegt damit auf jeder Node eine Kopie. Die Best Practices empfehlen für Produktion, die Einstellung „Replica Node Level Soft Anti-Affinity“ auf false zu lassen, das ist auch der Standard. So landen nie zwei Kopien desselben Volumes auf einer Node. Daraus folgt bei drei Nodes: Fällt eine Node aus, läuft das Volume mit zwei Kopien weiter, aber Longhorn findet keinen Platz für eine dritte, bis die Node zurück ist.
Für datenintensive Anwendungen nennen die Best Practices zwei Replikas als Standard, weil das Plattenplatz und Schreiblast spart. Anwendungen, die selbst replizieren, etwa ein verteilter Datenbank-Cluster, kannst du mit dataLocality: strict-local und genau einer Replika betreiben. Dann doppelt sich die Redundanz nicht. Wie solche Anwendungen ihre Volumes pro Instanz bekommen, zeige ich in Kubernetes StatefulSet oder Deployment?.
Für die Planung hilft eine Zahl aus der Dokumentation: Der Leseindex im Arbeitsspeicher kostet ein Byte pro 4-KiB-Block, ein Volume mit 1 TB belegt also pro Replika 256 MB RAM. Eine defekte Replika verwirft Longhorn nach 48 Stunden (staleReplicaTimeout: 2880 Minuten).
Voraussetzungen: open-iscsi, NFSv4 und Hardware
Longhorn greift tief ins Betriebssystem der Nodes ein. Die Installationsanleitung zu 1.13.0 verlangt auf jeder Node:
- Kubernetes ab Version 1.34 und eine kompatible Container-Runtime wie containerd
open-iscsi mit laufendem Dienst iscsid und geladenem Kernelmodul iscsi_tcp, weil V1 die Volumes per iSCSI bereitstellt- einen NFSv4-Client, wenn du ReadWriteMany-Volumes oder ein NFS-Backupziel nutzt
- die Werkzeuge
bash, curl, findmnt, grep, awk, blkid und lsblk
- ein Host-Dateisystem mit ext4 oder XFS sowie Root- und privilegierte Rechte für die Longhorn-Pods
Eine Warnung steht ausdrücklich in der Anleitung: open-iscsi 2.1.12 nicht installieren, weil eine Konfigurationsänderung dort das Anhängen von Volumes scheitern lässt. Ältere Versionen bis 2.1.11 oder neuere ab 2.1.13 sind in Ordnung. Unterstützt werden AMD64 und ARM64.
Ob deine Nodes bereit sind, prüft das Kommandozeilenwerkzeug longhornctl. Auf Debian oder Ubuntu installierst du die Pakete sonst selbst:
# Prüfung aller Nodes über die kubeconfig
./longhornctl check preflight
# oder von Hand auf jeder Node (Debian/Ubuntu)
apt-get install open-iscsi nfs-common
modprobe iscsi_tcp
Als Mindestausstattung für Produktion nennen die Best Practices drei Nodes mit je 4 vCPUs und 4 GiB RAM, SSD- oder NVMe-Speicher und eine eigene Platte für Longhorn statt der Systemplatte. Für gute Leistung empfehlen sie 10 Gbit/s zwischen den Nodes. Wichtiger als IOPS ist laut Dokumentation die Latenz, denn jede Schreiboperation geht synchron über das Netz.
Longhorn per Helm installieren
Die Installation selbst ist kurz. Helm 3 auf deinem Rechner reicht:
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
--namespace longhorn-system --create-namespace --version 1.13.0
kubectl -n longhorn-system get pod
Drei Dinge solltest du danach wissen. Erstens markiert das Chart seine StorageClass longhorn als Default, und auf k3s ist local-path ebenfalls Default. Bei zwei Default-Klassen nimmt Kubernetes für ein PVC ohne storageClassName die zuletzt angelegte, also entscheide dich bewusst. Zweitens ist die Weboberfläche ohne Anmeldung erreichbar, sobald du sie per Ingress freigibst; setz eine Authentifizierung davor. Drittens rät die Dokumentation davon ab, die Standard-StorageClass zu ändern. Lege eine neue an:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-2r
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
parameters:
numberOfReplicas: "2"
dataLocality: "best-effort"
staleReplicaTimeout: "2880"
fsType: "ext4"
Betreibst du den Cluster per GitOps, gehört das Release mit fester Version ins Repository, wie in GitOps mit ArgoCD: Deployments aus Git beschrieben.
Longhorn Backup: Snapshots und Sicherung nach S3
Ein Longhorn-Snapshot ist kein Backup. Snapshots liegen als Teil jeder Replika auf denselben Platten wie das Volume, höchstens 254 pro Volume. Sie sind absturzkonsistent: Longhorn führt vor dem Snapshot sync aus, eine Datenbank mit offenen Transaktionen ist damit aber noch nicht anwendungskonsistent.
Ein Backup liegt außerhalb des Clusters in einem Backupstore, bevorzugt S3-kompatibel, alternativ NFS, SMB oder Azure Blob. Die Zugangsdaten kommen in ein Secret im Namespace longhorn-system. Bei einem S3-kompatiblen Anbieter außerhalb von AWS setzt du zusätzlich AWS_ENDPOINTS. Das Ziel trägst du im Format s3://<bucket>@<region>/ ein, per Weboberfläche oder per Helm unter defaultBackupStore.backupTarget und defaultBackupStore.backupTargetCredentialSecret.
Regelmäßige Backups legst du als RecurringJob an. Dieses Beispiel sichert alle Volumes ohne eigene Zuordnung täglich um 3 Uhr und behält 14 Stände:
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
name: backup-taeglich
namespace: longhorn-system
spec:
cron: "0 3 * * *"
task: "backup"
groups:
- default
retain: 14
concurrency: 2
Eine Regel ist leicht zu übersehen: Den Lebenszyklus der Backups im Bucket verwaltet allein Longhorn. Eine Aufbewahrungsregel direkt am Bucket ist laut Dokumentation ausdrücklich verboten. Longhorn sichert nur die Volumes. Den Cluster-Zustand in etcd und die Manifeste brauchst du zusätzlich; wie das zusammenspielt, beschreibe ich in Kubernetes Backup: etcd und Volumes sichern.
Longhorn, Cloud-CSI oder local-path: was passt wann
Die Grundlagen zu Persistent Volumes, StorageClass und den drei Wegen erkläre ich in Persistent Volumes und PVC in Kubernetes. Hier der direkte Vergleich:
Daraus ergibt sich eine Faustregel. Longhorn passt, wenn du keinen guten Blockspeicher vom Anbieter hast: eigene Server, Bare Metal, Edge-Standorte. Es passt auch, wenn du ReadWriteMany brauchst oder Backups nach S3 direkt in der Storage-Schicht haben willst. Liefert dein Cloud-Anbieter bereits replizierten Blockspeicher per CSI, würdest du mit Longhorn darüber doppelt replizieren und zusätzliche Latenz einbauen. local-path reicht für Caches, Tests und alles, was eine Node-Bindung verträgt.
Auf meinem eigenen Cluster nutze ich, wie in Kubernetes auf Hetzner: k3s in Produktion beschrieben, den CSI-Treiber von Hetzner, und Datenbanken laufen dort mit CloudNativePG, das die Replikation selbst übernimmt. Ob Selbstbetrieb von Storage für dich grundsätzlich sinnvoll ist, wäge ich in Kubernetes on-premise oder Cloud? ab.
Kleine Cluster mit drei Nodes: worauf du achtest
- Eigene Platte: Musst du die Systemplatte nutzen, lass die Einstellung „Storage Minimal Available Percentage“ auf 25 Prozent. Mit eigener Platte erlaubt die Dokumentation 10 Prozent.
- CPU-Reserve: Longhorn reserviert pro Instance Manager standardmäßig 12 Prozent der zuteilbaren CPU einer Node. Plane das bei kleinen Nodes ein.
- Wartung: Beim Leeren einer Node für Updates greift das PodDisruptionBudget des Instance Managers. Bei drei Nodes und drei Replikas wartest du, bis alle Volumes wieder gesund sind, bevor du die nächste Node anfasst.
- Monitoring: Longhorn liefert Prometheus-Metriken. Mehr dazu in Kubernetes Monitoring mit Prometheus.
Häufige Fragen
Ist Longhorn kostenlos?
Ja. Longhorn ist freie Open-Source-Software, ursprünglich von Rancher Labs entwickelt und seit dem 4. November 2021 ein Incubating-Projekt der CNCF. Kosten entstehen nur durch Hardware, Plattenplatz für die Replikas und den Speicher für Backups.
Kann Longhorn ReadWriteMany?
Ja. Longhorn stellt RWX-Volumes über einen NFSv4.1-Server in einem eigenen Share-Manager-Pod bereit. Dafür braucht jede Node einen NFSv4-Client.
Ersetzt ein Longhorn-Snapshot ein Backup?
Nein. Snapshots liegen auf denselben Platten wie das Volume. Erst ein Backup in einen externen Backupstore wie S3 übersteht den Verlust des Clusters.
Läuft Longhorn auf dem Raspberry Pi?
Longhorn unterstützt ARM64, aber kein ARM32. Ein Pi mit 64-Bit-Betriebssystem kommt also infrage; die empfohlene Ausstattung mit SSD und 4 GiB RAM pro Node gilt trotzdem. Wie du ein Pi-Cluster aufbaust, zeige ich in Kubernetes auf dem Raspberry Pi.
Wie du weitermachst
Mein Vorschlag für diese Woche: Führe longhornctl check preflight gegen einen Testcluster aus und sieh pro Node, welche Pakete fehlen. Die Installationsanleitung von Longhorn und die Best Practices sind die verbindliche Grundlage für jede Version.
Die Grundlagen zu Volumes, StorageClass und CSI-Treibern stehen ausführlich in Kapitel 6 meines Kubernetes-Praxisbuchs bei Rheinwerk. Alle Informationen zum Buch findest du auf meiner Kubernetes-Seite.
