АрхитектураОблако и инфраструктураИнженер по DevOps и облачной инфраструктуре

За счёт чего контейнеры на разных узлах кластера могут обмениваться по виртуальным адресам, хотя физическая...

За счёт чего контейнеры на разных узлах кластера могут обмениваться по виртуальным адресам, хотя физическая сеть не знает маршрутов к этим адресам?

Проходите собеседования с ИИ помощником Hintsage

Краткий ответ

Это обеспечивает оверлейная сеть: пакет с виртуальным адресом контейнера помещается внутрь внешнего пакета с адресами узлов кластера. Физическая сеть доставляет внешний пакет между узлами, а сетевой агент на узле удаляет внешнюю оболочку и передаёт внутренний пакет нужному контейнеру.

Исторический контекст

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

Оверлейный подход отделяет адресацию контейнеров от физической топологии. Он появился как практический способ динамически соединять рабочие нагрузки поверх уже существующей IP-сети, не требуя от неё понимания внутренней структуры кластера.

Постановка проблемы

Контейнер на одном узле должен обратиться к контейнеру на другом узле по виртуальному адресу. Однако маршрутизаторы физической сети видят только адреса узлов и могут отбросить пакет, если не знают маршрута к адресу контейнера.

Неправильная реализация приводит к потере пакетов, фрагментации из-за уменьшенного MTU, проблемам с доступом к внешним сервисам или ошибочному предположению, что оверлей сам по себе обеспечивает шифрование и изоляцию.

Подробное решение

Сетевой плагин или другой сетевой агент на исходном узле определяет, что адрес назначения находится на другом узле. Он формирует внешний пакет: его адресом источника становится адрес исходного узла, а адресом назначения — адрес узла, на котором находится контейнер. Исходный пакет сохраняется внутри внешнего пакета.

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

Оверлей не является единственным вариантом. В режиме маршрутизации без инкапсуляции узлы или сетевое оборудование могут объявлять маршруты к подсетям контейнеров, например через BGP. Такой вариант обычно уменьшает накладные расходы, но требует поддержки маршрутизации и согласованной настройки физической сети.

Инкапсуляция добавляет заголовки, поэтому эффективный MTU внутренней сети становится меньше MTU физической сети. Если это не учесть, крупные пакеты могут фрагментироваться или теряться при запрете фрагментации. Сетевой плагин должен корректно выбирать MTU, а диагностика должна проверять путь от контейнера до контейнера, а не только доступность узлов.

Оверлей отвечает за доставку пакета, но не обязательно за контроль доступа или шифрование. Политики сетевого доступа реализуются отдельными механизмами, а защита от прослушивания требует шифрования, например на уровне сетевого туннеля. Также нужно учитывать производительность: инкапсуляция увеличивает размер пакета и может повышать нагрузку на CPU.

Ситуация из практики

В кластере контейнеры на одном узле взаимодействовали нормально, а межузловые запросы с большими ответами периодически зависали. Были рассмотрены три варианта: оставить VXLAN без изменений, перейти на маршрутизацию через BGP или уменьшить MTU виртуальных интерфейсов.

Переход на BGP мог убрать накладные расходы оверлея, но требовал изменений в облачной сетевой инфраструктуре и усложнял эксплуатацию. Оставить настройки как есть было проще, но не устраняло риск потери крупных пакетов. Выбрали корректировку MTU и проверку прохождения ICMP-сообщений с установленным битом запрета фрагментации.

После согласования MTU виртуальных интерфейсов с накладными расходами туннеля межузловые запросы стабилизировались. Дополнительно в мониторинг добавили проверки межузлового трафика и отдельно задокументировали, что используемый оверлей не заменяет шифрование и сетевые политики.

Что кандидаты часто упускают

  1. Обязательно ли оверлейной сети использовать инкапсуляцию?

Нет. Оверлей означает логическую сеть, отделённую от физической топологии, но реализовать её можно разными способами. При VXLAN или Geneve используется инкапсуляция, а при маршрутизации подсетей контейнеров через BGP внутренний пакет может идти без дополнительной оболочки. Поэтому нельзя считать слова оверлей и туннель полными синонимами.

  1. Почему при работающем ping между узлами контейнерный трафик всё равно может не проходить?

Проверка узлов подтверждает только доступность underlay-сети. Она не доказывает корректность маршрутов контейнеров, таблиц инкапсуляции, правил брандмауэра, MTU и состояния виртуальных интерфейсов. Диагностировать нужно отдельно путь от контейнера до контейнера, включая адрес назначения, маршрут, внешний транспорт туннеля и обратный путь.

  1. Гарантирует ли оверлей, что контейнеры из разных сетевых сегментов не увидят друг друга?

Нет. Оверлей обеспечивает связность и адресацию, но уровень изоляции зависит от сетевого плагина и применяемых политик. Если политики не настроены или разрешают трафик слишком широко, контейнеры могут обмениваться пакетами независимо от логического разделения подсетей. Для конфиденциальности дополнительно требуется шифрование трафика.