Usamos cookies técnicas y, si lo aceptas, de analítica (Google Analytics 4) para
mejorar el sitio. Hasta entonces no se instalan cookies de analítica.
Más información en la política de cookies.
Kubernetes resuelve muy bien un problema concreto: orquestar muchos servicios que escalan, se recuperan solos y se despliegan a menudo. Si no tienes ese problema, sobra.
Sobre Proxmox, Kubernetes corre en VMs que hacen de nodos del clúster; Proxmox aporta la capa de virtualización, K8s la de orquestación de contenedores.
Señales de que sí lo necesitas: microservicios numerosos, varios equipos desplegando, autoescalado real, despliegues continuos.
Señales de que no: pocas aplicaciones, un equipo pequeño, un monolito. Ahí unas VMs con Docker Compose o LXC hacen el trabajo con una fracción de la complejidad.
La pregunta honesta antes de montarlo no es cómo, sino si el coste de operar Kubernetes lo compensa el problema que tienes.
Kubernetes tiene algo de rito de paso: parece que un cloud privado «serio» tiene que tener un clúster de Kubernetes, y no tenerlo se vive casi como una carencia. Es un error de perspectiva. Kubernetes no es un signo de madurez; es una herramienta para un problema específico. Montarlo sin tener ese problema no te hace más avanzado: te añade una capa enorme de complejidad operativa a cambio de resolver algo que no tenías.
Este artículo es el contrapunto honesto a la moda. No va de cómo montar Kubernetes —de eso hay mil tutoriales—, sino de si deberías, y de qué alternativas más simples hacen el mismo trabajo para la mayoría. Y sí, también de cómo desplegarlo sobre Proxmox cuando de verdad toca. Porque la respuesta correcta a «¿monto Kubernetes?» a veces es sí, y a veces es «no, y te ahorras un montón de dolor».
Qué problema resuelve Kubernetes de verdad
Para decidir si lo necesitas, hay que tener claro para qué se diseñó. Kubernetes es un orquestador de contenedores: automatiza el despliegue, el escalado y la recuperación de aplicaciones empaquetadas en contenedores, repartidas por muchas máquinas. Sus superpoderes reales:
Autorreparación: si un contenedor muere, Kubernetes lo levanta de nuevo. Si muere una máquina entera, replanifica sus cargas en otras. La aplicación se mantiene viva sin intervención.
Autoescalado: ajusta el número de réplicas de un servicio según la carga, arriba en un pico y abajo cuando pasa.
Despliegues continuos y sin corte: actualiza versiones gradualmente (rolling updates), y revierte si algo falla, sin tirar el servicio.
Abstracción declarativa: describes el estado que quieres («quiero 5 réplicas de esto, con este almacenamiento y esta red») y Kubernetes se encarga de mantener la realidad igual a esa descripción.
Estos son poderes reales y muy valiosos… si tu problema los necesita. Kubernetes es la respuesta correcta cuando tienes decenas o cientos de servicios que cambian a menudo, que deben escalar solos y sobrevivir a fallos sin que nadie se levante de madrugada. Ese es su terreno, y ahí no tiene rival.
Proxmox ya planifica y recupera máquinas; Kubernetes hace lo mismo con pods. La pregunta no es si funciona —funciona—, sino si necesitas las dos capas.
Cuándo NO lo necesitas (que es más veces de lo que parece)
Aquí está la parte incómoda. Para muchas infraestructuras, Kubernetes resuelve problemas que no tienen, y a cambio les cobra una complejidad que sí tienen que sufrir cada día. Señales de que probablemente no lo necesitas:
Tienes pocas aplicaciones. Si toda tu carga son cinco o diez servicios estables que cambian una vez al mes, la maquinaria de orquestación de Kubernetes es desproporcionada. Un par de VMs bien montadas hacen el trabajo.
Eres un equipo pequeño. Kubernetes tiene un coste operativo permanente: hay que actualizarlo, parchearlo, entender su red, su almacenamiento, sus fallos. Si no tienes a alguien que lo domine, ese coste se paga en incidentes y en tiempo perdido depurando YAML en lugar de resolviendo el negocio.
Tu aplicación es un monolito. Un monolito no gana casi nada al meterlo en Kubernetes; sigue siendo una aplicación que corre en una máquina. Le añades complejidad de orquestación sin la contrapartida de los microservicios.
Tu carga es estable y predecible. El autoescalado brilla con tráfico variable. Si tu carga es plana, escalar dinámicamente resuelve un problema que no tienes.
En todos esos casos, alternativas mucho más simples cubren la necesidad:
Fíjate en la tercera fila: mucha gente monta Kubernetes «para tener alta disponibilidad», y resulta que Proxmox ya se la da a nivel de VM sin una sola línea de YAML. La HA de infraestructura y la orquestación de contenedores son cosas distintas; no montes la segunda si lo que querías era la primera.
Cuándo SÍ tiene sentido sobre Proxmox
Dicho todo lo anterior, hay escenarios donde Kubernetes sobre tu cloud privado es exactamente lo correcto:
Ya trabajas con Kubernetes. Tu equipo lo conoce, tus aplicaciones están pensadas para él, tu pipeline de despliegue lo asume. Llevarlo a tu propia infraestructura sobre Proxmox te da la potencia de K8s con la soberanía y el control de costes del cloud privado, sin la factura variable del Kubernetes gestionado de un hiperescalar.
Tienes microservicios de verdad, numerosos y cambiantes. Muchos servicios pequeños que se despliegan a menudo y deben escalar y recuperarse solos: el caso de uso canónico.
Necesitas autoescalado real con carga variable. Picos que suben y bajan, donde ajustar réplicas a mano no es viable.
Varios equipos comparten infraestructura. Kubernetes ofrece aislamiento lógico (namespaces), cuotas y autoservicio que ayudan cuando muchos despliegan sobre lo mismo.
Si te reconoces en esto, Kubernetes no es sobreingeniería: es la herramienta adecuada, y montarla sobre Proxmox es una gran opción.
Cómo se despliega sobre Proxmox (cuando toca)
El patrón es limpio y encaja con todo lo que hemos ido contando. Kubernetes necesita máquinas donde correr; Proxmox se las da como VMs:
Proxmox provee las VMs. Cada nodo de Kubernetes —los de control y los de trabajo— es una VM de Proxmox. Lo habitual: tres nodos de control para alta disponibilidad del plano de control, y los nodos de trabajo que necesites.
Las VMs se crean por código. Con Terraform/OpenTofu y el provider de Proxmox más plantillas cloud-init, levantas los nodos de forma reproducible. Nada de clic manual: el clúster es código.
Se instala la distribución de Kubernetes sobre esas VMs: desde kubeadm para un clúster a medida, hasta distribuciones ligeras como K3s para entornos más modestos, o herramientas que automatizan el ciclo completo.
El almacenamiento y la red se integran con lo que ya tienes: almacenamiento persistente sobre Ceph, red sobre el SDN de Proxmox.
La capa queda ordenada: Proxmox orquesta las máquinas, Kubernetes orquesta los contenedores. Cada uno en su nivel, sin pisarse.
La pregunta honesta antes de empezar
Reduciendo todo a una decisión: antes de montar Kubernetes, pregúntate qué problema concreto te resuelve que no puedas resolver con unas VMs, Docker Compose o LXC y el HA de Proxmox. Si tienes una respuesta clara —«decenas de microservicios que escalan y se despliegan diez veces al día»—, adelante, es tu herramienta. Si la respuesta es vaga —«porque es lo que se usa», «para estar preparados»—, probablemente estás a punto de añadir una complejidad que te va a costar cara y no te va a devolver el equivalente.
Kubernetes es excelente. Pero la ingeniería no consiste en usar la herramienta más potente, sino la adecuada al problema. Y a veces la más adecuada es la más aburrida: tres VMs, un poco de Docker y el HA que Proxmox ya te da.
Preguntas frecuentes
¿Necesito Kubernetes para tener alta disponibilidad?
No. La alta disponibilidad de las máquinas la da Proxmox de forma nativa a nivel de VM, sin Kubernetes. Kubernetes añade recuperación y escalado a nivel de aplicación/contenedor, que es un problema distinto. Si lo que quieres es que tus VMs sobrevivan a la caída de un nodo, el HA de Proxmox basta.
¿Cuándo merece la pena Kubernetes sobre Proxmox?
Cuando ya trabajas con Kubernetes, cuando tienes microservicios numerosos que cambian a menudo, cuando necesitas autoescalado real con carga variable o cuando varios equipos comparten la infraestructura. En esos casos, llevarlo a Proxmox te da la potencia de K8s con soberanía y coste previsible. Para pocas apps estables, es desproporcionado.
¿Qué alternativas más simples hay?
Para desplegar unas cuantas aplicaciones en contenedores, Docker Compose en una o dos VMs. Para densidad de servicios Linux, contenedores LXC. Para alta disponibilidad de máquinas, el HA de Proxmox. Para reproducibilidad, Terraform o OpenTofu con cloud-init. La mayoría de infraestructuras se cubren con estas sin Kubernetes.
¿Cómo corre Kubernetes sobre Proxmox?
En máquinas virtuales que hacen de nodos del clúster: unas VMs para el plano de control (idealmente tres, para HA) y otras para los nodos de trabajo. Se crean por código con Terraform/OpenTofu y cloud-init, y encima se instala la distribución de Kubernetes (kubeadm, K3s u otra). Proxmox gestiona las VMs; Kubernetes, los contenedores.
¿K3s o Kubernetes completo?
K3s es una distribución ligera de Kubernetes, más sencilla de operar, ideal para entornos modestos, edge o equipos pequeños que sí necesitan orquestación pero no toda la maquinaria. Kubernetes completo (vía kubeadm u otras) encaja cuando necesitas todas sus capacidades y tienes quien lo opere. Ambos corren bien sobre VMs de Proxmox.
¿Dudas entre montar Kubernetes o mantenerlo simple en tu cloud privado? Te ayudamos a decidir con criterio y a montar lo que de verdad necesitas sobre Proxmox —ni más ni menos—. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
¿Te ha resultado útil? Compártelo o resúmelo con IA
