Longhorn Kubernetes: Block-Storage statt local-path 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 20.09.2026

TL;DR: longhorn kubernetes kurz erklärt

longhorn kubernetes ist verteiltes Block-Storage mit Replicas, Snapshots und Volume-Backup im Cluster, kein Datenbank-Operator und kein Velero-Ersatz. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) nimmt local-path aus Prod und trennt Volume-Backup von Cluster-Backup. Drei Replikate sind die ehrliche Untergrenze. Besitz von Job und Ziel gehört in den Betrieb.

Das Problem: local-path ist ehrlich nur im Lab

Der Pod schreibt. Die PVC ist Bound. Die StorageClass heißt irgendwas mit local. Ein Node stirbt, und mit ihm das Verzeichnis. Restore heißt: „wir haben noch ein Backup irgendwo“, oft keines.

Genau hier endet local-path als Default und beginnt longhorn kubernetes als Betriebsfrage. Longhorn hält das Volume über Nodes. Es hält nicht den Cluster-Schnitt und nicht den Postgres-Zeitpunkt.

Den Einsteiger-Schnitt PV/PVC/StorageClass trägt eine andere Seite, sobald sie live ist. Der StatefulSet-Text erklärt Pods und Volumes mit local-path. Dieser Text erklärt den Wechsel: local-path raus, Longhorn rein.

Pexon Consulting hängt die Grenze an den Managed Service: wer besitzt Replica-Zahl, Recurring Jobs und das externe Backup-Ziel.

Was ist Longhorn in Kubernetes – Replica, Snapshot, Backup?

Longhorn ist ein verteiltes Block-Storage für Kubernetes mit Replicas, Snapshots, Volume-Backup und einem eigenen Monitoring-Schnitt, kein Datenbank-Operator. Zielgruppe: Betriebsteams, die CSI-Volumes im Cluster halten und die Backup-Ebene nicht mit Velero verwechseln.

Es stellt StorageClasses, Replicas über Nodes, Snapshots und Recurring Jobs. Backup und Monitoring gehören zur selben Entity. local-path ist ein Host-Pfad, ein Knoten, oft Default in Labs. Longhorn ist repliziert und kann Volume-Backup.

Stabile Version am 20.09.2026: Longhorn v1.12.1 (Release 14.08.2026). Das Repo longhorn/longhorn lag bei 7.992 GitHub-Stars. Frische im Patch: V2 Fast Volume Cloning und Storage Sharding (experimentell), Legacy V2 Linked-Clone Volumes sind ab 1.12.1 deprecated.

# StorageClass-Beispiel. Replica-Count und Backup-Target gehören in den Betrieb, nicht in Copy-Paste.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fromBackup: ""

Docs: Longhorn Architecture und Backup. Keine erfundenen RPO-Minuten.

Was sichert Longhorn-Backup, das Velero nicht sichert?

Die kurze Antwort: das Volume als Block. Velero sichert Cluster-Objekte und optional CSI-Snapshots. Longhorn-Backup schreibt eine flache Kopie nach S3, NFS oder CIFS. Beides ist nötig, eins ersetzt das andere nicht.

Unsere Empfehlung: Snapshot-Job und Backup-Job getrennt, Retention begrenzen. Unbegrenzte Snapshots fressen Disk. Ein Backup ohne Restore-Übung ist Scheinsicherheit. Den Auditor-Walkthrough trägt der Restore-Nachweis, nicht dieses Lemma.

Wann wir davon abraten: Longhorn-Backup als Antwort auf „kubernetes backup“, während Velero die Cluster-Ebene meint. Focus bleibt longhorn kubernetes, nicht der Head-Term.

Das Lemma zu Velero Backup bleibt die Cluster-Schicht. Hier bleibt die Volume-Schicht.

Wann ist local-path ehrlich, und wann müssen Sie nach Longhorn oder Cloud-Disk?

local-path ist ehrlich in Labs, Demos und Workloads, die den Node-Verlust verkraften. Es ist unehrlich, sobald Persistenz ein Geschäftswert ist und niemand den Node besitzt.

Wir raten davon ab, Replica auf 1 zu setzen, „weil Disk teuer ist“. Ein Replica ist local-path mit Extra-UI. Drei Replikate sind die Untergrenze, die wir in Prod schreiben.

Cloud-Disk (Azure Disk, EBS, GCE PD) bleibt die ehrliche Alternative, wenn der Provider die Platte und die Snapshots trägt. Longhorn gewinnt, wenn Storage im Cluster liegen soll und Nodes eigene NVMe haben. NFS allein koppelt den Cluster an ein externes Gerät und an dessen Snapshot-Fähigkeit.

Welche Storage-Frage gehört in Managed, welche ins Review?

Wer setzt numberOfReplicas? Wer darf Volumes detachieren? Liegt das Backup-Target im Kunden-Tenant? Welche Uhrzeit ist das Restore-Fenster, Mo-Fr 08:00-18:00 wie auf der Betriebsseite, nicht ein erfundenes 24/7?

Das sind Vertragsfragen. Helm-Werte sind es nicht. Pexon Consulting übernimmt den Recurring-Betrieb für den Cluster, den Sie schon haben. Kein Hosting-Tarif, kein Konfigurator.

