Comments 14
Ого, похоже, Хабр — снова торт!
Просто методичный перевод.
Скорее просто DeepL
В самом же начале - "может быть привести к проблемам"
Я бы даже сказал что это вышло "обновление" :)
Вопрос к знающим -- почему тут используются veth а не tap девайсы? И те и те получается можно цеплять к бриджу.
veth создаёт пару интерфейсов, точка-точка, один из которых можно отправить в отдельный namespace, другой в бридж. tap создаёт пару интрфейс - устройство в /dev и его нельзя одновременно добавить в бридж и отправить в другой namespace.
Ключевое отличие в том, что veth работают парами. Пакет, ушедший в veth, находящийся в контейнере, придет на парный veth, находящийся в каком угодно netns. Далее он подчиняется правилам обработки трафика. Всё это не выходя из ядра. Пакет, ушедший в tap, находящийся в контейнере, придет в процесс, который создал этот tap. Хотя процесс может быть в другом netns, то есть технически tap можно использовать для общения с контейнером, пакет выйдет из ядра и придется с ним что-то делать, чтобы доставить, когда с veth все богатство сетевого стека работает автоматически. Обычно нужен сценарий veth, хотя tap позволяет сделать обработку трафика в userspace.
Спасибо, разница ясно. Я привык к tap в kvm-виртуалках. Они именно что подхватываются через API с другой стороны обёрткой qemu.
спасибо за перевод! очень полезная статья :)
Кстати, автор оригинала (не переводчик) - местный старожил @iximiuz и у него в целом шикарный блог, даже целая лаборатория, хотя и на английском. Спасибо Ивану за очень доходчивые статьи!
Спасибо, интересное исследование
Про kubernetes подробнее надо
Отличная статья! Очень интересно и доступно, спасибо.
сколько было боли, когда я не мог просто так из контейнера работать с хостом на котором этот контейнер жил :))) это прям было очень больно и требовало курения очень большого количества гугла.
Еще бы сюда было бы неплохо добавить пример с каким нибудь веб контейнером или попугаем, который бы отвечал тебе с какого адреса ты к нему достучался. Потому что когда у тебя софт крутящийся в контейнере имеет фильтр по IP для доступа - выяснить для незнающего человека с какого адреса ты туда приходишь - очень сложно.
ну например у тебя в одном контейнере болтается VPN сервер к которому ты подключаешься, а в другом контейнере софт со списками доступа по IP. И вот как неподготовленному человеку понять с каким адресом ты приходишь во второй контейнер, подключившись к серваку через VPN? там появляется как минимум 5 вариантов и все неправильные :))))
Как работает сеть в контейнерах: Docker Bridge с нуля