Windows-Containernetzwerktreiber

  • Artikel

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

Zusätzlich zur Nutzung des standardmäßigen NAT-Netzwerks, das von Docker unter Windows erstellt wurde, können Benutzer benutzerdefinierte Containernetzwerke festlegen. Benutzerdefinierte Netzwerke können mithilfe des Docker CLI-Befehls docker network create -d <NETWORK DRIVER TYPE> <NAME> erstellt werden. Unter Windows stehen folgende Netzwerktreibertypen zur Verfügung:

NAT-Netzwerktreiber

Container, die an ein mit dem Nat-Treiber erstelltes Netzwerk angefügt sind, werden mit einem internen Hyper-V-Switch verbunden und erhalten eine IP-Adresse vom vom Benutzer angegebenen (--subnet) IP-Präfix. Portweiterleitung/-zuordnung vom Containerhost zu Containerendpunkten wird unterstützt.

Tipp

Es ist möglich, das Subnetz, das vom Standardmäßigen Nat-Netzwerk verwendet wird, über die fixed-cidr Einstellung in der Docker-Daemon-Konfigurationsdatei anzupassen.

Hinweis

NAT-Netzwerke, die unter Windows Server 2019 (oder höher) erstellt wurden, werden nach dem Neustart nicht mehr beibehalten.

Erstellen eines NAT-Netzwerks

So erstellen Sie ein neues NAT-Netzwerk mit Subnetz 10.244.0.0/24:

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

Transparenter Netzwerktreiber

Container, die an ein netzwerk angefügt werden, das mit dem "transparenten" Treiber erstellt wurde, werden über einen externen Hyper-V-Switch direkt mit dem physischen Netzwerk verbunden. IPs aus dem physischen Netzwerk können mithilfe eines externen DHCP-Servers statisch (erfordert eine benutzerdefinierte --subnet-Option) oder dynamisch zugewiesen werden.

Hinweis

Aufgrund der folgenden Anforderung wird das Verbinden Ihrer Containerhosts über ein transparentes Netzwerk auf Azure-VMs nicht unterstützt.

Erforderlich: Wenn dieser Modus in einem Virtualisierungsszenario (Containerhost ist eine VM) verwendet wird, ist spoofing für MAC-Adressen erforderlich.

Erstellen eines transparenten Netzwerks

So erstellen Sie ein neues transparentes Netzwerk mit Subnetz 10.244.0.0/24, Gateway 10.244.0.1, DNS-Server 10.244.0.7 und VLAN-ID 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

Überlagerungsnetzwerktreiber

Häufig von Container-Orchestratoren wie Docker Swarm und Kubernetes verwendet, können Container, die an ein Overlaynetzwerk angefügt sind, über mehrere Containerhosts mit anderen Containern kommunizieren, die an dasselbe Netzwerk angefügt sind. Jedes Overlaynetzwerk wird mit einem eigenen IP-Subnetz erstellt, das durch ein privates IP-Präfix definiert wird. Der Überlagerungsnetzwerktreiber verwendet die VXLAN-Kapselung, um eine Netzwerkdatenverkehrsisolation zwischen Mandantencontainernetzwerken zu erreichen und die Wiederverwendung von IP-Adressen über Overlaynetzwerke hinweg zu ermöglichen.

Erforderlich: Stellen Sie sicher, dass Ihre Umgebung die erforderlichen Voraussetzungen für das Erstellen von Overlaynetzwerken erfüllt.

Erforderlich: Unter Windows Server 2019 erfordert dies KB4489899.

Erfordert: Für Windows Server 2016 ist KB4015217 erforderlich.

Hinweis

Unter Windows Server 2019 und höher nutzen Überlagerungsnetzwerke, die von Docker Swarm erstellt wurden, VFP NAT-Regeln für ausgehende Konnektivität. Dies bedeutet, dass ein bestimmter Container 1 IP-Adresse empfängt. Dies bedeutet auch, dass ICMP-basierte Tools wie ping oder Test-NetConnection mithilfe ihrer TCP/UDP-Optionen in Debugsituationen konfiguriert werden sollten.

Erstellen eines Overlaynetzwerks

So erstellen Sie ein neues Überlagerungsnetzwerk mit Subnetz 10.244.0.0/24, DNS-Server 168.63.129.16und 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

L2bridge-Netzwerktreiber

Container, die an ein Mit dem l2bridge-Treiber erstelltes Netzwerk angefügt sind, werden über einen externen Hyper-V-Switch mit dem physischen Netzwerk verbunden. In l2bridge weist der Containernetzwerkdatenverkehr die gleiche MAC-Adresse wie der Host aufgrund des Vorgangs zur Übersetzung von Layer-2-Adressen (MAC-Re-Write) für eingehenden und ausgehenden Datenverkehr auf. In Rechenzentren trägt dies dazu bei, die Belastung von Switches zu verringern, die MAC-Adressen von manchmal kurzlebigen Containern lernen müssen. L2bridge-Netzwerke können auf 2 verschiedene Arten konfiguriert werden:

  1. Das L2bridge-Netzwerk ist mit demselben IP-Subnetz wie der Containerhost konfiguriert.
  2. Das L2bridge-Netzwerk ist mit einem neuen benutzerdefinierten IP-Subnetz konfiguriert.

In Konfiguration 2 müssen Benutzer einen Endpunkt im Hostnetzwerkbereich hinzufügen, der als Gateway fungiert, und Routingfunktionen für das angegebene Präfix konfigurieren.

