Udostępnij za pośrednictwem

Sterowniki sieciowe kontenerów systemu Windows

  • Artykuł

Dotyczy: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Oprócz korzystania z domyślnej sieci nat utworzonej przez platformę Docker w systemie Windows użytkownicy mogą definiować niestandardowe sieci kontenerów. Sieci zdefiniowane przez użytkownika można utworzyć przy użyciu interfejsu wiersza polecenia platformy Docker docker network create -d <NETWORK DRIVER TYPE> <NAME>. W systemie Windows dostępne są następujące typy sterowników sieciowych:

Sterownik sieci NAT

Kontenery dołączone do sieci utworzonej za pomocą sterownika nat będą połączone z wewnętrznym przełącznikiem Hyper-V i odbierają adres IP z prefiksu IP określonego przez użytkownika (--subnet). Obsługiwane jest przekierowywanie portów/mapowanie z hosta kontenera do punktów końcowych kontenera.

Napiwek

Istnieje możliwość dostosowania podsieci używanej przez domyślną sieć 'nat' za pośrednictwem ustawienia w fixed-cidr w pliku konfiguracji demona Dockera .

Notatka

Sieci NAT utworzone w systemie Windows Server 2019 (lub nowszym) nie są już utrwalane po ponownym uruchomieniu.

Tworzenie sieci NAT

Aby utworzyć nową sieć NAT z podsiecią 10.244.0.0/24:

docker network create -d "nat" --subnet "10.244.0.0/24" my_nat

Przezroczysty sterownik sieciowy

Kontenery dołączone do sieci utworzonej za pomocą sterownika "przezroczystego" będą bezpośrednio połączone z siecią fizyczną za pośrednictwem przełącznika Hyper-V zewnętrznego. Adresy IP z sieci fizycznej można przypisać statycznie (wymaga określonej przez użytkownika opcji --subnet) lub dynamicznie przy użyciu zewnętrznego serwera DHCP.

Notatka

Ze względu na następujące wymaganie łączenie hostów kontenerów za pośrednictwem przezroczystej sieci nie jest obsługiwane na maszynach wirtualnych platformy Azure.

Wymaga: jeśli ten tryb jest używany w scenariuszu wirtualizacji (host kontenera jest maszyną wirtualną), fałszowanie adresów MAC jest wymagane.

Tworzenie przezroczystej sieci

Aby utworzyć nową przezroczystą sieć przy użyciu 10.244.0.0/24podsieci, 10.244.0.1bramy, 10.244.0.7 serwera DNS i identyfikatora sieci VLAN 7:

docker network create -d "transparent" --subnet 10.244.0.0/24 --gateway 10.244.0.1 -o com.docker.network.windowsshim.vlanid=7 -o com.docker.network.windowsshim.dnsservers="10.244.0.7" my_transparent

Sterownik sieci nakładowej

Popularnie używane przez koordynatorów kontenerów, takich jak Docker Swarm i Kubernetes, kontenery dołączone do sieci nakładki mogą komunikować się z innymi kontenerami dołączonymi do tej samej sieci na wielu hostach kontenerów. Każda z sieci nakładkowych jest tworzona z własną podsiecią IP, zdefiniowaną przez prywatny prefiks adresu IP. Sterownik dla sieci nakładkowych używa hermetyzacji sieci typu VXLAN w celu zapewnienia izolacji ruchu sieciowego między sieciami kontenerów dzierżawy i umożliwia ponowne używanie adresów IP w sieciach nakładkowych.

Zalecenia: Upewnij się, że środowisko spełnia te wymagania niezbędne do tworzenia sieci nakładek.

Wymaga: w systemie Windows Server 2019 wymaga to KB4489899.

Wymaga: na Windows Server 2016 jest to wymagane KB4015217.

Notatka

W systemie Windows Server 2019 i nowszych sieci nakładkowe utworzone przez usługę Docker Swarm korzystają z reguł NAT protokołu VFP na potrzeby łączności wychodzącej. Oznacza to, że dany kontener otrzymuje 1 adres IP. Oznacza to również, że narzędzia oparte na protokole ICMP, takie jak ping lub Test-NetConnection, powinny być skonfigurowane przy użyciu ich opcji TCP/UDP w sytuacjach debugowania.

