La pregunta parece lógica: si OpenStack utiliza KVM y Proxmox también, ¿por qué no instalar Proxmox en los servidores y colocar OpenStack por encima para gestionar toda la infraestructura? El problema es que ambos productos son plataformas de control. Los dos quieren decidir cómo nacen, se conectan, almacenan, migran y desaparecen las máquinas virtuales, así que combinarlos no crea automáticamente una nube privada más completa.

Las claves de OpenStack y Proxmox en 30 segundos

• OpenStack admite KVM mediante Nova y libvirt, pero no incorpora un controlador específico para gestionar clústeres Proxmox.
• Proxmox ya administra máquinas virtuales, redes, almacenamiento, alta disponibilidad, permisos y copias de seguridad.
• Colocar dos planos de control sobre los mismos recursos puede provocar configuraciones divergentes y operaciones contradictorias.
• Proxmox encaja bien como plataforma de virtualización; OpenStack responde mejor cuando se necesita una nube IaaS multiusuario y autoservicio.
• Kubernetes puede funcionar sobre cualquiera de los dos y no justifica por sí solo desplegar OpenStack.

La documentación actual de Nova, el componente de computación de OpenStack, incluye KVM entre los hipervisores compatibles y lo gestiona mediante su controlador para libvirt. También enumera otras opciones, como VMware vSphere, Virtuozzo, z/VM o el aprovisionamiento de servidores físicos mediante Ironic. Proxmox no aparece como un controlador o hipervisor compatible de primera clase.

Esto no significa que sea imposible escribir una integración, llamar a la interfaz de programación de aplicaciones (API) de Proxmox o construir una capa propia que traduzca órdenes entre los dos sistemas. Significa que esa combinación no forma parte del modelo normal de OpenStack y que una empresa tendría que asumir el desarrollo, las pruebas, las actualizaciones y los fallos de una pieza intermedia que ninguno de los dos proyectos gobierna de forma conjunta.

KVM es el punto común, pero no define la arquitectura

KVM es la tecnología de virtualización incluida en Linux que permite ejecutar máquinas virtuales utilizando las extensiones del procesador. Proxmox VE la integra junto con QEMU para ofrecer virtualización completa de sistemas Windows y Linux. OpenStack puede utilizarla como motor de computación a través de Nova y libvirt.

La coincidencia termina en buena medida ahí. Proxmox VE no es una interfaz web colocada encima de KVM. Es una plataforma completa que incorpora gestión de clústeres, alta disponibilidad, migración, almacenamiento, redes definidas por software, cortafuegos, autenticación, permisos y herramientas de recuperación. También administra contenedores LXC desde el mismo entorno.

OpenStack construye su propio modelo sobre servicios separados. Nova gestiona la capacidad de cálculo; Neutron controla las redes; Cinder proporciona almacenamiento en bloques; Glance mantiene las imágenes y Keystone se ocupa de la identidad. A estos componentes pueden añadirse otros para balanceo, orquestación, telemetría o gestión de clústeres de contenedores.

Cuando OpenStack crea una instancia, registra su identidad, asigna el host, conecta sus interfaces virtuales, adjunta los volúmenes y mantiene el estado esperado de ese recurso. Proxmox hace algo equivalente dentro de su propio inventario y con sus propias definiciones de almacenamiento, red y alta disponibilidad.

Permitir que los dos modifiquen las mismas máquinas introduce dos fuentes de verdad. OpenStack puede considerar que una instancia debe ejecutarse en un nodo mientras Proxmox intenta migrarla por una política de alta disponibilidad. Un administrador puede cambiar un disco desde la interfaz de Proxmox sin que Cinder conozca esa operación. Una red puede existir para Neutron y no corresponder con la configuración que Proxmox aplica en sus puentes, VLAN o redes virtuales.

El fallo no tiene por qué aparecer durante la creación inicial. Puede surgir meses después, durante una migración, una recuperación, una ampliación de disco o una actualización. Las operaciones manuales que funcionan en una prueba pequeña suelen convertirse en configuraciones divergentes cuando intervienen automatizaciones, varios administradores y cientos de máquinas.

Instalar los componentes de Nova directamente en servidores que ya forman un clúster Proxmox tampoco resuelve la contradicción. En la práctica implicaría pedir a OpenStack que gestione el KVM y la libvirt subyacentes mientras Proxmox mantiene sus propios procesos, archivos de configuración y base de datos distribuida sobre los mismos recursos.

