Сообщить об ошибкеКороткий ответ
Host networking даёт минимальные накладные расходы на пакет, но ломает изоляцию портов между контейнерами и усложняет multi-tenancy; user-defined bridge изолирует сервисы друг от друга при умеренном NAT-оверхеде; overlay-сети (для связи между хостами, например в Swarm) добавляют ещё больший оверхед ради мультихостовой связности — выбор зависит от конкретных требований к latency/throughput и допустимой сложности, а не от общей рекомендации.
Как это работает подробнее
каждый дополнительный уровень сетевой абстракции (NAT в bridge, VXLAN-инкапсуляция в overlay) добавляет вычислительные накладные расходы на обработку каждого пакета и потенциально увеличивает latency, но в обмен даёт изоляцию адресного пространства и упрощает маршрутизацию между множеством контейнеров/хостов без конфликтов портов.
Пример кода
$ docker run --network bridge --rm networkstatic/iperf3 -c target_bridge
$ docker run --network host --rm networkstatic/iperf3 -c target_hostЧто использовать на практике
- Практика. для latency-критичных нагрузок (например, высокочастотная обработка сообщений, где каждая микросекунда на пакет важна) host networking может быть осознанным выбором, принятым с пониманием, что контейнеры такого сервиса не могут использовать одинаковые порты на одном хосте и теряют сетевую изоляцию друг от друга. Для большинства обычных сервисов умеренный NAT-оверхед user-defined bridge незначим по сравнению с выгодой простой изоляции и многотенантности на одном хосте.
Подводные камни
- Риск. переходят на host networking "для производительности" без измерения фактической разницы в своей нагрузке, теряя изоляцию портов без реальной необходимости; выбирают overlay-сеть для связи контейнеров на одном хосте, хотя там достаточно обычного bridge, добавляя ненужный оверхед инкапсуляции.