Gérer un seul cluster Harvester est relativement simple. Le problème survient lorsque une entreprise répartit son infrastructure entre plusieurs centres de données, succursales ou environnements edge, et que chaque cluster commence à fonctionner comme une entité isolée. Rancher permet d’importer et de gérer plusieurs clusters Harvester à partir d’une couche centralisée, combinant la gestion des machines virtuelles avec l’authentification, le contrôle d’accès et le déploiement de Kubernetes directement sur l’infrastructure HCI.
Les clés de Rancher + Harvester en 20 secondes
- Rancher peut importer plusieurs clusters Harvester et centraliser leur accès via Virtualization Management.
- Depuis cette couche, on gère des ressources telles que les hôtes, les machines virtuelles, les images et les volumes.
- L’intégration exploite l’authentification et le contrôle d’accès basé sur les rôles (RBAC) de Rancher.
- Son node driver permet de déployer des clusters RKE2 ou K3s sur des machines virtuelles Harvester.
- Pour un environnement de production, il est conseillé de séparer la couche de gestion de l’infrastructure qu’on administre.
Cette combinaison trouve tout son intérêt dans un contexte où de nombreuses organisations revisitent leurs plateformes de virtualisation. Harvester aborde cette problématique avec une architecture différente des hyperviseurs traditionnels : plateforme HCI (Hyper-Converged Infrastructure) open source basée sur Kubernetes, intégrant virtualisation et stockage distribué. Rancher ajoute par-dessus la gestion des environnements Kubernetes et la gestion centralisée de plusieurs installations Harvester.
Cela ne signifie pas que les deux produits font la même chose.
Harvester gère l’infrastructure virtualisée. Rancher administre les différents environnements et peut utiliser Harvester comme infrastructure pour créer de nouveaux clusters Kubernetes.
Cette séparation permet de mieux comprendre pourquoi SUSE les intègre.
De cinq clusters Harvester à une seule console de gestion
Un cluster Harvester dispose de sa propre interface pour gérer les hôtes, réseaux, stockages et machines virtuelles.
Une seule installation peut suffire dans certains cas.
La situation devient plus complexe si une entreprise possède, par exemple, deux centres de données et plusieurs bureaux avec infrastructure locale. Maintenir chaque cluster indépendamment oblige à accéder à différentes consoles, ce qui reproduit certaines tâches administratives.
Rancher Virtualization Management vise à réduire cette complexité.
La documentation officielle confirme qu’il permet d’importer et de gérer plusieurs clusters Harvester, d’y accéder via Rancher, et d’exploiter les capacités d’authentification et RBAC de la plateforme.
Un point important pour les administrateurs testant cette intégration :
Un cluster Harvester doit être importé depuis :
Virtualization Management
Cluster Management
Rancher distingue volontairement ces deux interfaces. Bien que Harvester repose sur Kubernetes, sa fonction première est de fournir une plateforme de virtualisation. Avec le feature flag approprié, activé par défaut, Rancher filtre les clusters Harvester des vues destinées aux clusters Kubernetes classiques.
L’interface de Virtualization Management donne accès, par la suite, à des ressources telles que hôtes, machines virtuelles, images et volumes des clusters importés.
Cela rapproche l’expérience du concept connu de single pane of glass : plusieurs infrastructures accessibles via une couche centrale d’administration.
Il ne s’agit pas de faire en sorte que tous les clusters deviennent physiquement un seul, chaque installation Harvester restant indépendante. La gestion, elle, est centralisée.
Comment enregistrer Harvester dans Rancher
Le processus d’importation établit la relation entre les deux systèmes.
Depuis Rancher, on crée l’entrée correspondante dans Virtualization Management, puis on récupère la configuration pour l’enregistrement. Dans Harvester, on trouve le paramètre :
cluster-registration-url
qui définit précisément l’URL utilisée pour importer le cluster dans Rancher et activer sa gestion multicluster.
La documentation officielle décrit aussi tout le processus via les ressources Kubernetes. Rancher génère un ClusterRegistrationToken, dont on extrait un manifestUrl, qui sera ensuite configuré dans Harvester comme cluster-registration-url.
Une fois l’enregistrement effectué, on voit apparaître dans Harvester un cattle-cluster-agent dans l’espace de noms cattle-system. Cet agent assure la communication avec Rancher.
Ce modèle a une conséquence pratique intéressante : Rancher n’a pas besoin de traiter chaque Harvester simplement comme un Kubernetes générique.
Une intégration spécifique est prévue pour cette plateforme.
Il convient aussi de prendre en compte certaines précautions opérationnelles. Par exemple, en environnement sans accès direct à Internet, il peut être nécessaire de précharger l’image du rancher-agent en privé, ou de la charger sur les nœuds.
Une identité unique pour différentes infrastructures
Centraliser la console n’a que peu d’intérêt si, après, il faut gérer séparément utilisateurs et permissions à chaque site.
C’est là qu’intervient une autre de ses forces : Rancher exploite pleinement les capacités d’authentification, RBAC et multi-tenancy.
SUSE met en avant ces fonctionnalités comme un des avantages de Virtualization Management.
Au lieu d’en faire un élément distinct pour chaque cluster, l’organisation peut appliquer des politiques d’accès à partir d’une couche unique.
Cela devient particulièrement crucial lorsque plusieurs profils existent :
- Un administrateur d’infrastructure nécessite souvent des droits étendus, tandis qu’une équipe de développement doit pouvoir accéder uniquement à certains ressources.
- Un autre département peut vouloir visualiser des machines virtuelles sans avoir la possibilité de modifier la configuration des clusters.
Rancher apporte son expertise de plateforme Kubernetes, où le contrôle d’accès basé sur les rôles est intégré à l’architecture.
Le résultat est particulièrement pertinent pour les entreprises ayant plusieurs sites : l’expansion physique de l’infrastructure ne doit pas obligatoirement augmenter proportionnellement le nombre de points d’administration.
Kubernetes fonctionnant sur les machines virtuelles Harvester
La seconde partie de l’intégration est plus technique et particulièrement intéressante.
Rancher ne se limite pas à la gestion d’Harvester.
Il peut également l’utiliser comme fournisseur d’infrastructure pour déployer Kubernetes via le Harvester Node Driver, aussi appelé SUSE Virtualization Node Driver dans la documentation récente.
Le fonctionnement ressemble conceptuellement à l’utilisation d’un fournisseur cloud.
Rancher a besoin de machines pour construire un cluster Kubernetes. En cloud public, il s’agirait par exemple d’instances EC2 d’Amazon ou de machines virtuelles d’un autre fournisseur. Avec le Node Driver d’Harvester, ces VM sont créées directement dans l’infrastructure HCI.
Ce processus peut être résumé ainsi :
Serveurs physiques → Harvester → Machines virtuelles → RKE2/K3s → Applications
Rancher pilote l’ensemble depuis le haut.
La documentation d’Harvester 1.9 précise que ce contrôleur permet de créer des clusters en utilisant RKE2 ou K3s. Elle indique aussi que les machines doivent être configurées en réseau VLAN, avec une assignation DHCP ou via la fonctionnalité Managed DHCP.
Il faut porter une attention particulière aux versions.
La documentation indique que le Node Driver est activé par défaut depuis Rancher 2.6.3, mais certaines pages pour d’autres versions mentionnent qu’il est désactivé par défaut. Avant de déployer, il est donc recommandé de vérifier la compatibilité et la documentation exacte selon la version utilisée.
Cela illustre bien pourquoi une architecture de production ne doit pas simplement copier une procédure d’une version à une autre sans vérification.
Stockage et équilibrage de charge dans les clusters invités
Créer les machines virtuelles n’est qu’une étape. Un Kubernetes de production nécessite aussi du stockage persistant et des mécanismes pour publier des services.
L’intégration avec Harvester offre un Cloud Provider qui relie les clusters Kubernetes invités à l’infrastructure sous-jacente.
SUSE documente la prise en charge du storage passthrough et du load balancing. En déployant RKE2 via le Node Driver en sélectionnant Harvester comme cloud provider, le système peut automatiquement installer les composants CSI (Container Storage Interface) et CCM (Cloud Controller Manager) nécessaires.
Le CSI permet aux charges Kubernetes de demander un stockage supporté par l’infrastructure Harvester.
Le Cloud Provider permet aussi d’utiliser des services Kubernetes de type :
type: LoadBalancerHarvester peut alors provisionner un équilibrage de charge pour exposer le service. La solution supporte différents mécanismes d’attribution d’adresses, comme DHCP ou pools IP.
Cela évite d’avoir à gérer manuellement chaque intégration après la création du cluster.
Harvester ne devient pas un équivalent exact d’AWS, Azure ou Google Cloud, mais reproduit une partie de leur expérience d’infrastructure programmable dans son propre centre de données.
C’est là que réside une partie de l’intérêt de cette solution combinée.
La virtualisation traditionnelle et le cloud native commencent à converger
Pendant de nombreuses années, machines virtuelles et Kubernetes ont évolué en deux couches relativement séparées :
- De leurs côtés, VMware, Hyper-V, KVM, Proxmox et autres plateformes de virtualisation.
- De l’autre, Kubernetes en tant que plateforme pour conteneurs.
Harvester part d’une idée différente : utiliser Kubernetes aussi comme socle pour virtualiser, en intégrant des technologies comme KubeVirt, et en la combinant avec du stockage distribué.
Rancher ajoute alors une couche de gestion.
Une organisation peut ainsi maintenir des applications traditionnelles dans des machines virtuelles tout en créant des clusters Kubernetes pour des applications cloud native, sur la même infrastructure physique.
Ce modèle peut particulièrement s’avérer intéressant lors de processus de modernisation.
En effet, toutes les applications ne sont pas forcément transformables en conteneurs, ni même nécessaires.
Une entreprise peut continuer à faire tourner certains workloads en VM, tout en déployant de nouveaux services via RKE2, sans avoir à gérer deux systèmes physiques totalement distincts.
Le concept décrit dans cette documentation repose précisément sur cette division des responsabilités : Harvester pour la virtualisation, Kubernetes/RKE2 pour l’orchestration, Rancher pour la gestion globale.
Le choix de l’emplacement d’installation de Rancher est aussi déterminant
Centraliser la gestion soulève une question inévitable : que faire si Rancher dépend du même environnement qu’il doit administrer ?
Pour les environnements de test, il peut être tentant de déployer Rancher dans des machines virtuelles hébergées sur Harvester.
Cela fonctionne et permet de réduire les ressources pour une première démarche de laboratoire.
Mais cette approche crée une dépendance.
En cas d’incident grave sur le cluster Harvester hébergeant Rancher, toute l’infrastructure et la console de gestion peuvent devenir inaccessibles.
La documentation de Harvester recommande aussi que l’installation de Rancher via Docker ne doit pas être utilisée en environnement production : elle est réservée aux phases d’évaluation et de test.
Dans un contexte où la continuité de la gestion est essentielle, il est judicieux de dissocier ces deux couches et de déployer Rancher selon une architecture hautement disponible adaptée.
Ce n’est pas uniquement une question technique :
Une plateforme centralisée simplifie la gestion, mais concentre aussi les responsabilités. La disponibilité, les sauvegardes, l’identité, les certificats, le DNS, la connectivité — tout cela doit être pris en compte dans la conception de l’infrastructure.
Une alternative pertinente face aux évolutions de la virtualisation
Rancher et Harvester se positionnent également sur un marché désormais plus ouvert aux alternatives de virtualisation qu’il y a quelques années.
Les bouleversements chez VMware après son rachat par Broadcom ont incité de nombreuses entreprises à réévaluer licences, coûts et architectures. Proxmox VE, OpenStack, Nutanix AHV, et d’autres alternatives ont gagné en popularité.
Harvester propose une approche différente.
Il ne cherche pas à être juste un hyperviseur parmi d’autres.
Son architecture, étroitement liée à Kubernetes et Rancher, peut séduire des organisations déjà engagées dans des stratégies cloud native ou souhaitant gérer machines virtuelles et clusters Kubernetes dans une démarche commune.
Cela ne signifie pas que Harvester soit la meilleure option pour tout environnement VMware.
Migrer une plateforme de virtualisation demande une analyse approfondie : stockage, réseau, sauvegarde, reprise après sinistre, haute disponibilité, compatibilité applicative, compétences de l’équipe et support technique.
L’intérêt de Rancher + Harvester apparaît surtout lorsque< предст পরিষ্কার কীভাবে চট্টীয় ক্রমটি চালানো যায় না।
Les deux couches de virtualization restent sous leur responsabilité, mais la couche de gestion devient une seule couche cohérente pour toute l’infrastructure.
Et quand on passe de quelques localisations à plusieurs dizaines, disposer d’une gestion centralisée devient non seulement une commodité, mais une nécessité stratégique.
Questions fréquentes
Quelle différence entre Rancher et Harvester ?
Harvester est une plateforme HCI de virtualisation basée sur Kubernetes, tandis que Rancher est spécialisé dans la gestion de Kubernetes et de multiples clusters. Leur intégration permet de gérer des installations Harvester et d’utiliser son infrastructure pour déployer des clusters Kubernetes.
Peut-on gérer plusieurs clusters Harvester depuis Rancher ?
Oui. Rancher Virtualization Management permet d’importer plusieurs clusters Harvester et d’accéder à des ressources comme les hôtes, machines virtuelles, images et volumes par une gestion centralisée.
Rancher peut-il créer des Kubernetes dans Harvester ?
Oui. Le Harvester/SUSE Virtualization Node Driver permet de provisionner des machines virtuelles sur Harvester et de les utiliser comme nœuds pour les clusters RKE2 ou K3s, selon les versions et supports disponibles.
Rancher doit-il être déployé sur le même Harvester qu’il administre ?
Cela peut être pratique pour des environnements de test, mais en production, il est conseillé d’adopter une architecture où la plateforme de gestion et l’infrastructure sont séparées afin d’éviter toute dépendance critique. La configuration précise doit suivre les recommandations et compatibilités selon les versions déployées.