La opción coherente es decidir cuál será el plano de control. Si se elige OpenStack, los nodos de computación deben incorporarse siguiendo la arquitectura y los controladores de OpenStack. Si se elige Proxmox, las máquinas deben administrarse mediante el clúster, la API y las herramientas de Proxmox.

Esto no impide que una organización utilice las dos plataformas. Puede mantener un entorno Proxmox para cargas tradicionales y otro OpenStack para servicios internos de infraestructura como servicio (IaaS). La separación evita que ambos intenten gobernar los mismos objetos y permite asignar cada carga al modelo operativo que necesita.

La elección real es virtualización o nube privada

La discusión suele aparecer durante una migración desde VMware vSphere. El cambio de licencias lleva a muchas empresas a buscar una alternativa y, en ese momento, se mezclan dos proyectos distintos: sustituir la plataforma de virtualización y construir una nube privada.

Proxmox puede cubrir muchas necesidades que antes resolvía vSphere. Permite agrupar servidores, ejecutar máquinas virtuales y contenedores, configurar alta disponibilidad, integrar Ceph, ZFS y almacenamiento compartido, realizar migraciones y conectar una solución específica de copias de seguridad.

Además, Proxmox Datacenter Manager amplía la administración centralizada a varios clústeres y centros de datos. El fabricante indica que permite visualizar, operar y migrar miles de cargas desde una única interfaz, además de centralizar identidades, redes EVPN y actualizaciones. Esta evolución reduce algunas limitaciones históricas en entornos distribuidos, aunque sigue trabajando dentro del modelo de Proxmox.

OpenStack intenta resolver un problema diferente. Su utilidad aparece cuando los usuarios internos necesitan solicitar recursos mediante API, trabajar en proyectos aislados, aplicar cuotas, crear redes bajo demanda, consumir catálogos de imágenes y adjuntar volúmenes sin abrir un ticket al administrador de virtualización.

En una nube privada, la infraestructura se presenta como un servicio. Los equipos de desarrollo no necesitan conocer en qué servidor se ejecuta cada máquina ni qué cabina guarda el disco. Piden un recurso con unas características y el sistema decide dónde desplegarlo según capacidad, políticas y disponibilidad.

Ese modelo tiene un coste operativo. OpenStack exige mantener varios servicios, bases de datos, colas de mensajería, redes, almacenamiento y herramientas de despliegue. También requiere personal que entienda cómo actualizar el conjunto, investigar fallos distribuidos y automatizar cambios sin romper las dependencias entre componentes.

El software puede ser abierto y no exigir una licencia por cada procesador, pero su operación necesita tiempo, conocimiento y procesos. Una empresa que solo pretende reemplazar vSphere puede acabar construyendo una plataforma más compleja de la que necesita.

Proxmox reduce esa carga al integrar la mayor parte de la administración de virtualización en un producto más compacto. Esa sencillez relativa también establece un límite: disponer de API, permisos y automatización no convierte por sí solo un clúster de virtualización en una nube IaaS completa con el mismo modelo de proyectos, cuotas y servicios de red de OpenStack.

El número de máquinas virtuales tampoco decide por sí solo. Un entorno con menos de 2.000 VM puede justificar OpenStack si atiende a numerosos equipos, ofrece autoservicio, necesita redes aisladas por proyecto y crea o destruye recursos de forma continua. Otro entorno con la misma cantidad puede funcionar mejor sobre Proxmox si las cargas son estables y las administra un equipo central.

La pregunta útil no es cuántas máquinas existen, sino quién las solicita, con qué frecuencia cambian y qué servicios esperan sus usuarios. Si casi todos los cambios pasan por administradores y procedimientos planificados, Proxmox puede cubrir el objetivo con menos piezas. Si decenas de equipos necesitan consumir infraestructura mediante API con aislamiento y cuotas, la complejidad de OpenStack empieza a estar justificada.

La independencia del hipervisor también necesita matices. OpenStack puede trabajar con varias tecnologías y su documentación permite programar cargas sobre hipervisores diferentes dentro de una misma instalación. Aun así, la propia documentación reconoce que la mayoría de los despliegues utiliza uno solo. Las diferencias de funciones, formatos, controladores y redes impiden tratar todos los hipervisores como si fueran intercambiables sin trabajo adicional.

Elegir OpenStack no elimina la dependencia tecnológica. La desplaza hacia sus APIs, sus servicios, el diseño de red, el almacenamiento y la distribución elegida para operarlo. Esa dependencia puede ser preferible a la de un fabricante propietario, pero continúa existiendo y debe incluirse en el análisis.

