Virtualisierung
Harvester
Harvester ist eine quelloffene hyperkonvergente Infrastruktur (HCI) auf Basis von Kubernetes, KubeVirt und Longhorn, die VMs und Container vereint.
- Open-Source-HCI (SUSE)
- Kubernetes + KubeVirt + Longhorn
- VMs und Container vereint
- Bare-Metal, Rancher-Integration
- VMware-/vSphere-Alternative
Harvester ist eine quelloffene hyperkonvergente Infrastruktur (HCI) von SUSE. Statt einen klassischen Hypervisor zu bauen, setzt Harvester auf Kubernetes als Fundament und ergänzt KubeVirt für VM-Management und Longhorn für verteilten Block-Speicher. So laufen virtuelle Maschinen und Container auf derselben Plattform.
Dieser Artikel erklärt die Architektur, die VMware-Alternative-Positionierung, die Rancher-Integration sowie die Hardware-Anforderungen und Grenzen, die vor einer Migration zu beachten sind.
1. Architektur
Harvester läuft auf Bare-Metal mit einem immutablen, wartungsarmen Betriebssystem (SUSE Linux Micro). Darauf bildet Kubernetes die Steuerungsebene; KubeVirt verwaltet VMs als Kubernetes-Ressourcen (KVM-basiert), und Longhorn liefert verteilten, replizierten Block-Speicher direkt im Cluster. Monitoring mit Prometheus und Grafana ist eingebettet.
2. VMs und Container auf einer Plattform
Der Reiz von Harvester liegt in der Konsolidierung: Wer ohnehin Kubernetes betreibt, kann VMs und Container über dieselbe Infrastruktur und dieselben Werkzeuge fahren, statt zwei getrennte Stacks zu pflegen. Bestehende VM-Workloads werden so schrittweise neben Container-Workloads betreibbar.
3. VMware-Alternative und Rancher-Integration
SUSE positioniert Harvester ausdrücklich als offene Alternative zu VMware vSphere. Über das Rancher Virtualization Management lassen sich Harvester-VMs und Kubernetes-Cluster aus einer Oberfläche verwalten, was Harvester gut in eine bestehende Rancher-Landschaft einfügt.
4. Anforderungen und Grenzen
Harvester ist eine Cluster-Plattform, kein Einzelserver-Hypervisor: Für volle HA und Live-Migration sind mindestens drei Knoten nötig, und die Knoten brauchen identische oder über ein gemeinsames CPU-Modell kompatible CPUs. Ab Version 1.8 ist UEFI Pflicht, Nested Virtualization wird nicht unterstützt, und gemischte Architekturen sind ausgeschlossen. Funktionsumfang und Reife sollten gegen den konkreten Migrationsbedarf geprüft werden.
Hardware-Homogenität einplanen
Live-Migration verlangt identische oder über ein gemeinsames CPU-Modell (QEMU-CPU-Profil) kompatible CPUs über alle Knoten. Wer Cluster aus stark gemischter Hardware aufbaut, schränkt die Beweglichkeit ein, für die HCI gedacht ist. Knoten möglichst baugleich beschaffen.
5. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Offene HCI ohne Lizenzfesseln, VMs und Container vereint | Cluster-Plattform: mind. 3 gleichartige Knoten für HA |
| Kubernetes-native, integrierter Longhorn-Storage | Keine Nested Virtualization, ab v1.8 UEFI Pflicht |
| Gute Rancher-Integration, klare vSphere-Alternative | Reife/Funktionsumfang vor Migration gegen Etabliertes prüfen |
Häufige Fragen zu Harvester
Harvester zielt als offene HCI auf vSphere-Szenarien und vereint VMs und Container auf Kubernetes-Basis. Ob es im Einzelfall passt, hängt vom benötigten Funktionsumfang, der Reife einzelner Features und der Hardware ab; ein Abgleich mit dem konkreten Workload ist vor der Migration ratsam.
Beide sind offene Virtualisierungsplattformen, gehen aber unterschiedliche Wege: Harvester ist Kubernetes-native HCI (KubeVirt/Longhorn) und stark auf Cluster und Rancher ausgerichtet; Proxmox VE ist ein eigenständiger KVM-/LXC-Hypervisor mit eigenem Cluster- und Storage-Modell.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Harvester im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.