George Sims explica en un material publicado en el blog de CNCF el 3 de septiembre de 2026 una experiencia de migración de un servicio de autenticación esencial en un clúster de Kubernetes desde el default namespace a un espacio de nombres dedicado, sin detener el servicio. El servicio, al que el autor llamó auth-svc, era utilizado constantemente por decenas de servicios y era responsable de autenticar a los usuarios en una zona completa del clúster; por ello, su interrupción habría impedido iniciar sesión en esa zona.
El problema no consistía simplemente en trasladar un objeto Deployment a otro espacio de nombres. Los consumidores dentro del clúster accedían al servicio mediante el nombre auth-svc.default.svc.cluster.local, mientras que los usuarios externos al clúster accedían a él mediante un Ingress independiente. Además, los servicios consumidores pertenecían a equipos diferentes y funcionaban con calendarios de lanzamiento distintos, lo que hacía poco práctico modificar todas las referencias al mismo tiempo.
¿Por qué no basta con trasladar el servicio y actualizar las referencias?
El autor señala que el pipeline de despliegue solo admitía desplegar el servicio en un único espacio de nombres y no estaba diseñado para ejecutar dos versiones simultáneas. Modificar la lógica del pipeline compartido habría afectado a otros equipos, algo que el equipo quería evitar. Asimismo, existía una política basada en OPA que impedía que hubiera reglas de Ingress idénticas en dos espacios de nombres al mismo tiempo, para evitar un enrutamiento ambiguo derivado de una migración incompleta.
Por esta razón, la solución no se basó en obligar a cada consumidor a conocer la nueva dirección, sino en mantener temporalmente válida la dirección antigua y redirigirla al servicio migrado.
ExternalName como dirección de redirección
Después de desplegar la versión real del servicio en el nuevo espacio de nombres authentication, el objeto Service antiguo en default se convirtió en un servicio de tipo ExternalName. Su nombre pasó a apuntar a auth-svc.authentication.svc.cluster.local, de modo que los servicios que utilizaban la dirección antigua pudieran seguir accediendo a la nueva versión sin cambios inmediatos en su código ni un nuevo despliegue.
El autor compara este mecanismo con un servicio de reenvío postal: no es necesario contactar con todos los que tienen la dirección antigua, sino que las solicitudes se dirigen a la nueva ubicación hasta que las partes consumidoras actualicen gradualmente sus direcciones. Sin embargo, este método depende de que los consumidores utilicen un nombre DNS; si algunos sistemas se conectan a una dirección IP fija o evitan DNS, el problema será diferente y la migración requerirá otro tratamiento.
Antes de detener la versión antigua, el equipo supervisó las métricas para asegurarse de que las solicitudes recibidas en la dirección antigua llegaran realmente al nuevo Deployment y no fallaran ni entraran en un bucle de redirección. Tras la verificación, el número de réplicas antiguas se redujo a cero en lugar de eliminarlas directamente. Esto permitió disponer de una vía de reversión rápida mediante el reinicio de las réplicas antiguas si aparecía algún problema, dejando la eliminación definitiva para más adelante.
Gestión del conflicto de Ingress
La ruta de acceso externa necesitaba un Ingress en el nuevo espacio de nombres antes de eliminar el Ingress antiguo. Sin embargo, la política de OPA impedía crear ambas reglas idénticas al mismo tiempo. Por ello, el equipo utilizó una excepción temporal y específica en lugar de desactivar la política por completo: se añadió una etiqueta al espacio de nombres authentication para permitir omitir la comprobación de duplicación de Ingress durante la migración, utilizando la clave policy.example.com/allow-duplicate-ingress: "true".
Durante la breve ventana de solapamiento, el nuevo Ingress se ejecutó junto con el antiguo y después se verificó que el tráfico llegara al nuevo Deployment. A continuación, se eliminó el Ingress antiguo y se dejó que la excepción temporal expirara, en lugar de considerarla una configuración permanente.
¿Qué cambia en la práctica?
La experiencia muestra que la migración de un servicio sensible no requiere necesariamente coordinarse simultáneamente con todos los consumidores si existe un límite claro basado en DNS. No obstante, esto no elimina la necesidad de realizar pruebas por fases, una supervisión minuciosa y un plan de reversión. El equipo ejecutó el proceso primero en el entorno de desarrollo y después en el entorno de pruebas, y esperó dos semanas tras el éxito de la fase de pruebas antes de ejecutarlo en producción.
La lección más amplia es que la acumulación de servicios dentro del default namespace puede pasar inadvertida hasta que el servicio necesita políticas o recursos restringidos a un espacio de nombres dedicado. En ese momento, la deuda operativa se convierte en un problema real. ExternalName ofrece una ruta práctica para los servicios que dependen de DNS, pero no es una solución general para los sistemas que utilizan direcciones fijas; además, tanto la ventana de solapamiento como la excepción de seguridad deben ser intencionadas y temporales, y estar acompañadas de mediciones claras.