Основные понятия сети для контейнеров Windows

10 мин

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

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

Сетевая изоляция и безопасность

Контейнеры Windows поддерживают два типа изоляции среды выполнения: процесса и Hyper-V. Основное различие заключается в степени изоляции, созданной между контейнером, операционной системой узла и другими контейнерами на этом узле.

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

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

Hyper-V изоляция обеспечивает повышенную безопасность и более широкую совместимость между узлом и контейнерами. Несколько экземпляров контейнеров выполняются на одном узле, но каждый контейнер выполняется на оптимизированной виртуальной машине. Виртуальная машина обеспечивает изоляцию на уровне оборудования между каждым контейнером и хостом контейнера.

Каждый контейнер по сути имеет собственное ядро.
Чтобы обеспечить сетевую изоляцию между контейнерами на узле, для каждого контейнера создается сетевое пространство имен.
Контейнеры запускаются в изоляции Hyper-V, где подключается виртуальный сетевой адаптер для контейнера. Контейнеры Windows Server используют адаптер виртуальной сети узла для подключения к виртуальному коммутатору. Hyper-V изоляция использует синтетический сетевой адаптер виртуальной машины (который не виден служебной виртуальной машине) для подключения к виртуальному коммутатору.

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

Управление сетью с помощью Host Network Service (HNS)

Windows использует сетевую службу узла (HNS) и службу вычислений узлов (HCS) для создания контейнеров и подключения конечных точек к сети.

Сетевой: HNS создает виртуальный коммутатор Hyper-V для каждой сети и формирует необходимые пулы NAT и IP.
конечные точки: HNS создает сетевое пространство имен для каждого контейнерного конечного сегмента, а HNS/HCS добавляет виртуальный сетевой адаптер в это пространство имен. HNS создает порты виртуального коммутатора. HNS назначает IP-адрес, сведения о системе доменных имен (DNS), маршрутах и т. д. конечной точке в соответствии с настроенным режимом сетевого драйвера.
Политики: Для сети NAT по умолчанию HNS создает правила пересылки портов WinNAT и сопоставления с соответствующими правилами брандмауэра Windows "ALLOW". Для всех других сетей HNS использует платформу виртуальной фильтрации (VFP) для создания политик балансировки нагрузки, списков управления доступом и инкапсуляции.

Взаимодействие с брандмауэром

В зависимости от конфигурации контейнера и типа сетевого драйвера списки управления доступом портов применяются сочетанием брандмауэра Windows и платформы виртуальной фильтрации Azure (VFP). Следующие значения используют брандмауэр хостов Windows (улучшенный с помощью сетевых пространств имен) и VFP:

Исходящий трафик по умолчанию: ALLOW ALL.
Входящий трафик по умолчанию: ALLOW ALL (TCP, UDP, ICMP, IGMP) неинициированный сетевой трафик. ЗАПРЕТИТЬ ВЕСЬ другой сетевой трафик, а не из этих протоколов.

Сетевые драйверы

Windows поддерживает пять различных сетевых драйверов или режимов для контейнеров Docker: NAT, Transparent, Overlay, L2Bridge и L2Tunnel. Помимо сети NAT по умолчанию, созданной Docker в Windows, можно также определить пользовательские сети контейнеров с помощью команды docker network create из Интерфейса командной строки Docker.

В следующей таблице перечислены типы сетевых драйверов, доступные для контейнеров Docker в Windows. Выберите сетевой драйвер, удовлетворяющий требованиям конфигурации физической сетевой инфраструктуры и узла (один или несколько узлов).

Сетевой драйвер	Типичные варианты использования	Контейнер — контейнер (один узел)	Контейнер к внешней среде (одиночный узел + многоузловая система)	Контейнер — контейнер (многоузловая версия)
NAT (по умолчанию)	Хорошо для разработчиков	Та же подсеть: мостовое подключение через виртуальный коммутатор Hyper-V Перекрестная подсеть: не поддерживается (только один внутренний префикс NAT)	Переадресованный через виртуальный сетевой адаптер для управления (привязанный к WinNAT)	Не поддерживается напрямую: требуется открытие портов через хост
прозрачный	Хорошо подходит для разработчиков или небольших развертываний	Та же подсеть: мостовое подключение через виртуальный коммутатор Hyper-V Перекрестная подсеть: перенаправлено через узел контейнера.	Перенаправлено через узел контейнера с прямым доступом к сетевому адаптеру (физическому)	Перенаправлено через узел контейнера с прямым доступом к сетевому адаптеру (физическому)
Наложение	Хорошо подходит для нескольких узлов; требуется для Docker Swarm, доступной в Kubernetes	Та же подсеть: мостовое подключение через виртуальный коммутатор Hyper-V Перекрестная подсеть: сетевой трафик инкапсулируется и направляется через адаптер виртуальной сети управления.	Не поддерживается напрямую. Требуется вторая конечная точка контейнера, подключенная к сети NAT в Windows Server 2016 или правиле VFP NAT в Windows Server 2019.	Та же или перекрестная подсеть: сетевой трафик инкапсулируется с помощью VXLAN и направляется через адаптер виртуальной сети управления
L2Bridge	Используется для Kubernetes и microsoft Software Designed Network (SDN)	Та же подсеть: мостовое подключение через виртуальный коммутатор Hyper-V Перекрестная подсеть: MAC-адрес контейнера перезаписывается на входе и выходе, а затем маршрутизируется.	MAC-адрес контейнера
перезапись при входе и выходе	Та же подсеть: мостовое подключение Межсетевой: маршрутизируется через виртуальный сетевой адаптер управления в версии WSv1809 и выше.
L2Tunnel	Только Azure	В пределах одной подсети/между подсетями: переадресация на виртуальный коммутатор Hyper-V физического узла для применения политики.	Трафик должен проходить через шлюз виртуальной сети Azure	Одинаковая или перекрестная подсеть: запущенный на виртуальный коммутатор физического узла Hyper-V, где применяется политика

Дополнительные параметры сети

Вы можете воспользоваться несколькими параметрами сетевого драйвера для конкретных возможностей и функций Windows. Ниже приведены некоторые примеры.

Получите доступ к Switch Embedded Teaming для сетевых узлов контейнеров, указав несколько сетевых адаптеров для контейнеров Windows.
Задайте идентификатор VLAN сети для настройки изоляции VLAN для любых конечных точек контейнера, которые подключаются к сети.
Укажите OutboundNAT политику для сети, чтобы разрешить вашему контейнеру доступ к внешнему миру.