Freigeben über

Windows-Containernetzwerktreiber

  • Artikel

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

Neben der Nutzung des standardmäßigen nat-Netzwerks, das von Docker unter Windows erstellt wird, können Benutzer benutzerdefinierte Containernetzwerke definieren. Benutzerdefinierte Netzwerke können mit dem Befehl Docker CLI docker network create -d <NETWORK DRIVER TYPE> <NAME> erstellt werden. Unter Windows sind die folgenden Netzwerktreibertypen verfügbar:

NAT-Netzwerktreiber

Container, die an ein mit dem „nat“-Treiber erstelltes Netzwerk angeschlossen sind, werden mit einem internen Hyper-V-Switch verbunden und erhalten eine IP-Adresse aus dem benutzerdefinierten (--subnet) IP-Präfix. Portweiterleitung/Zuordnung vom Containerhost zu Containerendpunkten wird unterstützt.

Tipp

Es ist möglich, das vom standardmäßigen Nat-Netzwerk verwendete Subnetz über die Einstellung fixed-cidr in der Docker-Daemon-Konfigurationsdateianzupassen.

Anmerkung

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 mit dem „transparenten“ Treiber erstelltes Netzwerk angeschlossen sind, werden über einen externen Hyper-V-Switch direkt mit dem physischen Netzwerk verbunden. IPs aus dem physischen Netzwerk können statisch zugewiesen werden (erfordert die vom Benutzer angegebene Option --subnet) oder dynamisch durch einen externen DHCP-Server zugewiesen werden.

Anmerkung

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 verwendet wird (Containerhost ist eine VM), ist das Spoofing von 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-Schwarm und Kubernetes verwendet werden, können container, die an ein Überlagerungsnetzwerk angeschlossen sind, mit anderen Containern kommunizieren, die mit demselben Netzwerk über mehrere Containerhosts verbunden sind. Jedes Überlagerungsnetzwerk wird mit einem eigenen IP-Subnetz erstellt, das durch ein privates IP-Präfix definiert wird. Der Überlagerungsnetzwerktreiber verwendet die VXLAN-Kapselung, um die Netzwerkverkehrsisolation zwischen den Mandantencontainernetzwerken zu erreichen und ermöglicht die Wiederverwendung von IP-Adressen in Overlay-Netzwerken.

Erforderlich: Stellen Sie sicher, dass Ihre Umgebung diese erforderlichen Voraussetzungen zum Erstellen von Überlagerungsnetzwerken erfüllt.

Erforderlich: Unter Windows Server 2019 ist KB4489899 erforderlich.

Erforderlich: Unter Windows Server 2016 ist KB4015217 erforderlich.

Anmerkung

Unter Windows Server 2019 und höher nutzen Überlagerungsnetzwerke, die von Docker-Schwarm erstellt wurden, VFP NAT-Regeln für ausgehende Verbindungen. 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 Überlagerungsnetzwerks

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

Mit dem "l2bridge"-Treiber erstellte Container werden über einen externen Hyper-V Switch mit dem physischen Netzwerk verbunden. In l2bridge verfügt der Containernetzwerkdatenverkehr über dieselbe MAC-Adresse wie der Host aufgrund des Layer-2-Adressübersetzungsvorgangs (MAC re-write) beim Eingangs- und Ausgangsvorgang. In Rechenzentren hilft dies, den Stress bei Schaltern zu verringern, die MAC-Adressen von manchmal kurzlebigen Containern erlernen 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. L2bridge-Netzwerk ist mit einem neuen benutzerdefinierten IP-Subnetz konfiguriert.

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

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-Netze sind sehr programmierbar; Weitere Details zum Konfigurieren von l2bridge finden Sie hier.

L2tunnel-Netzwerktreiber