Tworzenie sieci nakładki

Aby utworzyć nową sieć nakładki z podsiecią 10.244.0.0/24, serwerem DNS 168.63.129.16oraz VSID 4096:

docker network create -d "overlay" --attachable --subnet "10.244.0.0/24" -o com.docker.network.windowsshim.dnsservers="168.63.129.16" -o com.docker.network.driver.overlay.vxlanid_list="4096" my_overlay

Sterownik sieciowy L2bridge

Kontenery dołączone do sieci utworzonej za pomocą sterownika l2bridge będą połączone z siecią fizyczną za pośrednictwem zewnętrznego przełącznika Hyper-V zewnętrznego. W systemie l2bridge ruch sieciowy kontenera będzie miał ten sam adres MAC co host ze względu na operację translacji adresów warstwy 2 (ponowne zapisywanie adresów MAC) na ruchu przychodzącym i wychodzącym. W tych centrach danych pomaga to złagodzić obciążenie przełączników, które muszą uczyć się adresów MAC niekiedy krótkotrwałych kontejnerów. Sieci L2bridge można skonfigurować na 2 różne sposoby:

  1. Sieć L2bridge jest skonfigurowana z tą samą podsiecią IP co host kontenera
  2. Sieć L2bridge jest skonfigurowana przy użyciu nowej niestandardowej podsieci IP

W konfiguracji 2 użytkownicy będą musieli dodać punkt końcowy w przedziale sieci hosta, który działa jako brama i skonfigurować możliwości routingu dla wyznaczonego prefiksu.

Tworzenie sieci l2bridge

Aby utworzyć nową sieć l2bridge z podsiecią 10.244.0.0/24, bramą 10.244.0.1, serwerem DNS 10.244.0.7 i identyfikatorem VLAN 7:

docker network create -d "l2bridge" --subnet 10.244.0.0/24 --gateway 10.244.0.1 -o com.docker.network.windowsshim.vlanid=7 -o com.docker.network.windowsshim.dnsservers="10.244.0.7" my_l2bridge

Napiwek

Sieci L2bridge są wysoce programowalne; Więcej szczegółów na temat konfigurowania biblioteki l2bridge można znaleźć tutaj.

Sterownik sieciowy L2tunnel

Tworzenie jest identyczne z l2bridge, jednak ten sterownik powinien być używany tylko na platformie Microsoft Cloud Stack (Azure). Jedyną różnicą między l2bridge jest to, że cały ruch kontenera jest wysyłany do hosta wirtualizacji, na którym są stosowane zasady sieci SDN, umożliwiając w ten sposób funkcje, takie jak sieciowych grup zabezpieczeń platformy Azure dla kontenerów.

Topologie sieci i usługa IPAM

W poniższej tabeli przedstawiono sposób zapewniania łączności sieciowej dla wewnętrznych (kontener-kontener) i połączeń zewnętrznych dla każdego sterownika sieciowego.

Tryby sieciowe/sterowniki platformy Docker

Sterownik sieciowy platformy Docker dla systemu Windows Typowe zastosowania Kontener-kontener (pojedynczy węzeł) Kontener do zewnętrznego użytku (pojedynczy węzeł + wiele węzłów) Kontener-kontener (wiele węzłów)
NAT (ustawienie domyślne) Dobre dla deweloperów
  • Ta sama podsieć: połączenie mostkowane za pośrednictwem przełącznika wirtualnego Hyper-V
  • Podsieciowanie krzyżowe: nieobsługiwane (tylko jeden wewnętrzny prefiks NAT)
 Kierowanie za pośrednictwem wirtualnej karty sieciowej zarządzania (powiązanej z WinNAT) Bezpośrednie wsparcie niedostępne: wymaga otwarcia portów przez hosta
