Kubernetes: Cuándo lo Necesitas y Cuándo te Sobra

Hay una escena que se repite en muchas empresas: el equipo tiene una aplicación monolítica que funciona bien en un par de servidores, alguien vuelve de una conferencia entusiasmado, y seis meses después hay un clúster de Kubernetes en producción que nadie entiende del todo, que consume el 30% del tiempo del equipo y que orquesta… cuatro contenedores.

Kubernetes es una herramienta extraordinaria — de hecho, es el estándar de facto para orquestar contenedores a escala. El problema no es la herramienta: es adoptarla sin que el problema que resuelve exista todavía. Esta guía te da los criterios para decidir con honestidad: señales claras de que lo necesitas, señales claras de que te sobra, y las alternativas intermedias que casi nadie te cuenta.

El Problema: Adoptar la Solución Antes que el Problema

Kubernetes resuelve un problema muy concreto: orquestar muchos contenedores, en muchas máquinas, con despliegues frecuentes y requisitos de alta disponibilidad. Cuando ese es tu problema, no hay nada mejor. Cuando no lo es, Kubernetes no desaparece: se convierte en un segundo producto que tu equipo tiene que mantener, con su curva de aprendizaje, sus incidencias a las 3 de la madrugada y sus facturas.

El patrón de error tiene nombre: resume-driven development. Se elige la tecnología que queda bien en el CV o en la charla, no la que encaja con la escala real del sistema. Y la escala real de la inmensa mayoría de productos es mucho más modesta de lo que su infraestructura sugiere.

Qué Resuelve Kubernetes de Verdad

Antes de decidir, conviene ser preciso sobre qué compras cuando adoptas Kubernetes:

• Orquestación: decide en qué nodo corre cada contenedor, lo reinicia si muere, lo mueve si el nodo falla.
• Escalado automático: más réplicas cuando sube la carga, menos cuando baja — por CPU, memoria o métricas propias.
• Despliegues declarativos: describes el estado deseado (manifiestos) y el sistema converge hacia él; rollouts progresivos y rollbacks incluidos.
• Descubrimiento de servicios y red interna: los servicios se encuentran entre sí sin hardcodear IPs.
• Autorreparación: health checks que sacan de rotación lo que falla y lo reemplazan sin intervención humana.

Si al leer la lista has pensado «no necesito casi nada de esto», ya tienes media respuesta.

Señales de que SÍ lo Necesitas

Kubernetes empieza a pagar sus costes cuando se cumplen varias de estas condiciones a la vez:

1. Arquitectura de microservicios real. No «tenemos tres módulos»: decenas de servicios desplegados de forma independiente, con equipos distintos que necesitan autonomía de release.
2. Despliegues muy frecuentes. Varias veces al día, con canary releases, feature flags y rollbacks rápidos como requisito de negocio, no como capricho.
3. Carga variable de verdad. Picos predecibles (campañas, cierres de mes) o impredecibles que hacen rentable el autoescalado frente a sobredimensionar máquinas.
4. Requisitos estrictos de disponibilidad. SLAs del 99,9% o superiores, donde la autorreparación y la distribución multi-nodo (o multi-zona) son una necesidad contractual.
5. Equipo con capacidad de plataforma. Al menos dos o tres personas que puedan dedicar una parte seria de su tiempo a la plataforma — porque el clúster es un producto interno, no un detalle.
6. Multi-entorno o multi-cloud como requisito. Portabilidad real entre nubes o entre on-premise y nube, no como argumento de PowerPoint.

Si cumples cuatro o más, Kubernetes probablemente es tu respuesta. Si cumples una o dos, sigue leyendo.

Señales de que Te Sobra (Aunque Duela)

• Un monolito bien hecho. Un monolito modular desplegado en una o dos máquinas con un buen CI es una arquitectura legítima y muy productiva. Meterlo en Kubernetes no lo mejora: solo lo hace más caro de operar.
• Equipo pequeño sin perfil de plataforma. Si nadie quiere (ni puede) ser dueño del clúster, el clúster acabará siendo dueño del equipo.
• Despliegues semanales o mensuales. La maquinaria de rollouts progresivos y service mesh es sobrecoste puro si despliegas los viernes con calma.
• Carga predecible y modesta. Si tu pico histórico cabe en una máquina mediana, estás pagando complejidad de autoescalado para un problema que no tienes.
• «Para aprender». Aprender Kubernetes está muy bien — en un entorno de juguete, con k3s o kind en local. Producción no es el laboratorio.

Las Alternativas Intermedias (Donde Vive el 80% de los Proyectos)

Entre «un VPS con Docker Compose» y «Kubernetes multi-zona» hay todo un espectro de opciones serias:

