Kubernetes es sin duda una de las tecnologías más influyentes de la última década en infraestructura de software. También es una de las más sobredimensionadas en el mercado de PYMEs. Hay empresas de 15 personas pagando por un clúster de Kubernetes gestionado cuando Docker Compose en un servidor les habría dado exactamente el mismo resultado al 10% del coste y complejidad.
Este artículo no pretende convencerle de que use Kubernetes ni de que lo evite. Pretende darle los criterios para tomar esa decisión con información real, no con tendencias del sector.
Qué hace Kubernetes exactamente
Kubernetes (K8s) es un orquestador de contenedores: su función es gestionar automáticamente dónde y cómo se ejecutan sus aplicaciones en un conjunto de servidores (el clúster). Cuando un contenedor falla, K8s lo reinicia. Cuando necesita más capacidad, escala automáticamente. Cuando despliega una nueva versión, lo hace sin tiempo de caída.
En una frase: Kubernetes resuelve el problema de gestionar muchos contenedores en muchos servidores de forma fiable y automatizada.
La pregunta clave antes de seguir: ¿tiene realmente muchos contenedores en muchos servidores? Si la respuesta es no, posiblemente no necesita Kubernetes todavía.
El coste real de Kubernetes que nadie menciona
Kubernetes resuelve problemas reales, pero introduce una capa de complejidad operativa significativa que tiene un coste que hay que valorar honestamente:
Curva de aprendizaje
Kubernetes tiene su propio modelo mental: pods, deployments, services, ingress controllers, namespaces, ConfigMaps, Secrets, PersistentVolumes… Alguien del equipo tiene que entender todo eso para mantener el clúster. No es un conocimiento que se adquiera en un fin de semana.
Overhead operativo
Un clúster de Kubernetes necesita mantenimiento: actualizaciones de versión, gestión de certificados, monitorización de los propios componentes del clúster (no solo de las aplicaciones), gestión de almacenamiento persistente, políticas de red. Si nadie en su equipo tiene experiencia, ese mantenimiento se convierte en deuda técnica acumulada hasta que algo falla.
Coste económico mínimo
Un clúster de Kubernetes mínimamente viable en producción (con alta disponibilidad) requiere al menos tres nodos. En los proveedores cloud principales, eso supone un coste base de entre 150 y 400 €/mes antes de contar el almacenamiento, el tráfico de red o los servicios gestionados adicionales. Un servidor único con Docker puede costar 20-40 €/mes.
Cuándo Kubernetes sí tiene sentido para una PYME
K8s probablemente vale la pena si...
- Tiene más de 10 microservicios o aplicaciones distintas que gestionar
- Necesita escalar automáticamente ante picos de tráfico impredecibles
- Hace despliegues múltiples veces al día y el tiempo de caída es inaceptable
- Tiene al menos una persona en el equipo con experiencia en K8s
- Su aplicación ya está completamente contenedorizada
- Necesita entornos reproducibles (producción, staging, desarrollo) con configuración idéntica
K8s probablemente es overkill si...
- Tiene entre 1 y 5 aplicaciones o servicios
- Su tráfico es predecible y estable
- Despliega una vez a la semana o menos
- Nadie del equipo conoce K8s en profundidad
- Su presupuesto de infraestructura es ajustado
- Está evaluando K8s porque "es lo que usa todo el mundo"
Las alternativas reales: qué usar en su lugar
La buena noticia es que entre "un servidor con todo a mano" y Kubernetes hay un espectro de opciones que cubren la mayoría de necesidades de una PYME en crecimiento.
La herramienta más infrautilizada del ecosistema de contenedores. Un archivo docker-compose.yml define todos sus servicios, redes y volúmenes. Con un solo comando levanta toda la pila, con otro la para. Perfecto para la mayoría de aplicaciones de PYMEs: un backend, una base de datos, un proxy, una cola de mensajes. Sin nodos, sin controladores, sin certificados de clúster. El mantenimiento es mínimo y cualquier desarrollador puede entenderlo en una hora.
Plataforma que ejecuta contenedores Docker cerca de los usuarios (edge computing) sin que usted gestione ningún servidor. Despliega con fly deploy, escala automáticamente y tiene presencia en más de 30 regiones. El modelo de precios es por recurso consumido, lo que lo hace económico para cargas variables. Para una aplicación web con tráfico moderado e internacional, puede ser más barato y sencillo que cualquier alternativa con gestión propia.
Alternativa a Heroku con mejor rendimiento y precios más competitivos. Despliega automáticamente desde Git, gestiona certificados SSL, bases de datos, workers y cron jobs desde una única interfaz. Si su prioridad es que el equipo se centre en el producto y no en la infraestructura, Render elimina prácticamente toda la carga operativa.
Distribución ligera de Kubernetes diseñada para entornos con recursos limitados: Raspberry Pi, servidores pequeños, entornos IoT. Mantiene la compatibilidad total con la API de Kubernetes pero con una huella mucho menor. Si quiere familiarizarse con K8s sin el coste de un clúster cloud completo, K3s en un VPS de 4 euros es el punto de partida habitual.
Si después de evaluar todo llega a la conclusión de que Kubernetes es lo que necesita, use siempre la versión gestionada de su proveedor cloud (EKS en AWS, GKE en Google Cloud, AKS en Azure). El plano de control (los nodos master) lo gestiona el proveedor; usted solo gestiona sus workloads. El sobrecoste frente a montarlo usted mismo se amortiza rápidamente en tiempo de administración ahorrado.
Un árbol de decisión para su caso concreto
¿Necesito Kubernetes?
¿Tiene más de 10 servicios independientes que desplegar y escalar?
Docker Compose o un PaaS (Fly.io, Render) cubre sus necesidades con mucho menos coste operativo.
Continúe evaluando. El número de servicios es condición necesaria pero no suficiente.
¿Tiene alguien en el equipo con experiencia real en K8s (no solo cursos)?
No adopte K8s hasta tenerlo. La curva de aprendizaje en producción es cara y arriesgada.
El factor humano está cubierto. Evalúe si el caso de uso justifica la complejidad adicional.
¿Necesita escala automática o despliegues sin tiempo de caída varias veces al día?
Un PaaS gestionado o Docker Swarm resuelven esto con mucha menos complejidad.
Kubernetes empieza a justificarse. Use un clúster gestionado (EKS/GKE/AKS), nunca autogestionado si puede evitarlo.
El error más costoso: adoptar K8s demasiado pronto
En el mundo tech existe una tendencia a adoptar la tecnología más sofisticada disponible como señal de madurez técnica. Kubernetes ha sufrido especialmente ese efecto. El resultado práctico en muchas PYMEs es un clúster de K8s ejecutando tres aplicaciones, mantenido por alguien que aprendió K8s en YouTube y que pasa más tiempo depurando problemas de red del clúster que desarrollando producto.
La tecnología correcta no es la más avanzada: es la más adecuada para el problema que tiene ahora, con el equipo que tiene ahora y el presupuesto que tiene ahora. Docker Compose no es una solución "para principiantes": es una solución profesional para un conjunto bien definido de problemas. Muchas empresas con decenas de millones de euros de facturación la usan en producción porque resuelve exactamente lo que necesitan.
Regla práctica: empiece con la solución más simple que resuelva su problema actual. Migre a algo más complejo solo cuando tenga un problema concreto que la solución simple no pueda resolver, no antes.
Cuándo sí tiene sentido dar el salto
Hay señales claras de que ha llegado el momento de evaluar Kubernetes seriamente:
- Sus despliegues con Docker Compose causan tiempo de caída que empieza a afectar al negocio
- Gestiona más de 15-20 contenedores y coordinarlos manualmente se está volviendo un problema
- Necesita entornos de staging y producción perfectamente aislados y reproducibles con configuraciones complejas
- Tiene picos de tráfico que requieren escalar en minutos y el sobreaprovisionamiento fijo sale más caro
- Su equipo ha crecido y varios desarrolladores despliegan en paralelo, generando conflictos
Si reconoce dos o más de estas situaciones a la vez, y tiene el perfil técnico para gestionarlo, Kubernetes empieza a tener una justificación económica clara.
En EstructuraBit evaluamos la infraestructura de cada empresa y recomendamos la solución que mejor se ajusta a su escala actual y su capacidad de gestión, sin sobrevender complejidad innecesaria. Si no está seguro de si su infraestructura actual es la adecuada para el siguiente paso de crecimiento, hablemos.
Volver al blog