Kubernetes no obliga a desplegar OpenStack

Kubernetes aparece con frecuencia como argumento definitivo a favor de OpenStack, aunque la relación no es automática. Kubernetes puede ejecutarse sobre máquinas virtuales creadas por vSphere, Proxmox, OpenStack o cualquier otra plataforma capaz de proporcionar servidores Linux y conectividad.

Un clúster estable con varios nodos puede funcionar perfectamente sobre Proxmox. Las máquinas se crean mediante plantillas, Terraform, Ansible u otras herramientas y Kubernetes administra después los contenedores. Para muchos entornos, esa capa resulta suficiente.

OpenStack aporta valor cuando Kubernetes necesita consumir de forma dinámica servicios de la infraestructura. Magnum, por ejemplo, ofrece clústeres de contenedores como recursos de OpenStack y se integra con Keystone para la identidad, Neutron para la red multiusuario y Cinder para los volúmenes. Octavia añade balanceo de carga dentro de la plataforma.

La decisión depende de lo que Kubernetes espere del nivel inferior. No es lo mismo mantener tres clústeres corporativos de larga duración que permitir a diferentes equipos crear entornos completos bajo demanda. Tampoco es igual asignar volúmenes manualmente que solicitar almacenamiento persistente a través de un controlador conectado al servicio de bloques.

Antes de utilizar Kubernetes como razón para elegir plataforma conviene concretar las necesidades: aprovisionamiento automático de nodos, creación dinámica de volúmenes, balanceadores bajo demanda, redes independientes, cuotas por equipo, reconstrucción automatizada y gestión de múltiples proyectos.

Si esas capacidades forman parte del servicio que la organización quiere ofrecer, OpenStack dispone de componentes diseñados para integrarlas. Si Kubernetes solo necesita máquinas virtuales estables, Proxmox puede proporcionarlas sin obligar a operar una nube privada completa.

CloudStack suele aparecer como una tercera vía por ofrecer un modelo IaaS más compacto que OpenStack. Sin embargo, la matriz oficial de compatibilidad de Apache CloudStack 4.22 enumera como familias principales KVM, XenServer/XCP-ng y VMware vSphere. Proxmox no figura entre los hipervisores admitidos en el núcleo del proyecto.

Pueden existir conectores comerciales, extensiones comunitarias o desarrollos propios capaces de comunicarse con Proxmox, pero deben evaluarse como una dependencia adicional. La prueba debe cubrir creación y borrado de VM, migración, snapshots, plantillas, redes, volúmenes, alta disponibilidad, recuperación de errores y actualizaciones de ambos extremos.

La salida más prudente para una migración desde vSphere consiste en separar las decisiones. Primero debe definirse si la empresa necesita sustituir una plataforma de virtualización o cambiar su forma de consumir infraestructura. Después puede probar Proxmox y OpenStack con cargas y procesos reales, pero sin colocar uno encima del otro para evitar elegir.

Proxmox puede ser suficiente y OpenStack puede estar plenamente justificado. Lo que rara vez resulta limpio es mantener a ambos como responsables de las mismas máquinas. Compartir KVM no los convierte en capas complementarias. Los convierte en dos plataformas que necesitan saber cuál de ellas manda.

Preguntas frecuentes

¿Puede OpenStack gestionar directamente un clúster Proxmox?

No como integración oficial de primera clase. Nova admite KVM mediante libvirt, pero no incorpora un controlador específico para administrar el clúster, la API y los recursos propios de Proxmox.

¿Se puede instalar OpenStack sobre nodos Proxmox?

Puede construirse una prueba o un desarrollo personalizado, pero utilizar ambos planos de control sobre los mismos recursos aumenta el riesgo de configuraciones divergentes. En producción resulta más coherente permitir que OpenStack gestione directamente sus nodos KVM o mantener Proxmox como único responsable.

¿Proxmox sirve para crear una nube privada?

Puede automatizarse y ofrecer recursos a través de su API, pero su modelo principal es la gestión de virtualización. Cuando se requieren proyectos multiusuario, cuotas, redes y volúmenes bajo demanda y servicios IaaS integrados, OpenStack ofrece una arquitectura más específica.

¿Es necesario OpenStack para ejecutar Kubernetes?

No. Kubernetes puede funcionar sobre máquinas virtuales de Proxmox. OpenStack resulta más útil cuando el clúster debe consumir dinámicamente identidad, redes, volúmenes, balanceadores y aprovisionamiento mediante APIs cloud.