L'hyperconvergence n'est plus un argument de plaquette. Quand Broadcom a relevé les tarifs vSphere et étranglé l'accès à VxRail, les DSI ont cherché des piles HCI ouvertes. Nutanix Community Edition a montré ses limites. Proxmox couvre la virtualisation mais n'est pas une HCI au sens strict. SUSE Virtualization, anciennement et toujours largement appelé Harvester, est l'option qui s'est imposée du côté cloud-native.
Harvester n'est pas un fork. C'est un assemblage cohérent de briques Kubernetes : KubeVirt pour la virtualisation, Longhorn pour le stockage distribué, Multus pour le réseau VLAN, RKE2 comme moteur K8s, le tout exposé derrière une UI Rancher unifiée. Sur du bare metal, on déploie un cluster qui pilote VMs et conteneurs avec la même API.
Côté ops, ça change le modèle mental. On ne gère plus un hyperviseur, on gère une plateforme.
Plan de l'article
- Pourquoi Harvester, et pour qui
- Architecture : ce qui tourne sous le capot
- Prérequis hardware et déploiement
- Intégration Rancher : un seul plan de contrôle
- Stockage Longhorn et HA en pratique
- Réseau VLAN, SDN et trunk physique
- Harvester vs Proxmox vs vSphere
- Pièges et limites du terrain
Pourquoi Harvester, et pour qui
Trois profils tirent le bénéfice direct.
Le premier : les équipes qui opèrent déjà du Rancher pour gérer plusieurs clusters Kubernetes downstream. Ajouter Harvester, c'est ajouter un pool de VMs dans la même UI, avec le même RBAC, le même pipeline GitOps. Pas de stack parallèle.
Le deuxième : les sites edge ou agences qui ont besoin d'une solution HCI bare metal sans abonnement, capable de tourner trois noeuds, faire de la HA, et exposer aussi bien des VMs Windows que des Pods. Harvester remplit ce rôle quand un Proxmox VE manquerait d'orchestration K8s native.
Le troisième : les organisations qui veulent une plateforme convergente VM + conteneur sans la complexité OpenStack. SUSE pousse fort sur ce segment depuis le rebranding "SUSE Virtualization" et le rachat (effectif depuis 2023) de Rancher Labs.
Ceux pour qui Harvester n'est pas la cible : les équipes qui veulent simplement remplacer ESXi par un hyperviseur léger. Pour ce besoin, Proxmox VE reste plus direct, et la migration depuis VMware est plus mature, comme on l'a documenté dans notre retour de migration concrète.
Architecture : ce qui tourne sous le capot
Harvester empile des composants connus, pas du code maison opaque.
- OS : SLE Micro ou OpenSUSE Leap Micro selon la distribution. Image immutable, A/B updates, transactional rollback. On ne SSH pas pour bidouiller.
- K8s : RKE2 en moteur, en mono-cluster ou multi-noeud. Le cluster Harvester est le même cluster qui héberge les VMs.
- Virtualisation : KubeVirt pilote KVM/QEMU sur chaque noeud. Les VMs sont des CRD
VirtualMachine. - Stockage : Longhorn fait le block distribué, avec réplication 3x par défaut, snapshots, backup S3.
- Réseau : Multus permet d'attacher plusieurs interfaces aux VMs. Bridges Linux ou OVN-Kubernetes selon profil.
- UI : intégrée nativement dans Rancher Manager. Possible aussi en standalone si on n'utilise pas Rancher.
Le diagramme mental : un cluster Kubernetes bare metal, dont les workloads sont à 80% des VMs au démarrage, et où les conteneurs viennent en complément. C'est l'inverse d'un cluster K8s classique avec Longhorn pour stocker des PV où les VMs sont l'exception.
Prérequis hardware et déploiement
La doc officielle est claire :
- CPU : 16 coeurs minimum par noeud en prod. 8 coeurs en dev/lab.
- RAM : 32 Go minimum, 64 Go recommandé en prod.
- Stockage : 500 Go par noeud. SSD obligatoire pour Longhorn, NVMe recommandé.
- Réseau : 10 GbE recommandé pour le trafic Longhorn et live migration.
- Cluster : 3 noeuds minimum pour la HA.
L'installation se fait par ISO, en mode interactif ou via un fichier harvester-config.yaml pour du provisioning automatique. PXE boot supporté, ce qui s'inscrit bien dans une stack netboot DHCP/PXE existante.
En prod, ça donne ça :
# harvester-config.yaml
scheme_version: 1
server_url: https://harvester.example.lan:443
token: <token>
os:
hostname: hci-node-01
ntp_servers:
- 0.fr.pool.ntp.org
ssh_authorized_keys:
- ssh-ed25519 AAAA...
install:
mode: create
management_interface:
interfaces:
- name: eno1
method: dhcp
bond_options:
mode: balance-tlb
device: /dev/nvme0n1
iso_url: https://releases.rancher.com/harvester/v1.7.0/harvester-v1.7.0-amd64.iso
Un boot, dix minutes, le noeud joint le cluster. Le second et le troisième noeud rejoignent en pointant server_url vers le premier. Pas de vCenter à provisionner, pas de licence à activer.
Intégration Rancher : un seul plan de contrôle
Le différenciateur Harvester, c'est l'intégration Rancher.
Une fois Harvester importé dans Rancher Manager, on accède à la page "Virtualization Management". Depuis cette interface :
- On crée et opère les VMs Harvester.
- On déploie un cluster RKE2 ou K3s downstream sur Harvester (les noeuds K8s sont des VMs gérées par Harvester).
- On gère les utilisateurs, le RBAC, les pipelines GitOps Fleet, les politiques OPA Gatekeeper, le tout sur la même UI.
Ce modèle "K8s sur HCI" est différent de KubeVirt vanilla. Avec Harvester, les VMs ne sont pas un add-on à un cluster existant : elles sont la fondation, et on construit des clusters K8s applicatifs au-dessus. C'est cohérent avec un pattern "platform engineering" tel qu'on l'a abordé dans platform engineering 2026.
Côté monitoring, le cluster expose des métriques Prometheus prêtes à être ingérées par un stack Grafana classique ou par Grafana Agent.
Stockage Longhorn et HA en pratique
Longhorn est le composant le plus visible côté ops, et celui qui demande le plus d'attention.
Le modèle de réplication par défaut est 3x synchrone. Chaque volume écrit en parallèle sur 3 noeuds. Si un noeud tombe, les VMs hostées dessus sont redémarrées sur les noeuds survivants, leurs disques sont disponibles immédiatement (les autres réplicas répondent), Longhorn rebuild le réplica manquant en arrière-plan.
Le piège classique : sous-dimensionner les disques. Avec 3x replication, 1 To de données VM consomme 3 To physiques. Sur un cluster 3 noeuds avec 4 To utiles par noeud, on plafonne vers 4 To de VMs avant de saturer. Les snapshots et backups Longhorn ne consomment pas autant (CoW), mais il faut prévoir la marge.
Le second piège : oublier la séparation des réseaux. Longhorn et live migration KubeVirt génèrent du trafic stockage intense. En 1 GbE partagé avec le réseau de prod, on dégrade les VMs lors d'un rebuild. La doc recommande une carte 10 GbE dédiée stockage, sur un VLAN séparé.
Les backups Longhorn vers S3 (MinIO local ou cloud) couvrent le scénario disaster recovery. Pour un PRA testé, on s'aligne sur une stratégie 3-2-1 stricte : un backup local, un backup S3 distant, un backup hors ligne immutable.
Réseau VLAN, SDN et trunk physique
Sur le réseau, Harvester offre deux modèles.
Mode "VLAN networks". Le cluster est connecté à un trunk 802.1Q sur le top-of-rack. On déclare des ClusterNetwork Harvester par VLAN, les VMs s'attachent via Multus à un ou plusieurs VLANs. Modèle proche du vSwitch VMware ou du Linux Bridge classique en plus orchestré.
Mode "Storage network". Réseau séparé pour Longhorn, isolé du trafic VM, sur des cartes physiques distinctes ou un VLAN dédié.
L'erreur fréquente : oublier de configurer le trunk côté commutateur de DC. La VM monte mais ne joint pas le VLAN attendu. Vérifier en amont, avec l'équipe réseau, les VLANs autorisés sur les ports des serveurs Harvester.
Pour les routages avancés (eBGP entre VMs et fabric, anycast services), Harvester ne couvre pas nativement. On bascule vers Cilium ou OVN-Kubernetes sur les clusters downstream, ou on intègre un FRRouting externe.
Harvester vs Proxmox vs vSphere
| Critère | Harvester | Proxmox VE | vSphere |
| Modèle | HCI cloud-native | Hyperviseur | HCI commerciale |
| Base | K8s + KubeVirt + Longhorn | KVM + ZFS/Ceph | ESXi propriétaire |
| Licence | Open source, support SUSE | AGPLv3, sub Proxmox | Subscription Broadcom |
| Courbe apprentissage | Moyenne (K8s requis) | Faible | Moyenne |
| Intégration K8s | Native (Rancher) | Externe (RKE/K3s) | Tanzu, payant |
| Live migration | Oui (KubeVirt) | Oui | Oui (vMotion) |
| HA built-in | Oui | Oui (Corosync) | Oui (HA + DRS) |
| Backup | Longhorn + S3 | PBS | Veeam, native limited |
| Hardware mini prod | 3x16c/64Go/SSD | 3x8c/32Go/SSD | 3x16c/64Go/SAN |
| Audience | Cloud-native ops | SMB et mid-market | Grand compte VMware |
Verdict : Harvester gagne quand l'équipe est cloud-native ou que la cible est un platform engineering convergent. Proxmox gagne sur la simplicité et le coût d'entrée. vSphere ne gagne plus sur grand chose, sauf inertie contractuelle.
Pièges et limites du terrain
Côté ops, quelques constats.
Maturité par rapport à vSphere : pas encore au niveau. Pas de DRS équivalent qui rééquilibre automatiquement les VMs en fonction de la charge. L'équilibrage est manuel ou via labels d'affinité K8s. Les workloads très sensibles à la latence stockage demandent du tuning Longhorn (réplica 2x au lieu de 3x, locality strict).
Versions et upgrades. L'A/B update de SLE Micro est fiable, mais une upgrade Harvester complète (cluster) demande une fenêtre planifiée. Tester sur un cluster lab avant prod.
Drivers et hardware. Comme tout produit bare metal, attention aux NIC exotiques, RAID controllers propriétaires, GPU. La HCL officielle est plus courte que celle de VMware. Vérifier en amont.
Communauté française. Plus restreinte que celle de Proxmox. La doc est en anglais, le support payant passe par SUSE.
Limite réelle d'échelle. En production, on voit Harvester confortable jusqu'à 8 à 10 noeuds par cluster. Au-delà, il faut empiler plusieurs clusters Harvester pilotés par un Rancher central. Ce n'est pas un défaut, c'est une bonne pratique cluster-of-clusters.
Sur les déploiements qu'on opère pour nos clients qui sortent de VMware, le choix entre Proxmox et Harvester se joue souvent sur la maturité Kubernetes interne. Quand l'équipe a déjà du RKE2 ou du K3s en prod et veut converger, Harvester gagne. Sinon Proxmox. Si vous hésitez sur la cible et que la décision impacte plusieurs millions d'euros sur 3 ans, on peut auditer votre parc et chiffrer le run sur les deux pistes avant que vous engagiez la migration.
Sources
- Harvester documentation officielle : référence pour l'architecture, l'installation et l'opération.
- GitHub harvester/harvester : code source, releases, issues, roadmap publique.
- SUSE Virtualization product page : positionnement commercial et matrice de support entreprise.
- Harvester Overview - Palark tech blog : analyse technique externe avec retour terrain.
- Hyperconverged Infrastructure with Harvester - Cisco Blogs : retour intégration Cisco UCS.
