Bitácora técnica · migración de servicios
Migrar un servicio legado a contenedores: errores que se repiten
Supuestos sobre estado, red y arranque que rompen la primera versión
El contenedor arranca en la laptop sin drama. Lo subís al clúster y a los pocos minutos empieza a reiniciarse. Casi nunca es un problema del runtime: es el servicio legado que daba por sentadas cosas que en un pod ya no existen. Rutas absolutas que apuntan a un disco que no está montado, un archivo de configuración que se escribía en /var/lib/app y ahora vive en una capa efímera, o una conexión a una base que se resolvía por nombre de host del servidor viejo.
Antes de exponer tráfico conviene hacer una pasada por tres frentes. Primero, el estado: revisá qué escribe el proceso en disco y si eso sobrevive a un reinicio del pod. Segundo, la red: listá cada dependencia saliente y confirmá que resuelve dentro del clúster, no por un hosts heredado. Tercero, el arranque: medí cuánto tarda el servicio en aceptar la primera petición real, no en abrir el puerto.
Ese último punto es el que más dolores de cabeza genera. Muchos servicios legados abren el socket antes de terminar de cargar cachés, índices o pools de conexiones. Si la sonda de readiness solo verifica que el puerto responde, va a mandar tráfico a un proceso que todavía no está listo y vas a ver errores intermitentes que no aparecen en local. La liveness, por su parte, no debería reiniciar un arranque lento: separá los tiempos y dejá que la readiness haga el trabajo de contener el tráfico.
La configuración del entorno es otro punto donde se rompe la imagen. Si el servicio lee variables de entorno, rutas o credenciales embebidas en el build, cada cambio obliga a reconstruir. Conviene mover todo lo que cambia entre entornos a variables o a un volumen montado, y dejar en la imagen solo lo que es igual en todos lados. Así el mismo artefacto pasa por staging y producción sin sorpresas.
Nada de esto es teoría de manual: son los patrones que aparecen una y otra vez cuando un servicio que llevaba años corriendo en una VM se muda a un clúster. La secuencia de verificación antes de exponer tráfico ahorra la mayor parte de los reinicios en cascada.