Как устроен роутинг (маршрутизация) трафика в Docker?

Маршрутизация трафика в Docker обеспечивается его сетевой подсистемой, которая под капотом использует возможности Linux: network namespaces, virtual bridge interfaces и iptables.

Основные сетевые драйверы и их работа:

1. bridge (драйвер по умолчанию):

   • Docker создает виртуальный мост docker0 (или пользовательский br-xxx).
   • Каждый контейнер подключается к этому мосту через свою виртуальную пару интерфейсов (veth).
   • Контейнеры получают IP-адреса из подсети моста (например, 172.17.0.0/16).
   • Роутинг между контейнерами: Происходит на уровне L2 через мост. Контейнеры могут общаться по IP друг друга.
   • Роутинг наружу (интернет): Трафик из контейнера, направленный не в локальную подсеть, через правила iptables в таблице nat маскарадится (SNAT) на IP-адрес хоста.

2. host: Контейнер использует сетевой неймспейс хоста. Нет изоляции, контейнер «видит» все сетевые интерфейсы и порты хоста. Роутинг происходит по правилам хоста.

3. overlay: Используется в Docker Swarm и Kubernetes для связи контейнеров на разных физических хостах.

   • Создается overlay-сеть (например, 10.0.0.0/24).
   • На каждом хосте создается виртуальный интерфейс (типа VXLAN), который инкапсулирует трафик между хостами.
   • Встроенный DNS позволяет контейнерам находить друг друга по имени сервиса.

Практический пример и проверка:

# Создаем пользовательскую bridge-сеть
docker network create --driver bridge my-app-net

# Запускаем контейнер в этой сети
docker run -d --name web --network my-app-net nginx

# Проверяем маршрутизацию внутри контейнера
docker exec web ip route
# Вывод будет примерно: default via 172.19.0.1 dev eth0 ...
# Где 172.19.0.1 — это IP шлюза (bridge-интерфейса на хосте).

# Проверяем правила iptables, которые Docker добавил для NAT и изоляции
sudo iptables -t nat -L -n | grep docker

Таким образом, Docker полностью управляет маршрутизацией, изоляцией и NAT, абстрагируя это от пользователя, но понимание механизмов необходимо для диагностики проблем.