Los tutoriales de Kubernetes hacen que todo parezca sencillo. En 20 minutos tenés un cluster corriendo, un deployment, un service, y la satisfacción de haber “aprendido Kubernetes”.
Lo que no te dicen es que ese cluster de tutorial y el de producción son dos cosas completamente distintas.
El gap de complejidad
En un cluster de producción real, necesitás resolver problemas que los tutoriales no mencionan:
- Gestión de secretos: ¿cómo rotás credenciales sin downtime? ¿usás Vault, AWS Secrets Manager, Sealed Secrets?
- Networking: ¿qué CNI elegís? ¿cómo manejás Network Policies? ¿cómo exponés servicios externamente con seguridad?
- Storage: PersistentVolumes en multi-zona es un problema no trivial, especialmente con cargas con estado.
- Monitoreo: métricas, logs y trazas son tres sistemas distintos que tienen que estar integrados.
- Upgrades: actualizar el control plane y los nodos sin afectar cargas de trabajo requiere un proceso maduro.
Lo que nadie te dice sobre el día 2
El “día 2” en Kubernetes es todo lo que pasa después de que el cluster está corriendo. Es operaciones, debugging, optimización de costos, gestión de capacidad.
Y es donde la mayoría de los equipos se encuentran sin las herramientas y el conocimiento necesario para operar bien.
¿Cuándo tiene sentido Kubernetes?
Kubernetes tiene sentido cuando:
- Tenés múltiples servicios que necesitan escalar independientemente
- Tenés un equipo que puede operar la plataforma (o usás un servicio gestionado)
- El beneficio de portabilidad y estandarización justifica la complejidad
No tiene sentido cuando:
- Tenés un monolito que funciona bien en EC2 o en un par de VMs
- No tenés un equipo con experiencia en Kubernetes
- Estás adoptándolo porque “todos lo usan”
Mi experiencia operando clusters
Después de operar clusters en producción durante varios años, lo que más diferencia los equipos maduros de los que sufren es la inversión en observabilidad y en runbooks.
Un cluster sin buenas alertas y sin procedimientos documentados para los problemas comunes es un cluster que va a generar incidentes en el peor momento posible.
La plataforma no es un fin en sí mismo. Es un medio para que los equipos de producto entreguen valor más rápido y con más confianza.
Si ese no es el resultado que estás viendo, vale la pena revisar si Kubernetes es la herramienta correcta o si la implementación necesita trabajo.
