Cambiar el pool predeterminado de Docker no renumera las redes

Cambiar default-address-pools no renumera las redes que ya tiene, y esperarlo es justo cómo un plan cuidadoso se convierte en una caída inesperada. El ajuste gobierna la asignación automática de las redes creadas después de que el demonio se reinicie con la nueva configuración. Todo lo que ya funciona conserva la subred que se le dio, porque esa subred forma parte de la definición guardada de la red. El mito es cómodo porque sugiere que una sola edición arregla cada solapamiento, y la realidad es un trabajo en dos partes: elija un rango que esté realmente libre y luego migre las redes que no lo están.

El mito: un solo cambio de pool arregla el solapamiento

El mito tiene una forma concreta. Alguien lee que el pool predeterminado de Docker se puede cambiar, lo cambia, reinicia el demonio y concluye que la red de contenedores ya no choca con la VPN de la oficina. La red antigua sigue ahí, sigue conectada y sigue teniendo la dirección que choca.

Lo que cambió es el comportamiento futuro del asignador, que es realmente útil y realmente limitado. Las redes nuevas creadas sin un --subnet explícito se recortan del pool nuevo; las existentes nunca estuvieron en ese pool. Un reinicio no reconstruye redes ni mueve contenedores entre ellas. Si el síntoma persiste después del cambio, el cambio fue real y el diagnóstico estaba incompleto.

Rango base y prefijo asignado

La configuración tiene dos campos que es fácil confundir. base es el rango del que recorta el asignador, y size es la longitud de prefijo de cada red asignada, así que una base 10.10.0.0/16 con tamaño 24 reparte /24 dentro de ese /16. Invertir los papeles produce un patrón de asignación que no pretendía, normalmente una red enorme o un pool agotado.

Un pool es una reserva, no una prueba. Docker evita los conflictos que ve en la tabla de enrutamiento del host y no puede ver una VPN a la que todavía no se ha conectado.

Esa limitación es todo el motivo para elegir con deliberación. Los rangos con los que comparar son los que el host debe alcanzar: la LAN de la oficina, las subredes internas de la VPN corporativa, los prefijos del laboratorio o de staging y cualquier otro host de contenedores en el mismo overlay. Anótelos como CIDR antes de tocar el demonio, porque una lista en la cabeza se saltará justo la que importa. Luego elija una base que no se solape con ninguno y guarde la lista junto al despliegue para que la siguiente persona no repita el ejercicio de memoria.

Inventaríe antes de elegir

Primero inventaríe lo que existe. docker network ls lista las redes, y docker network inspect bridge -f '{{.IPAM.Config}}' imprime la subred que usa una concreta. Repítalo para cada red definida por el usuario, porque los proyectos Compose crean las suyas y un --subnet explícito en un archivo compose se salta el pool por completo.

Ese último punto es el que sobrevive a la migración. Un cambio de pool no impide que un colega fije 172.18.0.0/16 en un archivo compose, y el conflicto vuelve con otro autor.

Migrar lo que ya existe

Migrar las redes existentes es una operación aparte y compatible. Cada red afectada debe recrearse con la subred nueva, lo que significa desconectar y volver a conectar los contenedores que la usan, y recrear una red elimina sus conexiones de contenedores en lugar de moverlas. Conserve los volúmenes y la configuración y trate la recreación como un despliegue, no como un reinicio de datos. Haga el trabajo en una ventana de mantenimiento, porque los contenedores de una red recreada se reinician tanto si lo planificó como si no.

Siga la configuración del demonio y el procedimiento de reinicio documentados, y coordine la interrupción. En un host con un solo demonio, systemctl restart docker reinicia los contenedores según sus políticas de reinicio, y ese es un comportamiento que conviene conocer antes y no después.

Luego verifique las dos cosas que el cambio debía arreglar. Inspeccione la subred nueva con docker network inspect y confirme que está dentro de la base elegida, y después compruebe la ruta hacia un destino VPN representativo con ip route get 10.20.30.40 y confirme que va adonde espera y no hacia un puente. Pruebe también el descubrimiento de servicios y la comunicación entre contenedores, porque una red recreada con otro direccionamiento puede romper la resolución de nombres de formas que parecen un error de la aplicación.

Qué sigue rompiéndose después

La parte duradera es el registro. Guarde la lista de asignaciones, la base y el tamaño elegidos y las redes recreadas en el mismo lugar que el despliegue.

Que un rango sea privado no lo hace seguro para reutilizar. 10.0.0.0/8 es privado y también lo más probable que ya esté en uso en algún punto del camino, por eso la respuesta es una reserva concreta y no una preferencia por un bloque. La documentación de redes de Docker describe la asignación automática de subredes y los campos del pool. Elija el rango por lo que debe alcanzar, no por lo que parece ordenado.