Gestionar un único clúster de Harvester resulta relativamente sencillo. El problema aparece cuando una empresa distribuye la infraestructura entre varios centros de datos, delegaciones o entornos edge y cada clúster empieza a funcionar como una isla. Rancher permite importar y administrar múltiples clústeres Harvester desde una capa centralizada, combinando gestión de máquinas virtuales con autenticación, control de acceso y aprovisionamiento de Kubernetes sobre la propia infraestructura HCI.
Las claves de Rancher + Harvester en 20 segundos
- Rancher puede importar varios clústeres Harvester y centralizar su acceso desde Virtualization Management.
- Desde esa capa se gestionan recursos como hosts, máquinas virtuales, imágenes y volúmenes.
- La integración aprovecha la autenticación y el control de acceso basado en roles (RBAC) de Rancher.
- Su node driver permite desplegar clústeres RKE2 o K3s sobre máquinas virtuales de Harvester.
- Para producción conviene separar la capa de gestión de la infraestructura que administra.
La combinación tiene interés en un momento en el que muchas organizaciones están revisando sus plataformas de virtualización. Harvester aborda el problema desde una arquitectura diferente a los hipervisores tradicionales: es una plataforma HCI (Hyper-Converged Infrastructure) open source construida sobre Kubernetes que integra virtualización y almacenamiento distribuido. Rancher añade por encima la administración de los entornos Kubernetes y la gestión centralizada de diferentes instalaciones de Harvester.
No significa que ambos productos hagan lo mismo.
Harvester administra la infraestructura virtualizada. Rancher gobierna los diferentes entornos y puede utilizar Harvester como infraestructura sobre la que crear nuevos clústeres Kubernetes.
Esa separación permite entender mejor por qué SUSE los integra.
De cinco clústeres Harvester a un único punto de gestión
Un clúster Harvester dispone de su propia interfaz para administrar hosts, redes, almacenamiento y máquinas virtuales.
Con una sola instalación puede ser suficiente.
La situación cambia si una empresa dispone, por ejemplo, de dos centros de datos y varias oficinas con infraestructura local. Mantener cada clúster independientemente implica acceder a diferentes consolas y reproducir parte de las tareas administrativas.
Rancher Virtualization Management pretende reducir ese problema.
La documentación oficial confirma que permite importar y gestionar múltiples clústeres Harvester, acceder a ellos desde Rancher y aprovechar las capacidades de autenticación y RBAC de la plataforma.
Hay además un detalle importante para los administradores que prueben la integración.
Un clúster Harvester debe importarse desde:
Virtualization Management
y no desde la pantalla convencional:
Cluster Management
Rancher hace esta separación deliberadamente. Aunque Harvester está construido sobre Kubernetes, su función es proporcionar una plataforma de virtualización. Con el feature flag correspondiente activado, que es la configuración predeterminada, Rancher filtra los clústeres Harvester de las vistas destinadas a clústeres Kubernetes convencionales.
La interfaz de Virtualization Management permite posteriormente acceder a recursos como hosts, máquinas virtuales, imágenes y volúmenes de los clústeres importados.
Esto acerca la experiencia al conocido concepto de single pane of glass: diferentes infraestructuras visibles desde una capa común de administración.
No implica que todos los clústeres se conviertan físicamente en uno. Cada instalación Harvester continúa siendo independiente. Lo que se centraliza es su gestión.
Cómo se registra Harvester en Rancher
El procedimiento de importación establece la relación entre ambos sistemas.
Desde Rancher se crea la entrada correspondiente en Virtualization Management y se obtiene la información de registro. En Harvester existe el parámetro:
cluster-registration-url
que define precisamente la URL utilizada para importar el clúster en Rancher y habilitar su gestión multiclúster.
La documentación actual de Harvester describe también el proceso mediante recursos Kubernetes. Rancher genera un ClusterRegistrationToken, del que se obtiene un manifestUrl, y ese valor se configura posteriormente como cluster-registration-url en Harvester.
Cuando se establece el registro aparece en Harvester un cattle-cluster-agent dentro del espacio de nombres cattle-system. Este agente se encarga de la comunicación necesaria con Rancher.
El modelo tiene una consecuencia práctica interesante: Rancher no necesita tratar cada Harvester simplemente como otro Kubernetes genérico.
Existe una integración específicamente diseñada para esa plataforma.
También hay consideraciones operativas. Por ejemplo, en instalaciones sin acceso directo a Internet puede ser necesario proporcionar previamente la imagen adecuada de rancher-agent mediante un registro privado o cargarla en los nodos.
Una identidad para diferentes infraestructuras
Centralizar la consola tiene poco valor si después hay que mantener usuarios y permisos independientemente en cada ubicación.
Aquí aparece otra de las ventajas de Rancher.
La integración con Harvester puede aprovechar las capacidades de autenticación, RBAC y multi-tenancy de Rancher. SUSE presenta precisamente estas funciones como una de las ventajas de Virtualization Management.
En lugar de considerar la identidad como un elemento separado de cada clúster, la organización puede aplicar una política de acceso desde una capa común.
Eso resulta especialmente relevante cuando existen distintos perfiles.
Un administrador de infraestructura puede necesitar permisos amplios, mientras un equipo de desarrollo puede requerir acceso únicamente a determinados recursos. Otro departamento puede necesitar visualizar máquinas virtuales sin capacidad para modificar la configuración del clúster.
Rancher aporta aquí su experiencia como plataforma de gestión Kubernetes, donde el control de acceso basado en roles forma parte de la arquitectura habitual.
El resultado es especialmente interesante para empresas con varias ubicaciones: la expansión física de la infraestructura no tiene por qué obligar a multiplicar en la misma proporción sus puntos de administración.
Kubernetes ejecutándose sobre las máquinas virtuales de Harvester
La segunda parte de la integración es técnicamente más interesante.
Rancher no se limita a administrar Harvester.
También puede utilizarlo como proveedor de infraestructura para desplegar Kubernetes mediante el Harvester Node Driver, denominado SUSE Virtualization Node Driver en documentación más reciente.
El funcionamiento se parece conceptualmente a utilizar un proveedor cloud.
Rancher necesita máquinas para construir un clúster Kubernetes. En un cloud público podrían ser instancias de Amazon EC2 o máquinas virtuales de otro proveedor. Con el Node Driver de Harvester, esas máquinas virtuales se crean en la propia infraestructura HCI.
El resultado puede representarse así:
Servidores físicos → Harvester → máquinas virtuales → RKE2/K3s → aplicaciones
Rancher administra el proceso desde arriba.
La documentación actual de Harvester 1.9 indica que el controlador permite crear clústeres utilizando RKE2 o K3s. También especifica que las máquinas necesitan una red VLAN y que pueden recibir sus direcciones mediante un servidor DHCP existente o mediante la funcionalidad Managed DHCP.
Hay que prestar atención a las versiones.
La documentación de Harvester indica que el Node Driver está habilitado de forma predeterminada desde Rancher 2.6.3, mientras algunas páginas de Rancher correspondientes a versiones diferentes lo describen como desactivado por defecto. Antes de diseñar un despliegue conviene, por tanto, comprobar la matriz de compatibilidad y documentación correspondiente exactamente a las versiones utilizadas.
Es un buen ejemplo de por qué una arquitectura de producción no debería construirse copiando simplemente una guía correspondiente a otra versión.
Almacenamiento y balanceo llegan también a los clústeres invitados
Crear las máquinas virtuales es solamente una parte del problema.
Un Kubernetes de producción necesita también almacenamiento persistente y mecanismos para publicar servicios.
La integración de Harvester dispone de un Cloud Provider que conecta los clústeres Kubernetes invitados con la infraestructura subyacente.
SUSE documenta soporte para storage passthrough y balanceadores de carga. Cuando se despliega RKE2 mediante el Node Driver seleccionando Harvester como cloud provider, el sistema puede instalar automáticamente los componentes CSI (Container Storage Interface) y CCM (Cloud Controller Manager) necesarios.
El CSI permite que las cargas Kubernetes soliciten almacenamiento respaldado por la infraestructura de Harvester.
El Cloud Provider permite además utilizar servicios Kubernetes de tipo:
type: LoadBalancerHarvester puede asignar entonces un balanceador para exponer el servicio. La implementación admite diferentes mecanismos de asignación de direcciones, entre ellos DHCP y pools de IP.
Esto evita tener que resolver manualmente cada integración después de crear el clúster.
No convierte Harvester en un equivalente idéntico a AWS, Azure o Google Cloud, pero reproduce parte de la experiencia de infraestructura programable dentro del centro de datos propio.
Y ahí está buena parte del atractivo de la combinación.
Virtualización tradicional y cloud native empiezan a encontrarse
Durante años las máquinas virtuales y Kubernetes han evolucionado como dos capas relativamente separadas.
Por un lado estaban VMware, Hyper-V, KVM, Proxmox y otras plataformas de virtualización.
Por otro apareció Kubernetes como plataforma para contenedores.
Harvester parte de una idea distinta: utilizar Kubernetes también como base para proporcionar virtualización mediante tecnologías como KubeVirt y combinarla con almacenamiento distribuido.
Rancher añade la capa de gestión.
Una organización puede mantener aplicaciones tradicionales dentro de máquinas virtuales mientras crea clústeres Kubernetes para aplicaciones cloud native sobre la misma infraestructura física.
Eso puede resultar especialmente interesante durante procesos de modernización.
No todas las aplicaciones pueden convertirse en contenedores.
Ni necesitan hacerlo.
Una empresa puede conservar determinadas cargas como máquinas virtuales y desplegar nuevos servicios sobre RKE2 sin mantener necesariamente dos plataformas físicas completamente diferentes.
El enfoque que describe la documentación aportada se apoya precisamente en esa división de responsabilidades: Harvester para virtualización, Kubernetes/RKE2 para orquestación y Rancher para la administración superior.
El lugar donde se instala Rancher también importa
Centralizar la gestión introduce una pregunta inevitable: ¿qué ocurre si Rancher depende del mismo entorno que debe administrar?
Para pruebas resulta tentador desplegar Rancher dentro de máquinas virtuales alojadas en Harvester.
Funciona y reduce los recursos necesarios para montar un laboratorio.
Pero crea una dependencia.
Si el clúster Harvester que hospeda Rancher sufre una incidencia grave, la organización podría perder simultáneamente parte de la infraestructura y la consola utilizada para gestionarla.
La documentación de Harvester advierte además que una instalación de Rancher mediante Docker no debe utilizarse para producción y reserva ese modelo para evaluación y pruebas.
En entornos donde la continuidad de la gestión sea importante tiene sentido separar ambas capas y desplegar Rancher con la arquitectura de alta disponibilidad adecuada.
La cuestión no es únicamente técnica.
Una plataforma centralizada simplifica la administración, pero también concentra responsabilidades. Su disponibilidad, copias de seguridad, identidad, certificados, DNS y conectividad pasan a formar parte del diseño de infraestructura.
Una alternativa que merece atención tras los cambios en virtualización
Rancher y Harvester llegan además a un mercado mucho más receptivo a alternativas de virtualización que hace unos años.
Los cambios experimentados alrededor de VMware tras su adquisición por Broadcom han llevado a numerosas empresas a revisar licencias, costes y arquitecturas. Proxmox VE, OpenStack, Nutanix AHV y otras alternativas han ganado visibilidad durante ese proceso.
Harvester presenta una propuesta diferente.
No intenta ser únicamente otro hipervisor.
Su arquitectura está estrechamente relacionada con Kubernetes y Rancher, lo que puede resultar atractivo para organizaciones que ya utilizan tecnologías cloud native o quieren administrar máquinas virtuales y Kubernetes dentro de una estrategia común.
Eso tampoco significa que sea automáticamente la mejor alternativa para cualquier entorno VMware.
Migrar una plataforma de virtualización exige revisar almacenamiento, red, backup, recuperación ante desastres, alta disponibilidad, compatibilidad de aplicaciones, operaciones, conocimientos del equipo y soporte.
La ventaja de Rancher + Harvester aparece especialmente cuando la organización no quiere limitar la discusión a dónde ejecutar sus máquinas virtuales, sino también a cómo administrar la siguiente generación de cargas Kubernetes.
La virtualización continúa debajo.
Lo que cambia es la capa desde la que se gobierna.
Y cuando la infraestructura pasa de un clúster a cinco, diez o decenas de ubicaciones, disponer de esa capa común deja de ser simplemente una cuestión de comodidad.
Preguntas frecuentes
¿Qué diferencia hay entre Rancher y Harvester?
Harvester es una plataforma HCI de virtualización construida sobre Kubernetes, mientras Rancher está orientado a la administración de Kubernetes y múltiples clústeres. Su integración permite gestionar instalaciones Harvester y utilizar su infraestructura para desplegar clústeres Kubernetes.
¿Se pueden gestionar varios clústeres Harvester desde Rancher?
Sí. Rancher Virtualization Management permite importar varios clústeres Harvester y acceder a recursos como hosts, máquinas virtuales, imágenes y volúmenes desde una capa de gestión centralizada.
¿Puede Rancher crear Kubernetes dentro de Harvester?
Sí. El Harvester/SUSE Virtualization Node Driver permite provisionar máquinas virtuales sobre Harvester y utilizarlas como nodos de clústeres RKE2 o K3s, dependiendo de las versiones y soporte aplicables.
¿Rancher debería ejecutarse dentro del mismo Harvester que administra?
Puede ser práctico para laboratorios, pero en producción conviene estudiar una arquitectura que evite dependencias entre la plataforma de gestión y la infraestructura administrada. La configuración concreta debe seguir las recomendaciones y matrices de compatibilidad de las versiones desplegadas.
