"¿Ya necesitamos Kubernetes?" es casi siempre la pregunta equivocada. La correcta es: ¿cuántos servicios, cuántos servidores y a cuántas personas les suena el teléfono de guardia? Esos tres números dicen más que cualquier charla abstracta sobre "necesitar orquestación".
Los umbrales que de verdad importan
CodeCeibe corre en un único VPS con Compose: Django, Postgres 17, Redis, un worker de analítica, un worker de la cola de posts programados y nginx -- seis servicios, un servidor, una persona de guardia. Mover eso a Kubernetes hoy añadiría un control plane, un cluster de etcd y un árbol de YAML que mantener, sin ningún beneficio operativo. La tabla de abajo son las señales que de verdad vigilamos, no una checklist genérica.
| Señal | Compose sigue bien | Hora de mirar Kubernetes |
|---|---|---|
| Servicios | 8 o menos en un servidor | 10+ servicios, varios equipos dueños de piezas distintas |
| Servidores | 1 (quizás un standby) | 3+ servidores que necesitan un scheduler que decida dónde correr |
| Equipo de guardia | 1-3 personas que conocen el stack de memoria | 4+ ingenieros rotando, nadie quiere aprender "pregúntale a Alvaro" como proceso de despliegue |
| Despliegues | Pocas veces por semana, un corte breve es aceptable | 10+ veces al día, los rolling updates sin downtime son un requisito, no un extra |
| Patrón de carga | Más o menos plano, dimensionas los contenedores una vez | Picos de tráfico lo bastante fuertes como para necesitar escalar de 2 a 12 réplicas automáticamente |
Cómo se ve justo antes de haberlo cruzado
La señal no es una epifanía filosófica, es un script. Si ya estás escribiendo algo así, ya te quedaste corto con Compose y todavía no lo admites:
for host in web01 web02 web03; do
ssh deploy@$host "cd /srv/app && docker compose pull && docker compose up -d --no-deps app"
sleep 15
curl -sf https://$host/healthz || { echo "rollback en $host"; break; }
doneEso es una versión artesanal, secuencial y sin rollback de lo que un Deployment de Kubernetes da gratis con readinessProbe y maxUnavailable: 0. Cuando ya estás escribiendo bucles de SSH para simular rolling updates entre servidores, el orquestador sale más barato que el bash.
Lo que realmente cambia después del salto
- Alguien tiene que ser dueño del cluster en sí -- actualizar nodos, el plugin de CNI, rotar certificados. Eso es un trabajo a tiempo parcial con 3 nodos, y uno real pasados los 10.
- Tu artefacto de despliegue pasa de un
docker-compose.ymlque cualquiera lee en 30 segundos a un chart de Helm o un montón de manifiestos que necesita su propio proceso de revisión. - Ganas autoscaling real, rolling updates con checks de salud y un scheduler que reparte la carga entre servidores -- cosas que Compose de verdad no puede hacer, porque nunca se diseñó para eso.
La respuesta honesta para la mayoría de equipos chicos
Si sois menos de 3 personas y menos de 10 servicios en un servidor, no migréis. Arreglad el dolor real en su lugar -- normalmente es "los despliegues cortan el servicio" (se resuelve con un contenedor azul/verde y un swap del upstream de nginx) o "solo yo sé desplegar" (se resuelve con un runbook documentado, no con un scheduler). Kubernetes resuelve problemas de escala, y crea uno nuevo -- un segundo sistema que operar -- que todavía no tenéis.