przezroczysty Dobre dla deweloperów lub małych wdrożeń
  • Ta sama podsieć: połączenie mostowe za pośrednictwem przełącznika wirtualnego Hyper-V
  • Ruch pomiędzy podsieciami: przekazywany za pośrednictwem hosta kontenera
 Przekierowany przez hosta kontenera z bezpośrednim dostępem do (fizycznej) karty sieciowej. Kierowany przez hosta kontenera z bezpośrednim dostępem do karty sieciowej (fizycznej)
nakładki Dobre dla wielu węzłów; wymagane dla platformy Docker Swarm dostępnej w rozwiązaniu Kubernetes
  • Ta sama podsieć: połączenie mostkowane za pośrednictwem przełącznika wirtualnego Hyper-V
  • Podsieć krzyżowa: ruch sieciowy jest hermetyzowany i kierowany za pośrednictwem wirtualnej karty sieciowej Mgmt
 Nieobsługiwane bezpośrednio — wymaga drugiego punktu końcowego kontenera dołączonego do sieci NAT w systemie Windows Server 2016 lub zasady NAT VFP w systemie Windows Server 2019. Ta sama/krzyżowa podsieć: Ruch sieciowy jest hermetyzowany przy użyciu sieci VXLAN i kierowany za pośrednictwem wirtualnej karty sieciowej Mgmt
L2Bridge Używane na potrzeby platformy Kubernetes i sieci SDN firmy Microsoft
  • Ta sama podsieć: połączenie mostkowane za pośrednictwem przełącznika wirtualnego Hyper-V
  • Między podsieciami: adres MAC kontenera jest ponownie zapisywany podczas ruchu przychodzącego i wychodzącego oraz kierowany.
 Adres MAC kontenera jest zapisywany ponownie na ruchu przychodzącym i wychodzącym
  • Ta sama podsieć: połączenie mostkowane
  • Między podsieciami: kierowane za pośrednictwem wirtualnej karty sieciowej mgmt w programie WSv1809 lub nowszym
L2Tunnel Tylko platforma Azure Ta sama/krzyżowa podsieć: przyporządkowana do przełącznika wirtualnego Hyper-V hosta fizycznego, gdzie stosuje się zasady Ruch musi przechodzić przez bramę sieci wirtualnej platformy Azure Ta sama/odrębna podsieć: przelotowo przypięta do przełącznika wirtualnego Hyper-V hosta fizycznego, w miejscu zastosowania polityki

IPAM

Adresy IP są przydzielane i przypisywane inaczej dla każdego sterownika sieciowego. System Windows używa Host Networking Service (HNS) do zapewnienia usługi IPAM dla sterownika nat i współpracuje z Docker Swarm Mode (wewnętrzny KVS) w celu zapewnienia usługi IPAM dla overlay. Wszystkie inne sterowniki sieciowe używają zewnętrznego protokołu IPAM.

Tryb sieciowy/sterownik IPAM
NAT Dynamiczna alokacja i przypisywanie adresów IP przez usługę sieci hosta (HNS) z wewnętrznego prefiksu podsieci translatora adresów sieciowych
Przejrzysty Statyczna lub dynamiczna (przy użyciu zewnętrznego serwera DHCP) alokacja i przypisywanie adresów IP z zakresu prefiksu sieci hosta kontenera.
Nakładka Dynamiczna alokacja adresów IP z zarządzanych prefiksów przez Silnik Docker w trybie Swarm i przypisań przez HNS
L2Bridge Dynamiczne przydzielanie i przypisywanie adresów IP przez usługę sieciową hosta (HNS) z podanego prefiksu podsieci
L2Tunnel Tylko platforma Azure — dynamiczna alokacja i przypisywanie adresów IP z wtyczki

Odnajdywanie usług

Odnajdywanie usługi jest obsługiwane tylko w przypadku niektórych sterowników sieciowych systemu Windows.

Nazwa sterownika Odnajdywanie usługi lokalnej Globalne odnajdywanie usług
NAT (tłumaczenie adresów sieciowych) TAK TAK w usłudze Docker EE
pokrycie TAK TAK w przypadku platformy Docker EE lub kube-dns
przejrzysty NIE NIE
l2bridge TAK z kube-dns TAK z kube-dns