Erstellen eines l2bridge-Netzwerks

So erstellen Sie ein neues l2bridge-Netzwerk mit Subnetz 10.244.0.0/24, Gateway 10.244.0.1, DNS-Server 10.244.0.7 und VLAN-ID 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

Tipp

L2bridge-Netzwerke sind stark programmierbar; Weitere Informationen zum Konfigurieren von l2bridge finden Sie hier.

L2tunnel-Netzwerktreiber

Die Erstellung ist identisch mit l2bridge, dieser Treiber sollte jedoch nur in einem Microsoft Cloud Stack (Azure) verwendet werden. Der einzige Unterschied zu l2bridge besteht darin, dass der gesamte Containerdatenverkehr an den Virtualisierungshost gesendet wird, auf den die SDN-Richtlinie angewendet wird, wodurch Features wie Azure-Netzwerksicherheitsgruppen für Container aktiviert werden.

Netzwerktopologien und IPAM

Die folgende Tabelle zeigt, wie die Netzwerkkonnektivität für interne (Container-zu-Container) und externe Verbindungen für jeden Netzwerktreiber bereitgestellt wird.

Netzwerkmodi/Docker-Treiber

Docker Windows-Netzwerktreiber Typische Verwendung Container-zu-Container (einzelner Knoten) Container-zu-Extern (einzelner Knoten und mehrere Knoten) Container-zu-Container (mehrere Knoten)
NAT (Standard) Gut für Entwickler*innen
  • Gleiches Subnetz: Überbrückte Verbindung über den virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Nicht unterstützt (nur ein internes NAT-Präfix)
 Routing über Verwaltungs-vNIC (an WinNAT gebunden) Nicht direkt unterstützt: Erfordert das Verfügbarmachen von Ports über den Host
Transparent Gut für Entwickler*innen oder kleine Bereitstellungen
  • Gleiches Subnetz: Überbrückte Verbindung über den virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Routing über Containerhost
 Weitergeleitet über den Containerhost mit direktem Zugriff auf den (physischen) Netzwerkadapter Weitergeleitet über den Containerhost mit direktem Zugriff auf den (physischen) Netzwerkadapter
Überlagerung Gut für mehrere Knoten; erforderlich für Docker Swarm, verfügbar in Kubernetes
  • Gleiches Subnetz: Überbrückte Verbindung über den virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Netzwerkdatenverkehr wird gekapselt und über Mgmt vNIC weitergeleitet
 Nicht direkt unterstützt: Erfordert einen zweiten Containerendpunkt, der an das NAT-Netzwerk auf Windows Server 2016 oder an die VFP-NAT-Regel unter Windows Server 2019 angefügt ist Gleiches/übergreifendes Subnetz: Netzwerkdatenverkehr wird mithilfe von VXLAN gekapselt und über Mgmt vNIC weitergeleitet
L2Bridge Wird für Kubernetes und Microsoft SDN verwendet
  • Gleiches Subnetz: Überbrückte Verbindung über den virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Container-MAC-Adresse, die bei eingehendem und ausgehendem Datenverkehr neu geschrieben und weitergeleitet wird
 Container-MAC-Adresse, die bei eingehendem und ausgehendem Datenverkehr neu geschrieben wird
  • Gleiches Subnetz: Überbrückte Verbindung
  • Subnetzübergreifendes Routing über Mgmt vNIC auf WSv1809 und höher
L2Tunnel Nur Azure Gleiches/übergreifendes Subnetz: An den virtuellen Hyper-V-Switch des physischen Hosts angeheftet, auf den die Richtlinie angewendet wird. Der Datenverkehr muss über das Gateway für virtuelle Azure-Netzwerke erfolgen. Gleiches/übergreifendes Subnetz: An den virtuellen Hyper-V-Switch des physischen Hosts angeheftet, auf den die Richtlinie angewendet wird.

IPAM

IP-Adressen werden von jedem Netzwerktreiber unterschiedlich belegt und diesem zugewiesen. Windows verwendet den Host-Netzwerkdienst (HNS), um dem NAT-Treiber IPAM bereitzustellen und arbeitet mit dem Docker-Schwarmmodus (interner KVS), um IPAM für die Überlagerung bereitzustellen. Alle anderen Netzwerktreiber verwenden eine externe IPAM.

Netzwerkmodus/Treiber IPAM
NAT Dynamische IP-Zuordnung und Zuweisung durch Host Networking Service (HNS) aus dem internen NAT-Subnetzpräfix
Transparent Statische oder dynamische IP-Zuordnung und Zuweisung von IP-Adressen innerhalb des Netzwerkpräfixes des Containerhosts
Überlagerung Dynamische IP-Zuordnung von verwalteten Präfixen und Zuweisungen über HNS
L2Bridge Dynamische IP-Zuordnung und -Zuweisung durch Host Networking Service (HNS) aus dem bereitgestellten Subnetzpräfix
L2Tunnel Nur Azure: Dynamische IP-Zuordnung und -Zuweisung über das Plug-In

Dienstsuche

Die Dienstermittlung wird nur für bestimmte Windows-Netzwerktreiber unterstützt.

Treibername Lokale Dienstermittlung Globale Dienstermittlung
NAT YES JA mit Docker EE
overlay YES JA mit Docker EE oder kube-dns
transparent Nein Nein
l2bridge JA mit kube-dns JA mit kube-dns