Creation ist identisch mit l2bridge, dieser Treiber sollte jedoch nur in einem Microsoft Cloud-Stapel (Azure) verwendet werden. Der einzige Unterschied gegenüber l2bridge besteht darin, dass der gesamte Containerdatenverkehr an den Virtualisierungshost gesendet wird, auf den SDN-Richtlinie angewendet wird, wodurch Features wie Azure Network Security Groups 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 Verwendungen Container-zu-Container (einzelner Knoten) Container-zu-extern (einzelner Knoten und mehrere Knoten) Container-zu-Container (mehrere Knoten)
NAT (Standard) Gut für Entwickler
  • Gleiches Subnetz: Überbrückte Verbindung über virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Nicht unterstützt (nur ein internes NAT-Präfix)
 Routing durch Verwaltungs-vNIC (gebunden an WinNAT) Nicht direkt unterstützt: Erfordert das Verfügbarmachen von Ports über den Host
Transparent Gut für Entwickler oder kleine Bereitstellungen
  • Gleiches Subnetz: Überbrückte Verbindung über virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Routing durch Containerhost
 Routing durch Containerhost mit direktem Zugriff auf (physische) Netzwerkadapter Routing durch Containerhost mit direktem Zugriff auf (physische) Netzwerkadapter
Überlagerung Gut für mehrere Knoten. Erforderlich für Docker Swarm, verfügbar in Kubernetes.
  • Gleiches Subnetz: Überbrückte Verbindung über 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 unter Windows Server 2016 oder VFP NAT-Regel unter Windows Server 2019 angefügt ist. Same/Cross Subnet: Netzwerkdatenverkehr wird mit VXLAN gekapselt und über Mgmt vNIC weitergeleitet
L2Bridge Wird für Kubernetes und Microsoft SDN verwendet
  • Gleiches Subnetz: Überbrückte Verbindung über virtuellen Hyper-V-Switch
  • Subnetzübergreifend: Die MAC-Adresse des Containers wird beim Eingangs- und Ausgangsprozess neu geschrieben und weitergeleitet.
 Container-MAC-Adresse, die beim Eingangs- und Ausgang neu geschrieben wurde
  • Gleiches Subnetz: Überbrückte Verbindung
  • Subnetzübergreifend: Routing durch Verwaltungs-vNIC für WSv1809 und höher
L2Tunnel Nur Azure Gleiches Subnetz/Subnetzübergreifend: An den virtuellen Hyper-V-Switch des physischen Hosts gebunden, auf den die Richtlinie angewendet wird Datenverkehr muss über das virtuelle Azure-Netzwerkgateway gehen Gleiches Subnetz/Subnetzübergreifend: An den virtuellen Hyper-V-Switch des physischen Hosts gebunden, auf den die Richtlinie angewendet wird

IPAM

IP-Adressen werden für jeden Netzwerktreiber unterschiedlich zugeteilt und zugewiesen. Windows verwendet den Host Networking Service (HNS) zur Bereitstellung von IPAM für den NAT-Treiber und arbeitet mit Docker Swarm Mode (internal KVS) zusammen, um IPAM für Overlay bereitzustellen. Alle anderen Netzwerktreiber verwenden ein externes IPAM.

Netzwerkmodus /Treiber IPAM
NAT Dynamische IP-Zuteilung und Zuweisung durch Hostnetzwerkdienst (Host Networking Service, HNS) aus dem internen NAT-Subnetzpräfix
Durchsichtig Statische oder dynamische IP-Zuordnung (mit externem DHCP-Server) und Zuweisung von IP-Adressen innerhalb des Netzwerkpräfixes des Containerhosts
Überlagerung Dynamische IP-Zuteilung aus den verwalteten Präfixen im Schwarmmodus der Docker-Engine und Zuweisung über HNS
L2Bridge Dynamische IP-Zuordnung und -Zuweisung durch den Host Networking Service (HNS) aus vorgegebenen Subnetzpräfixen
L2Tunnel Nur Azure – Dynamische IP-Zuweisung und -Zuordnung aus dem Plugin

Dienstentdeckung

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

Treibername Lokale Dienstsuche Globale Dienstermittlung
NAT JA JA mit Docker EE
Überlagerung JA JA mit Docker EE oder kube-dns
durchsichtig NEIN NEIN
l2bridge JA mit kube-dns JA mit kube-dns