Het beheren van een enkele Harvester-cluster is relatief eenvoudig. Problemen ontstaan wanneer een organisatie de infrastructuur verdeelt over meerdere datacenters, filialen of edge-omgevingen, waardoor elk cluster als een geïsoleerde enclave gaat functioneren. Rancher maakt het mogelijk om meerdere Harvester-clusters te importeren en centraal te beheren, waarbij virtuele machines, authenticatie, toegangscontrole en Kubernetes-voorzieningen op de eigen HCI-infrastructuur worden geïntegreerd.
De kernpunten van Rancher + Harvester in 20 seconden
- Rancher kan meerdere Harvester-clusters importeren en hun toegang centraliseren via Virtualization Management.
- Vanaf dat niveau wordt beheer uitgevoerd over resources zoals hosts, virtuele machines, images en volumes.
- De integratie benut de authenticatie en RBAC-functies van Rancher.
- De node driver maakt het mogelijk om RKE2 of K3s clusters te deployen op virtuele machines van Harvester.
- Voor productieomgevingen is het aan te raden om de beheerlaag los te koppelen van de infrastructuur die wordt beheerd.
De combinatie is bijzonder relevant in een tijd waarin vele organisaties hun virtualisatieplatformen herzien. Harvester benadert het vraagstuk vanuit een andere architectuur dan traditionele hypervisors: het is een open source HCI-platform (Hyper-Converged Infrastructure) gebouwd op Kubernetes dat virtualisatie en gedistribueerde opslag combineert. Rancher overkoepelt het beheer van Kubernetes-omgevingen en faciliteert gecentraliseerde controle over verschillende Harvester-instellingen.
Dit betekent niet dat beide producten hetzelfde doen.
Harvester beheert de virtuele infrastructuur. Rancher bestuurt de verschillende Kubernetes-omgevingen en kan Harvester gebruiken als fundament voor het creëren van nieuwe Kubernetes-clusters.
Deze scheiding verduidelijkt waarom SUSE beide oplossingen integreert.
Van vijf Harvester-clusters naar één centraal beheerpunt
Een Harvester-cluster beschikt over een eigen interface om hosts, netwerken, opslag en virtuele machines te beheren.
Met één installatie kan dit voldoende zijn.
De situatie verandert zodra een organisatie bijvoorbeeld twee datacenters en meerdere kantoren met lokale infrastructuur bezit. Het onafhankelijk beheren van elk cluster betekent toegang tot verschillende consoles en het uitvoeren van duplicerende beheertaken.
Rancher Virtualization Management beoogt dit probleem te verminderen.
Volgens de officiële documentatie maakt het mogelijk om meerdere Harvester-clusters te importeren en beheren, ze te benaderen vanuit Rancher en gebruik te maken van de authenticatie- en RBAC-mogelijkheden van het platform.
Een belangrijk detail voor beheerders die de integratie testen:
Een Harvester-cluster moet worden geïmporteerd via:
Virtualization Management
en niet via de gebruikelijke Cluster Management-interface.
Deze scheiding is bewust door Rancher aangebracht. Hoewel Harvester op Kubernetes is gebouwd, heeft de oplossing een virtuele infrastructuur-specifieke rol. Met de standaard ingeschakelde feature flag worden Harvester-clusters niet weergegeven binnen de zichtbaarheid voor standaard Kubernetes clusters.
Vanaf Virtualization Management kunnen vervolgens resources zoals hosts, virtuele machines, images en volumes worden benaderd van de geïmporteerde clusters.
Dit brengt de ervaring dichterbij het concept van single pane of glass: verschillende infrastructuren vanuit één centrale beheerslaag zichtbaar maken.
Het betekent niet dat alle clusters fysiek tot één worden samengevoegd. Elke Harvester-implementatie blijft onafhankelijk; de centralisatie betreft de beheerslaag.
Hoe registreer je Harvester in Rancher?
Het importproces legt de verbinding tussen beide systemen.
In Rancher wordt een registratieverzoek aangemaakt in Virtualization Management en worden de benodigde gegevens voor registratie verkregen. In Harvester bestaat hiervoor een parameter:
cluster-registration-url
die de URL specificeert die wordt gebruikt om het cluster te importeren in Rancher en beheer over meerdere clusters mogelijk te maken.
De officiële documentatie van Harvester beschrijft ook de procesgang via Kubernetes-resources. Rancher genereert een ClusterRegistrationToken, waarvan een manifestUrl wordt verkregen. Dit wordt vervolgens geconfigureerd als cluster-registration-url in Harvester.
Wanneer de registratie voltooid is, verschijnt in Harvester een cattle-cluster-agent within de namespace cattle-system. Deze agent verzorgt de communicatie met Rancher.
Een praktisch gevolg hiervan is dat Rancher niet alleen Harvester ziet als een algemeen Kubernetes-systeem, maar gebaseerd op de specifieke integratie dat ook beter kan beheren.
Voor operationele overwegingen: in omgevingen zonder directe internettoegang kan het nodig zijn om de juiste rancher-agent-images vooraf te voorzien via een privé register of handmatig op de nodes te laden.
Identiteit binnen verschillende infrastructuren
Het centraliseren van de beheerconsole heeft weinig zin als na het centraliseren de gebruikers en permissies nog altijd lokaal en onafhankelijk moeten worden beheerd.
Hier komt een andere kracht van Rancher om de hoek kijken.
De integratie met Harvester benut de authenticatie, RBAC en multi-tenancy functies van Rancher. SUSE presenteert deze functies als voordelen van Virtualization Management.
In plaats van de identiteit als een los onderdeel van elke cluster te beschouwen, kan een organisatie beleid toepassen voor toegangsbeheer op één gedeeld niveau.
Dit is vooral relevant bij uiteenlopende gebruikersprofielen:
- Een infrastructuurbeheerder met uitgebreide rechten.
- Een ontwikkelingsteam dat slechts toegang nodig heeft tot specifieke resources.
- Een afdeling die virtuele machines mag zien maar niet aanpassingen mag maken aan de clusterconfiguratie.
Rancher brengt hier diens ervaring op het gebied van Kubernetes-beheer en role-based access control in.
De meerwaarde voor organisaties met meerdere locaties is dat fysieke uitbreiding niet automatisch betekent dat ook de beheerspunten in dezelfde mate moeten toenemen.
Kubernetes draait op de virtuele machines van Harvester
De tweede, meer technisch interessante, component van de integratie.
Rancher beperkt zich niet tot het beheer van Harvester zelf.
Het kan ook worden ingezet als infrastructuuraanbieder voor het uitrollen van Kubernetes clusters via de Harvester Node Driver, dat in recente documentatie ook bekendstaat als SUSE Virtualization Node Driver.
De werking lijkt conceptueel op het gebruik van een cloudprovider.
Rancher heeft virtuele machines nodig om een Kubernetes-cluster te bouwen. In een openbaar cloud kunnen dat EC2-instances van Amazon of virtuele machines van andere aanbieders zijn. Met de Harvester Node Driver worden deze virtuele machines binnen de eigen HCI-infrastructuur aangemaakt.
Het proces kan worden weergegeven als:
Fysieke servers → Harvester → Virtuele machines → RKE2/K3s → Applicaties
Rancher beheert dit geheel vanaf de top.
De huidige documentatie van Harvester 1.9 geeft aan dat de controller het mogelijk maakt om clusters te maken met RKE2 of K3s. Daarnaast wordt vermeld dat de virtuele machines moeten zijn verbonden via een VLAN-netwerk en dat ze hun IP-adressen kunnen krijgen via DHCP of de Managed DHCP-functie.
Let wel op de versiecompatibiliteit:
Harvester documenteert dat de Node Driver standaard ingeschakeld is in Rancher vanaf versie 2.6.3. Sommige documentatie van Rancher voor andere versies beschrijft deze optie echter als uitgeschakeld. Het is dus verstandig om vooraf de compatibiliteitsmatrix en documentatie te controleren afhankelijk van de gebruikte versie.
Dit benadrukt dat een upgrade of productie-implementatie niet zomaar op basis van een gids voor een andere versie moet worden uitgevoerd.
Opslag en load balancing voor de geïnfecteerde clusters
Het aanmaken van virtuele machines is slechts een deel van het verhaal.
Een productie Kubernetes-cluster vereist ook persistent opslag en mechanismen voor het publiciseren van services.
De Harvester-integratie bevat een Cloud Provider die de gekoppelde Kubernetes-clusters verbindt met de onderliggende infrastructuur.
SUSE documenteert ondersteuning voor storage passthrough en load balancers. Bij het uitrollen van RKE2 met de Node Driver, waarbij Harvester als cloud provider wordt gekozen, kunnen de benodigde CSI (Container Storage Interface)- en CCM (Cloud Controller Manager)-componenten automatisch worden geïnstalleerd.
Het CSI maakt het mogelijk voor Kubernetes workloads om opslag van Harvester te gebruiken.
Daarnaast kan de Cloud Provider zorgen voor services van het type:
type: LoadBalancerHarvester kan op dat moment een load balancer toewijzen om de service te exposeren. De implementatie ondersteunt diverse toewijzingsmechanismen, zoals DHCP en IP-pools.
Dit voorkomt handmatige configuraties na het clusterdeployment.
Harvester wordt niet identiek aan grote cloud providers zoals AWS, Azure of Google Cloud, maar bootst een stuk van die programmatische infrastructuur binnen de eigen datacenteromgeving na.
Dat draagt voor een deel bij aan de kracht van deze gecombineerde oplossing.
Van tradionele virtualisatie tot cloud-native integratie
Jarenlang evolueerden virtuele machines en Kubernetes grotendeels onafhankelijk van elkaar:
- Hypervisors zoals VMware, Hyper-V, KVM, Proxmox en andere.
- Kubernetes als platform voor container-orkestratie.
Harvester introduceert een andere visie: Kubernetes gebruiken als fundament voor virtualisatie, onder meer via KubeVirt, gecombineerd met gedistribueerde opslag.
Rancher brengt bovenop het beheer.
Zo kunnen organisaties bestaande toepassingen in virtuele machines behouden en tegelijkertijd nieuwe cloud-native workloads op Kubernetes draaien, allemaal binnen dezelfde fysieke infrastructuur.
Dat is bijzonder tijdens transformatie- en modernisatieprocessen.
Niet alle toepassingen kunnen of hoeven in containers te worden gemigreerd.
Soms is het wenselijk toepassingen als VM te blijven draaien en tegelijkertijd nieuwe services te ontwikkelen op Kubernetes.
De aanpak zoals beschreven in de documentatie ondersteunt die flexibele strategie, waarbij Harvester voor virtualisatie zorgt, Kubernetes voor orkestratie en Rancher voor beheer.
De locatie van Rancher installatie is bepalend
Door centrale beheer te willen realiseren, komt de vraag naar voren: wat gebeurt er als Rancher op dezelfde infrastructuur draait als waarop het moet worden beheerd?
Voor testdoeleinden is het eenvoudig om Rancher op virtuele machines binnen Harvester te zetten.
Dat werkt en beperkt de resource-vereisten voor het opzetten van een lab.
Maar het introduceert een afhankelijkheid.
Bij een ernstige storing in het Harvester-cluster dat Rancher host, kan de hele beheerslaag verloren gaan.
De documentatie raadt bovendien aan dat Rancher niet via Docker voor productie wordt ingezet, maar alleen voor evaluatie en testen.
Voor productieomgevingen waar continue beschikbaarheid vereist is, is het verstandig om de beheerlaag te scheiden van de infrastructuur en Rancher met een high-availability architectuur te implementeren.
De keuze is niet alleen technisch:
Een gecentraliseerd platform vereenvoudigt beheer, maar verhoogt ook de afhankelijkheden. Backup, identity management, certificaten, DNS en connectiviteit worden onderdeel van het infra-ontwerp.
Een perspectief dat voordeel biedt in het licht van hervormingen in virtualisatie
Rancher en Harvester hebben een steeds breder speelveld, mede door veranderingen binnen de virtualisatiebranche:
- Na de overname van VMware door Broadcom zijn veel bedrijven hun licentie- en kostenstructuren herzien. Alternatieven zoals Proxmox VE, OpenStack, Nutanix AHV winnen aan zichtbaarheid.
- Harvester biedt een ander soort oplossing: geen volledige hypervisor, maar een Kubernetes-gebaseerde aanpak die virtualisatie en opslag combineert.
Deze aanpak is interessant voor organisaties die al gebruik maken van cloud native technologieën of binnen een uniform beheer willen blijven: virtuele machines en Kubernetes onder één paraplu.
Het is geen automatische vervanger voor alle VMware-omgevingen en migraties vragen afwegingen: opslag, netwerken, backups, disaster recovery, compatibiliteit, teams, support.
De kracht van Rancher + Harvester ligt vooral in situaties waarin de organisatie niet alleen zoekt naar waar de virtuele machines worden uitgevoerd, maar ook naar de manier waarop de volgende generatie workloads kunnen worden beheerd.
Onderliggend blijft virtuele infrastructuur bestaan, maar de beheerlaag verandert.
Wanneer meerdere locaties worden toegevoegd, wordt die beheerlaag dé sleutelfactor voor schaalbaarheid en flexibiliteit.
Veelgestelde vragen
Wat is het verschil tussen Rancher en Harvester?
Harvester is een HCI-platform voor virtualisatie gebouwd op Kubernetes, terwijl Rancher zich richt op het beheer van Kubernetes-omgevingen en clusters. De integratie stelt om een organisatie Harvester te beheren en haar infrastructuur voor het uitrollen van Kubernetes-clusters te gebruiken.
Kunnen meerdere Harvester-clusters vanuit Rancher worden beheerd?
Ja. Rancher Virtualization Management maakt het mogelijk om meerdere Harvester-clusters te importeren en resources zoals hosts, virtuele machines, images en volumes vanuit een centrale laag te beheren.
Kan Rancher Kubernetes-clusters creëren binnen Harvester?
Ja. De Harvester/SUSE Virtualization Node Driver maakt het mogelijk virtuele machines te provisioneren als knooppunten voor RKE2 of K3s clusters, afhankelijk van de versie en ondersteuning.
Moet Rancher op dezelfde infrastructuur worden geïnstalleerd als Harvester?
Voor test- en ontwikkelomgevingen kan dit handig zijn, maar voor productie wordt aanbevolen een architectuur te gebruiken die de afhankelijkheid tussen beheer en infrastructuur minimaliseert, inclusief high-availability configuraties en scheiding van services.