Managing a single Harvester cluster is relatively straightforward. The challenge arises when a company distributes infrastructure across multiple data centers, branch offices, or edge environments, and each cluster begins to operate as an island. Rancher allows importing and managing multiple Harvester clusters from a centralized layer, combining virtual machine management with authentication, access control, and Kubernetes provisioning on the underlying HCI infrastructure.
The key points of Rancher + Harvester in 20 seconds
- Rancher can import multiple Harvester clusters and centralize access via Virtualization Management.
- This layer manages resources such as hosts, virtual machines, images, and volumes.
- The integration leverages Rancher’s authentication and role-based access control (RBAC).
- Its node driver enables deploying RKE2 or K3s clusters on Harvester virtual machines.
- For production, it’s advisable to separate the infrastructure management layer you administer.
This combination is particularly relevant at a time when many organizations are reviewing their virtualization platforms. Harvester addresses the issue from a different architecture than traditional hypervisors: it’s an open-source HCI (Hyper-Converged Infrastructure) platform built on Kubernetes that integrates virtualization and distributed storage. Rancher adds a layer of Kubernetes environment management and centralized control across multiple Harvester deployments.
This does not mean both products do the same thing.
Harvester manages virtualized infrastructure. Rancher governs the different environments and can use Harvester as the infrastructure foundation on which to create new Kubernetes clusters.
This separation helps clarify why SUSE integrates them.
From five Harvester clusters to a single management point
A Harvester cluster has its own interface for managing hosts, networks, storage, and virtual machines.
A single installation may suffice in some cases.
However, the situation changes if a company, for example, has two data centers and several branch offices with local infrastructure. Managing each cluster independently involves accessing different consoles and duplicating administrative tasks.
Rancher Virtualization Management aims to mitigate this issue.
Official documentation confirms that it allows importing and managing multiple Harvester clusters, accessing them from Rancher, and utilizing the platform’s authentication and RBAC capabilities.
There is also an important detail for administrators testing the integration.
A Harvester cluster must be imported from:
Virtualization Management
and not from the conventional Cluster Management screen.
Rancher intentionally separates this. Although Harvester is built on Kubernetes, its role is to provide a virtualization platform. With the corresponding feature flag enabled — which is the default setting — Rancher filters Harvester clusters out of views intended for conventional Kubernetes clusters.
The Virtualization Management interface then allows access to resources like hosts, virtual machines, images, and volumes of the imported clusters.
This brings the experience closer to the familiar concept of single pane of glass: different infrastructures visible from a common management layer.
It does not mean that all clusters become physically unified. Each Harvester installation continues to be independent. What is centralized is their management.
How Harvester is registered in Rancher
The import procedure establishes the connection between the two systems.
From Rancher, you create the corresponding entry in Virtualization Management and obtain the registration information. In Harvester, there is the parameter:
cluster-registration-url
which precisely defines the URL used to import the cluster into Rancher and enable multi-cluster management.
Harvester’s current documentation also describes the process using Kubernetes resources. Rancher generates a ClusterRegistrationToken, from which a manifestUrl is obtained, and this value is later configured as cluster-registration-url in Harvester.
Once registration is established, a cattle-cluster-agent appears in Harvester within the cattle-system namespace. This agent handles the necessary communication with Rancher.
The practical implication is interesting: Rancher does not need to treat each Harvester simply as another generic Kubernetes environment.
There is a specifically designed integration for that platform.
Operational considerations also apply. For example, in environments without direct internet access, it might be necessary to pre-provision the appropriate rancher-agent image via a private registry or load it onto nodes.
A unified identity for multiple infrastructures
Centralizing the console has little value if user management and permissions have to be maintained separately at each site.
This highlights another advantage of Rancher.
The integration with Harvester can leverage Rancher’s authentication, RBAC, and multi-tenancy features. SUSE presents these functions as key benefits of Virtualization Management.
Rather than viewing identity as a separate element for each cluster, the organization can enforce access policies from a common layer.
This is particularly relevant when different user profiles exist.
An infrastructure administrator may require broad permissions, while a development team might only need access to certain resources. Another department may need visibility into virtual machines without the authority to modify cluster settings.
Rancher’s expertise as a Kubernetes management platform—with role-based access control integrated—facilitates this.
This approach is especially beneficial for companies with multiple locations: physical expansion of infrastructure does not necessarily mean multiplying management points proportionally.
Kubernetes running on Harvester virtual machines
The second part of the integration is technically more intriguing.
Rancher does not limit itself to managing Harvester.
It can also use Harvester as an infrastructure provider to deploy Kubernetes via the Harvester Node Driver, known in newer documentation as the SUSE Virtualization Node Driver.
Conceptually, it’s similar to using a cloud provider.
Rancher requires machines to build a Kubernetes cluster. In a public cloud, these could be Amazon EC2 instances or virtual machines from another provider. With Harvester’s Node Driver, those virtual machines are created directly within the HCI infrastructure.
The process can be visualized as:
Physical Servers → Harvester → Virtual Machines → RKE2/K3s → Applications
Rancher manages the process from the top down.
Harvester 1.9’s current documentation states that the controller allows creating clusters using RKE2 or K3s. It also specifies that the machines require a VLAN network and can receive IP addresses via an existing DHCP server or the Managed DHCP feature.
Attention must be paid to version compatibility.
Harvester’s documentation indicates that the Node Driver is enabled by default from Rancher 2.6.3, but some pages for other Rancher versions describe it as disabled by default. Before planning a deployment, it’s wise to review the compatibility matrix and specific documentation for the versions in use.
This highlights why a production architecture should not merely copy a guide for another version.
Storage and load balancing extend to guest clusters
Creating virtual machines is only part of the challenge.
A production Kubernetes setup also requires persistent storage and mechanisms to expose services.
Harvester’s integration includes a Cloud Provider that connects guest Kubernetes clusters to the underlying infrastructure.
SUSE documents support for storage passthrough and load balancers. When deploying RKE2 via the Node Driver, selecting Harvester as the cloud provider enables the automatic installation of necessary CSI (Container Storage Interface) and CCM (Cloud Controller Manager) components.
CSI allows Kubernetes workloads to request storage backed by Harvester infrastructure.
The Cloud Provider also supports Kubernetes services of type:
type: LoadBalancerHarvester then can allocate a load balancer to expose the service. The implementation supports various address assignment mechanisms, including DHCP and IP pools.
This streamlines integration post-cluster creation rather than requiring manual configuration.
While Harvester does not make it identical to AWS, Azure, or Google Cloud, it reproduces a part of the programmable infrastructure experience within the local data center.
And that is part of its appeal.
Traditional virtualization and cloud-native start to merge
For years, virtual machines and Kubernetes evolved as two relatively separate layers.
On one side were VMware, Hyper-V, KVM, Proxmox, and other virtualization platforms.
On the other, Kubernetes emerged as a container management platform.
Harvester introduces a different idea: using Kubernetes as a foundation for virtualization via technologies like KubeVirt, combined with distributed storage.
Rancher adds the management layer.
Organizations can run traditional applications within virtual machines while creating Kubernetes clusters for cloud-native workloads on the same physical infrastructure.
This approach can be especially valuable during modernization processes.
Not all applications can be containerized, nor do they need to be.
A company may keep certain workloads as virtual machines and deploy new services on RKE2 without maintaining entirely separate physical platforms.
The design outlined in the documentation relies on this division: Harvester handles virtualization, Kubernetes/RKE2 manages orchestration, and Rancher offers overarching management.
Where Rancher is installed matters too
Central management raises an inevitable question: what if Rancher depends on the same environment it is supposed to manage?
For testing, deploying Rancher inside VMs hosted on Harvester can be tempting.
It works and reduces the resources needed for a lab setup.
However, it creates a dependency.
If the Harvester cluster hosting Rancher experiences a severe incident, the organization could lose both infrastructure and the management console simultaneously.
Harvester’s documentation also warns that deploying Rancher via Docker is not recommended for production, reserving that approach for evaluation and testing.
In environments prioritizing continuous management, separating layers and deploying Rancher with high-availability architecture is advisable.
This is not only a technical issue.
A centralized platform simplifies administration but concentrates responsibilities. Its availability, backups, identity management, certificates, DNS, and network connectivity all become part of the infrastructure design.
An alternative worth considering given virtualization shifts
Rancher and Harvester are making inroads into a much more receptive virtualization market than in previous years.
Changes around VMware, especially after its acquisition by Broadcom, have prompted many organizations to review licensing, costs, and architectures. Alternatives like Proxmox VE, OpenStack, Nutanix AHV, and others have gained visibility
Harvester offers a different proposition.
It’s not trying to be just another hypervisor.
Its architecture’s close ties with Kubernetes and Rancher may appeal to organizations already using cloud native technologies or seeking unified management of virtual machines and Kubernetes.
That doesn’t automatically make it the best choice for every VMware environment.
Migrating a virtualization platform involves re-evaluating storage, networking, backups, disaster recovery, high availability, application compatibility, operational knowledge, and support arrangements.
The strength of Rancher + Harvester lies especially in organizations that do not want to limit their decision to where to run virtual machines but also how to manage the next generation of Kubernetes workloads.
Virtualization remains underneath.
What changes is the layer from which governance and management are applied.
And as infrastructure expands from a cluster to five, ten, or dozens of locations, having a common layer becomes more than just a convenience; it’s a strategic necessity.
Frequently Asked Questions
What’s the difference between Rancher and Harvester?
Harvester is an HCI virtualization platform built on Kubernetes, while Rancher focuses on Kubernetes management and multi-cluster orchestration. Their integration enables managing Harvester deployments and leveraging its infrastructure to deploy Kubernetes clusters.
Can Rancher manage multiple Harvester clusters?
Yes. Rancher Virtualization Management supports importing multiple Harvester clusters and accessing resources like hosts, virtual machines, images, and volumes from a centralized management layer.
Can Rancher create Kubernetes clusters on Harvester?
Yes. The Harvester/SUSE Virtualization Node Driver allows provisioning VMs on Harvester and using them as nodes for RKE2 or K3s clusters, depending on versions and support.
Should Rancher be installed on the same Harvester it manages?
It may be practical for testing environments, but in production, it’s advisable to separate management and infrastructure layers to avoid dependencies. The specific architecture should follow compatibility matrices and best practices based on the deployment’s versions.