1. Docker Compose en uno o dos servidores: perfectamente válido para monolitos y arquitecturas pequeñas. Con un buen pipeline de CI, backups probados y monitorización, aguanta mucho más tráfico del que cree la mayoría.
2. PaaS (Render, Railway, Fly.io, App Engine, Azure App Service): despliegues desde git, escalado gestionado, certificados y balanceo incluidos. Pagas más por recurso, pero compras tiempo de equipo — que suele ser el recurso más caro.
3. Contenedores gestionados sin Kubernetes (AWS ECS/Fargate, Google Cloud Run, Azure Container Apps): corres contenedores con autoescalado y alta disponibilidad sin operar un plano de control. Para muchos equipos es el punto dulce.
4. Kubernetes gestionado y pequeño (k3s, GKE Autopilot, EKS con node groups mínimos): si sabes que vas a crecer hacia microservicios, empezar con un Kubernetes gestionado y austero es una apuesta razonable — la nube se lleva la parte más dolorosa (etcd, upgrades, certificados).

La pregunta no es «¿Kubernetes sí o no?», sino «¿qué nivel de esta escalera me corresponde hoy, y cuál me corresponderá en dos años?».

Lo que Kubernetes Cuesta de Verdad

La factura de Kubernetes no es (solo) la de los nodos. El coste real es operativo:

• Tiempo de plataforma: upgrades del clúster, rotación de certificados, ajuste de requests y limits, incidencias de red, storage que no monta… En equipos pequeños medimos habitualmente entre un 20% y un 40% del tiempo total de ingeniería absorbido por la plataforma.
• Curva de aprendizaje: pods, deployments, services, ingress, ConfigMaps, RBAC, NetworkPolicies, operators… Cada concepto es razonable por separado; juntos son meses de formación antes de ser productivo y seguro.
• Infraestructura sobredimensionada: el plano de control y los demonios de cada nodo consumen recursos antes de desplegar nada tuyo. Un clúster pequeño mal ajustado puede costar más que toda la aplicación que aloja — y de hecho es uno de los primeros sitios donde miramos cuando auditamos una factura de cloud que se dispara.
• Complejidad accidental: debugging entre capas (¿falla la app, el service, el ingress, el DNS, el NetworkPolicy?) multiplica el tiempo medio de resolución de incidencias.

Nada de esto es un argumento contra Kubernetes cuando lo necesitas: es el precio de una capacidad enorme. Es un argumento contra pagarlo sin necesitar la capacidad.

Cómo Decidir: Tres Preguntas Honestas

1. ¿Qué problema concreto me resuelve hoy? Si la respuesta empieza por «en el futuro podríamos…», es un no por ahora. Las migraciones a Kubernetes hechas a tiempo existen y son manejables; las hechas antes de tiempo son deuda técnica con YAML.
2. ¿Quién será el dueño de la plataforma? Si la respuesta es «ya lo veremos» o «entre todos», la respuesta real es «nadie» — y un clúster sin dueño es una bomba de relojería.
3. ¿Qué opción más simple descarté, y por qué? Si no puedes articular por qué Docker Compose, un PaaS o Cloud Run no te valen, probablemente sí te valen.

Errores Comunes

1. Confundir contenedores con Kubernetes. Docker resuelve el empaquetado; Kubernetes la orquestación a escala. Puedes (y muchas veces debes) quedarte en el primero.
2. Montar el clúster a mano «para entenderlo» y dejarlo así. Los clústeres artesanales sin Terraform/Ansible ni procedimiento de upgrade se convierten en piezas de museo que nadie se atreve a tocar.
3. Kubernetes para todo, incluida la base de datos. Las bases de datos con estado son lo peor gestionado por Kubernetes para equipos pequeños; un servicio gestionado (RDS, Cloud SQL) casi siempre gana.
4. Microservicios como excusa. Si tus «microservicios» se despliegan siempre juntos y comparten base de datos, tienes un monolito distribuido: los costes de ambos mundos, los beneficios de ninguno.
5. No tener plan de salida. Si adoptas Kubernetes, define también qué métricas te dirán que fue un error (tiempo de plataforma, coste por despliegue, MTTR) para poder corregir el rumbo.

En Resumen

Kubernetes es la respuesta correcta a un problema concreto: muchos servicios, despliegues constantes, disponibilidad exigente y equipo con capacidad de plataforma. Si ese no es tu problema hoy, las alternativas intermedias — Compose, PaaS, contenedores gestionados — te darán el 90% del valor por el 20% del coste operativo. La mejor infraestructura no es la más sofisticada: es la más aburrida que cumple tus requisitos.

¿Dudas sobre si tu arquitectura de despliegue está al nivel correcto — por exceso o por defecto? Es una de las revisiones más habituales en nuestras auditorías de infraestructura. Cuéntanos tu caso →

Sigue leyendo: Cómo reducir tu factura cloud un 30% sin tocar el rendimiento.