Ins Review gehört die Prüffrage: Default-Klasse local-path? Replica unter 3? Snapshot ohne Retention? Backup-Ziel im selben Cluster? Ins Managed gehört der Besitz danach.

iscsi_tcp und nfs-common auf den Nodes sind Voraussetzung, kein Feature. multipathd kann Warnungen auslösen. Vor Prod auf der eigenen Distribution testen, Workaround dokumentieren. Capacity trennt schedulable und reserved Storage. Wer das ignoriert, sieht freie Disk und bekommt trotzdem „Volume creation failed“.

Monitoring gehört zur Entity, nicht als zweiter Blog-Titel. Volume-Health, Node-Schedulability und Storage-Reserve sind Betriebszahlen. Ohne sie merken Sie den Engpass erst am Pending-Pod. Wir schreiben die Zahlen in denselben Betriebsvertrag wie die Replica-Zahl, sonst bleibt Longhorn ein Dashboard, das niemand liest.

Ein zweiter Stolperstein ist der Restore-Pfad nach Helm. Wer nach dem Restore die App neu installiert und existingClaim vergisst, provisioniert ein leeres Volume. Der Job war grün. Die Daten liegen im alten Volume. Das ist kein Longhorn-Bug, das ist ein fehlendes Runbook.

Wie wir longhorn kubernetes nach local-path schneiden

Longhorn nachrüsten ist ein Chart. Die Migration ist die Arbeit. In einem Cluster, der schon Last trägt, gehen wir so vor:

1. Nodes vorbereiten (iscsi, Pakete). Ohne das bleibt der Provisioner rot.
2. StorageClass mit drei Replicas als Default für zustandsbehaftete Namespaces. local-path bleibt nur für Labs.
3. Neue PVCs auf Longhorn. Bestehende local-path-Volumes nicht „umlabeln“. Datenpfad planen: Dump, Sync oder App-Cutover.
4. Recurring Jobs: Snapshot und Backup getrennt. Backup-Target außerhalb des Clusters.
5. Ein Restore-Fenster im Kalender. Ohne Datum bleibt der Drill ein Vorsatz.

Was dieser Text nicht wird: die Storage-Landingpage mit CSI-Oberbegriff. Die bleibt future. Was er nicht wird: Velero-Tutorial. Focus bleibt die Phrase longhorn kubernetes.

DataForSEO nannte am 16.09.2026 longhorn kubernetes mit 110 Suchen, Marke longhorn mit Homonym-Risiko. Focus trägt deshalb kubernetes.

1.12.1 vom 14.08.2026 ist der Stand. Stars 7.992 am 20.09.2026, Repo longhorn/longhorn. Legacy V2 Linked-Clone Volumes nach dem Upgrade nicht blind weiterbetreiben.

Pexon Consulting hängt den Besitz an den Managed Service, Mo-Fr 08:00-18:00 wie die live Seite. Kein Hosting, kein Konfigurator, kein 24/7. Wer nachts einen Volume-Restore braucht, muss das gesondert klären, nicht aus diesem Lemma ableiten.

Retention im Snapshot-Job und Platz auf den Nodes müssen dieselbe Geschichte erzählen. Sieben Snapshots ohne Limit und volle Disk: jemand nennt es Sicherheit und kauft Pending. Umgekehrt: Backup-Target löscht nach drei Tagen, Job verspricht einen Monat. Beides Finding.

RWX ist verfügbar, RWO bleibt Default. Wer RWX braucht, weil mehrere Nodes gleichzeitig schreiben, muss das als Anforderung schreiben, nicht als Chart-Zufall.

longhorn kubernetes ohne getesteten Restore bleibt ein grüner Volume-Health und eine rote Überraschung. Replica, Snapshot und externes Backup haben drei Besitzer oder einen Vertrag, der die drei nennt. Ein Chart allein ist keines von beiden.

Häufig gestellte Fragen

Was kostet longhorn kubernetes?

Open Source. Geld sitzt in Disk-Kapazität (Replicas multiplizieren), Object-Store für Backups, Übungen und dem Menschen, der Jobs besitzt. Einen Chart-Preis von uns gibt es nicht. Der Betrieb hängt am Managed Service.

Ist Longhorn eine Datenbank?

Nein. Longhorn hält Block-Volumes. Postgres, MySQL oder andere Operatoren liegen darüber. PITR bleibt Barman oder ein Cloud-DB-Feature.

Longhorn-Backup oder Velero?

Andere Ebene. Longhorn sichert Volumes. Velero sichert den Cluster-Schnitt. Beides kann nötig sein. Eins als Ersatz für das andere ist die falsche Sparsamkeit.

Reicht Longhorn statt Cloud-Disk?

Kommt darauf an, ob Sie Storage im Cluster tragen wollen. Cloud-Disk gewinnt, wenn der Provider Platte und Snapshot mitliefert. Longhorn gewinnt bei On-Prem und Nodes mit lokaler NVMe.

Wie viele Replikate brauchen Sie?

Mindestens drei in Prod. Ein Replica überlebt keinen Node-Verlust. Zwei sind ein Kompromiss, den wir schriftlich ablehnen, wenn Persistenz kritisch ist.

Nächster Schritt

Verwandte Themen