Смена пула Docker по умолчанию не перенумеровывает сети

Изменение default-address-pools не перенумеровывает сети, которые у вас уже есть, и именно это ожидание превращает аккуратный план в неожиданный простой. Настройка управляет автоматическим выделением для сетей, создаваемых после перезапуска демона с новой конфигурацией. Всё, что уже работает, сохраняет выданную подсеть, потому что эта подсеть является частью сохранённого определения сети. Миф удобен, потому что предполагает, будто одно изменение исправляет любое пересечение, а реальность — работа из двух частей: выберите диапазон, который действительно свободен, и перенесите сети, которые такими не являются.

Миф: одно изменение пула исправляет пересечение

У мифа есть конкретная форма. Кто-то читает, что пул Docker по умолчанию можно изменить, меняет его, перезапускает демон и делает вывод, что сеть контейнеров больше не конфликтует с офисным VPN. Старая сеть всё ещё на месте, всё ещё подключена и всё ещё держит конфликтующий адрес.

Изменилось будущее поведение распределителя, что действительно полезно и действительно ограничено. Новые сети, созданные без явного --subnet, вырезаются из нового пула; существующие в этом пуле никогда не были. Перезапуск не перестраивает сети и не переносит контейнеры между ними. Если симптом сохраняется после изменения, изменение было настоящим, а диагноз — неполным.

Базовый диапазон и выделенный префикс

В конфигурации есть два поля, которые легко перепутать. base — это диапазон, из которого вырезает распределитель, а size — длина префикса каждой выделенной сети, поэтому база 10.10.0.0/16 с размером 24 раздаёт /24 внутри этого /16. Перепутанные роли дают схему распределения, которую вы не планировали, обычно одну огромную сеть или исчерпанный пул.

Пул — это резервирование, а не доказательство. Docker избегает конфликтов, которые видит в таблице маршрутизации хоста, и не может увидеть VPN, к которому вы ещё не подключились.

Это ограничение и есть вся причина выбирать осознанно. Диапазоны для сравнения — те, до которых хост должен дотянуться: офисная LAN, внутренние подсети корпоративного VPN, префиксы лаборатории или staging и любой другой контейнерный хост в том же overlay. Запишите их как CIDR, прежде чем трогать демон, потому что список в голове пропустит именно тот, который важен. Затем выберите базу, не пересекающуюся ни с одним из них, и храните список вместе с развёртыванием, чтобы следующий человек не повторял упражнение по памяти.

Опишите до выбора

Сначала опишите то, что существует. docker network ls перечисляет сети, а docker network inspect bridge -f '{{.IPAM.Config}}' печатает подсеть, которую использует конкретная сеть. Повторите для каждой сети, определённой пользователем, потому что проекты Compose создают свои, а явный --subnet в compose-файле полностью обходит пул.

Именно последний пункт переживает перенос. Изменение пула не мешает коллеге закрепить 172.18.0.0/16 в compose-файле, и конфликт возвращается с другим автором.

Перенос того, что уже есть

Перенос существующих сетей — отдельная поддерживаемая операция. Каждую затронутую сеть нужно пересоздать с новой подсетью, а значит отключить и снова подключить использующие её контейнеры, и пересоздание сети удаляет её привязки контейнеров, а не переносит их. Сохраните тома и конфигурацию и относитесь к пересозданию как к развёртыванию, а не как к сбросу данных. Делайте работу в окне обслуживания, потому что контейнеры в пересозданной сети перезапускаются независимо от того, планировали вы это или нет.

Следуйте документированной конфигурации демона и процедуре перезапуска и согласуйте перерыв. На хосте с одним демоном systemctl restart docker перезапускает контейнеры согласно их политикам перезапуска, и это поведение стоит знать заранее, а не после.

Затем проверьте две вещи, которые изменение должно было исправить. Изучите новую подсеть с помощью docker network inspect и подтвердите, что она внутри выбранной базы, затем проверьте маршрут к представительному VPN-назначению с помощью ip route get 10.20.30.40 и подтвердите, что он идёт туда, куда вы ожидаете, а не в мост. Проверьте также обнаружение сервисов и связь контейнеров между собой, потому что сеть, пересозданная с другой адресацией, может сломать разрешение имён так, что это выглядит как ошибка приложения.

Что всё ещё ломается потом

Долговечная часть — это запись. Храните список выделений, выбранные базу и размер, а также пересозданные сети там же, где развёртывание.

То, что диапазон приватный, не делает его безопасным для повторного использования. 10.0.0.0/8 приватен и при этом вероятнее всего уже где-то на пути используется, поэтому ответ — конкретное резервирование, а не предпочтение одному блоку. Документация по сетям Docker описывает автоматическое выделение подсетей и поля пула. Выбирайте диапазон по тому, до чего вам нужно дотянуться, а не по тому, что выглядит аккуратно.