Kubernetes para los reacios: cuándo no usarlo

He operado Kubernetes en producción. Me gusta Kubernetes. También he visto a diez equipos adoptarlo por motivos que se reducían a “todo el mundo lo tiene” y los he visto arrepentirse durante los siguientes dieciocho meses.

Kubernetes es excelente cuando tu problema se parece al que Kubernetes fue diseñado para resolver. La trampa es que el problema que tienes el día uno casi nunca se parece a eso — pero Kubernetes es tan dominante culturalmente que adoptarlo se siente más seguro que las alternativas. Normalmente no lo es.

Estas son las cuatro señales que miro.

Señal 1: tienes un producto, una base de datos y un deploy a la semana

Si tu organización de ingeniería opera una sola aplicación, con una sola base de datos detrás, y entrega una release por semana, la plataforma de despliegue correcta es una VM con systemd, detrás de un reverse proxy. Vas a resolver todos los problemas que tengas durante los próximos dos años con git pull && systemctl restart, y la persona de guardia va a dormir.

Kubernetes es para cuando tienes N servicios en M nodos y necesitas planificarlos. Si N es 1 y M es 1, el scheduler no hace nada, y pagas el coste operativo (el YAML, los upgrades, la elección de network plugin, el ingress controller, cert-manager, el stack de métricas) a cambio de nada.

Señal 2: nadie en el equipo ha operado un servicio con estado en producción

Kubernetes hace los workloads sin estado fáciles y los workloads con estado engañosamente fáciles. Los tutoriales te enseñan un StatefulSet de Postgres de tres líneas que arranca felizmente. La realidad es que en tres meses vas a tener un evento de node-disk-pressure, y la diferencia entre “perdemos 30 segundos” y “perdemos la base de datos” es si escribiste el podAntiAffinity correcto, dimensionaste bien los PVCs, configuraste la storage class para retención y ensayaste el failover.

Si nadie en el equipo ha llevado el pager de una base de datos antes, no metas tu base de datos en Kubernetes. Usa un Postgres gestionado (RDS, Cloud SQL, Crunchy, Neon, lo que sea). Corre tus apps stateless en K8s si hace falta. Que la base de datos sea problema de otro hasta que tengas un ingeniero senior cuyo trabajo sea “la base de datos en K8s”.

Señal 3: no sabes describir qué posee tu platform team

El supuesto no escrito de Kubernetes es que alguien va a mantener el clúster sano. Upgrades cada trimestre. Comprobaciones de compatibilidad entre plugins. Observabilidad del propio control plane. La ruta del ingress que se rompe al actualizar el Helm chart. El driver CSI que tiene un known issue.

En una adopción seria, ese “alguien” es un platform team. Son uno o dos ingenieros, full-time. Si no los tienes y no puedes contratarlos, estás a punto de hacer que esas tareas sean el trabajo part-time de alguien cuyo trabajo real es entregar producto. Lo va a aborrecer, el clúster se va a degradar, y la siguiente versión de tu decisión de plataforma va a ser “nos estamos migrando fuera de K8s”.

Un control plane gestionado (EKS, GKE, AKS) reduce mucho este coste. No lo elimina. El día que un nodo se vuelva no-planificable, el diagnóstico sigue siendo tuyo.

Señal 4: tu cuello de botella no es el deploy, es el producto

Esta es la que nadie quiere oír. Kubernetes optimiza la velocidad de desplegar muchos servicios a muchos entornos. Si el cuello de botella de tu equipo es “entregamos features despacio”, Kubernetes no va a mover la aguja, porque entregar despacio casi nunca es un problema de deploy. Es un problema de producto, o de organización, o de tooling aguas arriba del deploy.

Mira honestamente los últimos seis meses. ¿Dónde fue el tiempo? Si la respuesta es “discovery, diseño, código, review, QA”, entonces Kubernetes no es la respuesta. Despliegue aburrido + obsesionarse con la parte lenta sí lo es.

---

¿Cuándo se gana Kubernetes su sitio? Cuando tienes muchos servicios, múltiples entornos, necesidades reales de autoscaling, un platform team que lo posee y una cultura que de verdad entiende lo que dice el YAML. En ese punto no es “Kubernetes es pesado”; es “Kubernetes hace lo que necesitamos”.

Hasta entonces: una VM, systemd y un reverse proxy. Han entregado más software fiable que todos los clústers de Kubernetes juntos.