Longhorn hat sich als unverzichtbare Lösung für Teams etabliert, die auf Amazon EKS stateful Anwendungen betreiben. Doch warum ist der Wechsel von der Standardlösung EBS zu Longhorn sinnvoll? Dieser Leitfaden zeigt, wie Sie Longhorn als dynamischen Speicher im Cluster einrichten und dabei von automatischer Replikation, Multi-AZ-Unterstützung und einer intuitiven Management-Oberfläche profitieren.
Warum EBS für Kubernetes an seine Grenzen stößt
Elastic Block Store (EBS) von AWS ist ein bewährter Cloud-Speicherdienst, der als virtuelle Festplatte für EC2-Instanzen fungiert. Doch im Kontext moderner Kubernetes-Workloads offenbaren sich seine strukturellen Schwächen:
- Starre Verfügbarkeitszonenbindung: EBS-Volumes sind an eine einzelne Availability Zone (AZ) gebunden. Wird ein Pod auf einen Knoten in einer anderen AZ migriert, scheitert der Zugriff – manuelle Eingriffe sind erforderlich.
- Single-Node-Zugriff: EBS unterstützt ausschließlich ReadWriteOnce (RWO), also den gleichzeitigen Zugriff durch nur einen Pod. Multi-Node-Szenarien wie Shared Filesysteme (RWX) sind nicht möglich.
- Fehlende Automatisierung bei Failover: Bei einem Knotenausfall muss das Volume manuell neu angehängt und die Anwendung neu gestartet werden. EBS bietet keine native Failover-Mechanismen.
- I/O-Bottlenecks: Da das Volume an eine einzelne EC2-Instanz gebunden ist, kann es bei hohem Datenverkehr zu Engpässen kommen.
Diese Einschränkungen führen in der Praxis zu erhöhten Betriebsaufwänden, Downtime-Risiken und einer eingeschränkten Flexibilität bei der Pod-Planung.
Longhorn: Eine Kubernetes-native Speicherlösung
Longhorn wurde speziell für Kubernetes entwickelt und adressiert die genannten Probleme mit einer verteilten Architektur. Als CNCF Incubating-Projekt bietet es folgende Vorteile:
- Verteilte Replikation: Daten werden automatisch auf mehrere Knoten kopiert, um Ausfälle abzufedern.
- Multi-AZ-Unterstützung: Volumes können über Availability Zones hinweg repliziert werden – Pods können problemlos migrieren.
- Cloud-Agnostik: Longhorn funktioniert in jedem Kubernetes-Cluster, unabhängig vom Cloud-Anbieter.
- Einfache Verwaltung: Die integrierte UI ermöglicht die Konfiguration von Snapshots, Backups und Failover-Strategien ohne manuelle Skripte.
- Flexible Zugriffsmodi: Neben RWO unterstützt Longhorn auch ReadWriteMany (RWX) für Shared-Filesystem-Anwendungen.
Die Lösung nutzt die lokalen Speicherressourcen der Knoten und aggregiert sie zu einem verteilten Blockspeicher. Jedes Volume wird durch einen eigenen Controller verwaltet, was Isolation und Resilienz garantiert.
Schritt-für-Schritt: Longhorn in EKS als Standard-StorageClass einrichten
Die Einrichtung von Longhorn in einem Amazon EKS-Cluster erfolgt in mehreren Phasen. Voraussetzung ist ein funktionierender Kubernetes-Cluster mit mindestens drei Worker-Knoten.
1. Voraussetzungen prüfen und Worker-Knoten vorbereiten
Bevor Longhorn installiert wird, müssen alle Worker-Knoten mit den erforderlichen Abhängigkeiten ausgestattet sein:
- open-iSCSI muss installiert sein: Dieses Protokoll ermöglicht die Blockspeicher-Anbindung an die Knoten.
# Beispiel für Ubuntu/Debian
sudo apt-get update && sudo apt-get install -y open-iscsi- Knoten-Labels für Disks markieren: Longhorn erkennt automatisch verfügbare Speichergeräte, sofern sie nicht bereits durch andere Prozesse belegt sind.
# Beispiel: Ein /dev/nvme1n1 als Speichergerät kennzeichnen
kubectl label nodes <node-name> node.longhorn.io/create-default-disk=true- IAM-Berechtigungen anpassen: Der Kubernetes-Service-Account benötigt Zugriff auf AWS-Ressourcen wie EC2-Volumes und Snapshots, falls externe Backups geplant sind.
2. Longhorn mit Helm installieren
Longhorn lässt sich bequem über Helm deployen. Die offizielle Chart-Repository enthält alle notwendigen Komponenten:
# Helm-Repository hinzufügen
helm repo add longhorn
helm repo update
# Longhorn installieren
helm install longhorn longhorn/longhorn -n longhorn-system --create-namespaceNach der Installation wird Longhorn als Standard-StorageClass registriert. Überprüfen Sie dies mit:
kubectl get storageclassDer Eintrag longhorn sollte nun als Standard markiert sein.
3. Management-UI einrichten und sichern
Longhorn bietet eine webbasierte Oberfläche zur Verwaltung von Volumes, Snapshots und Backups. Um den Zugriff zu sichern, empfehlen sich folgende Schritte:
- Ingress-Ressource erstellen: Nutzen Sie den AWS Load Balancer Controller, um eine externe URL bereitzustellen.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: longhorn-ui
namespace: longhorn-system
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: longhorn-frontend
port:
number: 80- Authentifizierung aktivieren: Konfigurieren Sie einen Ingress-Controller mit Basic-Auth oder OAuth2, um unbefugten Zugriff zu verhindern.
4. Volumes und Backups konfigurieren
Longhorn ermöglicht die automatische Erstellung von Snapshots und Backups. Diese lassen sich über die UI oder per CLI steuern:
- Snapshot erstellen:
kubectl -n longhorn-system exec deploy/longhorn-manager -- longhorn snapshot create <volume-name> --name <snapshot-name>- Backup auf S3 einrichten:
- Einen S3-Bucket erstellen und die Zugriffsdaten als Kubernetes-Secret hinterlegen.
- In der Longhorn-UI oder per YAML eine Backup-Richtlinie definieren:
apiVersion: longhorn.io/v1beta2
kind: Backup
metadata:
name: daily-backup
namespace: longhorn-system
spec:
volume: my-persistent-volume
snapshotName: "daily-snapshot"
backupTarget: s3://my-bucket@us-east-1/Fazit: Longhorn als Game-Changer für EKS-Speicher
Die Kombination aus Amazon EKS und Longhorn bietet eine leistungsstarke Alternative zu herkömmlichen Speicherlösungen wie EBS. Besonders für Teams, die stateful Anwendungen mit hohen Verfügbarkeitsanforderungen betreiben, überzeugt Longhorn durch seine verteilte Architektur, Multi-AZ-Unterstützung und einfache Verwaltung.
Während EBS nach wie vor eine solide Wahl für einfache Szenarien bleibt, ermöglicht Longhorn eine zukunftssichere Speicherstrategie, die Skalierbarkeit und Resilienz in den Vordergrund stellt. Unternehmen, die Wert auf Cloud-Agnostik und Automatisierung legen, profitieren besonders von dieser Lösung. Die Einrichtung ist zwar mit etwas Vorarbeit verbunden, zahlt sich jedoch durch geringeren Betriebsaufwand und höhere Ausfallsicherheit aus.
KI-Zusammenfassung
Learn how Longhorn fixes EBS limitations in EKS—multi-AZ replication, automatic failover, and ReadWriteMany support. Step-by-step guide to deploy as default storage class.