Pilotes réseau de conteneurs Windows

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

En plus de tirer parti du réseau « nat » par défaut créé par Docker sur Windows, les utilisateurs peuvent définir des réseaux de conteneurs personnalisés. Des réseaux définis par l’utilisateur peuvent être créés à l’aide de la commande CLI docker network create -d <NETWORK DRIVER TYPE> <NAME> Docker. Sur Windows, les types de pilote réseau suivants sont disponibles :

Pilote réseau NAT

Les conteneurs attachés à un réseau créé avec le pilote « nat » sont connectés à un commutateur Hyper-V interne et reçoivent une adresse IP à partir du préfixe IP spécifié par l’utilisateur (--subnet). Le réacheminement/mappage de ports à partir de l’hôte de conteneur vers des points de terminaison de conteneur est pris en charge.

Conseil

Il est possible de personnaliser le sous-réseau utilisé par le réseau « nat » par défaut via le fixed-cidr paramètre dans le fichier de configuration du démon Docker.

Notes

Les réseaux NAT créés sur Windows Server 2019 (ou version ultérieure) ne sont plus conservés après le redémarrage.

Création d’un réseau NAT

Pour créer un réseau NAT avec un sous-réseau 10.244.0.0/24:

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

Pilote réseau transparent

Les conteneurs attachés à un réseau créé avec le pilote « transparent » sont directement connectés au réseau physique via un commutateur Hyper-V externe . Les adresses IP issues du réseau physique peuvent être attribuées de façon statique (nécessite l'option --subnet spécifiée par l'utilisateur) ou dynamique à l’aide d’un serveur DHCP externe.

Notes

En raison de l’exigence suivante, la connexion de vos hôtes de conteneur sur un réseau transparent n’est pas prise en charge sur les machines virtuelles Azure.

Requis : lorsque ce mode est utilisé dans un scénario de virtualisation (l’hôte de conteneur est une machine virtuelle), l’usurpation d’adresse MAC est requise.

Création d’un réseau transparent

Pour créer un réseau transparent avec un sous-réseau 10.244.0.0/24, une passerelle 10.244.0.1, un serveur 10.244.0.7 DNS et un ID 7de réseau local virtuel :

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

Superposer le pilote réseau

Couramment utilisés par les orchestrateurs de conteneurs tels que Docker Swarm et Kubernetes, les conteneurs attachés à un réseau de superposition peuvent communiquer avec d’autres conteneurs attachés au même réseau sur plusieurs hôtes de conteneurs. Chaque réseau de superposition est créé avec son propre sous-réseau IP, défini par un préfixe d’adresse IP privée. Le pilote réseau de superposition utilise l’encapsulation VXLAN pour obtenir l’isolation du trafic réseau entre les réseaux de conteneurs de locataires et permet de réutiliser les adresses IP sur les réseaux de superposition.

Requis : assurez-vous que votre environnement remplit les conditions préalables requises pour créer des réseaux de superposition.

Nécessite : Sur Windows Server 2019, cette opération nécessite KB4489899.

Nécessite : sur Windows Server 2016, kb4015217 est nécessaire.

Notes

Sur Windows Server 2019 et versions ultérieures, les réseaux de superposition créés par Docker Swarm tirent parti des règles NAT VFP pour la connectivité sortante. Cela signifie qu’un conteneur donné reçoit 1 adresse IP. Cela signifie également que les outils ICMP tels que ping ou Test-NetConnection doivent être configurés à l’aide de leurs options TCP/UDP dans les situations de débogage.

Création d’un réseau de superposition

Pour créer un réseau de superposition avec le sous-réseau 10.244.0.0/24, le serveur 168.63.129.16DNS et 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

Pilote réseau L2bridge

Les conteneurs attachés à un réseau créé avec le pilote « l2bridge » seront connectés au réseau physique via un commutateur Hyper-V externe . Dans l2bridge, le trafic réseau de conteneurs aura la même adresse MAC que l’hôte en raison de l’opération de traduction d’adresses de couche 2 (réécriture MAC) à l’entrée et à la sortie. Dans les centres de données, cela permet d’atténuer le stress sur les commutateurs qui doivent apprendre les adresses MAC de conteneurs parfois de courte durée. Les réseaux L2bridge peuvent être configurés de deux façons différentes :

  1. Le réseau L2bridge est configuré avec le même sous-réseau IP que l’hôte de conteneur
  2. Le réseau L2bridge est configuré avec un nouveau sous-réseau IP personnalisé

Dans la configuration 2, les utilisateurs doivent ajouter un point de terminaison sur le compartiment réseau hôte qui fait office de passerelle et configurer les fonctionnalités de routage pour le préfixe désigné.

Création d’un réseau l2bridge

Pour créer un réseau l2bridge avec le sous-réseau 10.244.0.0/24, la passerelle 10.244.0.1, le serveur 10.244.0.7 DNS et l’ID de réseau local virtuel 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

Conseil

Les réseaux L2bridge sont hautement programmables; Vous trouverez plus d’informations sur la configuration de l2bridge ici.

Pilote réseau L2tunnel

La création est identique à l2bridge, mais ce pilote ne doit être utilisé que dans un Microsoft Cloud Stack (Azure). La seule différence par rapport à l2bridge est que tout le trafic de conteneur est envoyé à l’hôte de virtualisation où la stratégie SDN est appliquée, ce qui permet d’activer des fonctionnalités telles que les groupes de sécurité réseau Azure pour les conteneurs.

Topologies réseau et IPAM

Le tableau ci-dessous montre de quelle manière est fournie la connectivité réseau pour les connexions internes (conteneur-conteneur) et externes dans chaque pilote réseau.

Modes de mise en réseau/pilotes Docker

Pilote réseau Windows Docker Utilisations classiques Conteneur à conteneur (nœud unique) Conteneur à externe (nœud unique + multinœud) Conteneur à conteneur (multinœud)
NAT (par défaut) Convient aux développeurs
  • Même sous-réseau : connexion reliée par un pont via un commutateur virtuel Hyper-V
  • Multi-sous-réseau : non pris en charge (un seul préfixe interne NAT)
Routé via la carte réseau virtuelle de gestion (liée à WinNAT) Non pris en charge directement : nécessite l’exposition des ports via l’hôte
Mode transparent Convient aux développeurs ou aux petits déploiements
  • Même sous-réseau : connexion reliée par un pont via un commutateur virtuel Hyper-V
  • Multi-sous-réseau : routé via l’hôte de conteneur
Routé via l’hôte de conteneur avec un accès direct à la carte réseau (physique) Routé via l’hôte de conteneur avec un accès direct à la carte réseau (physique)
Overlay Convient pour plusieurs nœuds ; requis pour Docker Swarm, disponible dans Kubernetes
  • Même sous-réseau : connexion reliée par un pont via un commutateur virtuel Hyper-V
  • Multi-sous-réseau : le trafic réseau est encapsulé et routé via la carte réseau virtuelle de gestion
Non pris en charge directement : nécessite un deuxième point de terminaison de conteneur attaché au réseau NAT sur Windows Server 2016 ou règle NAT VFP sur Windows Server 2019. Même sous-réseau/multi-sous-réseau : le trafic réseau est encapsulé en utilisant VXLAN et routé via la carte réseau virtuelle de gestion
L2Bridge Utilisé pour Kubernetes et Microsoft SDN
  • Même sous-réseau : connexion reliée par un pont via un commutateur virtuel Hyper-V
  • Multi-sous-réseau : adresse MAC du conteneur réécrite lors de l’entrée et de la sortie, et routée
Adresse MAC du conteneur réécrit lors de l’entrée et de la sortie
  • Même sous-réseau : connexion reliée par un pont
  • Multi-sous-réseau : routé via la carte réseau virtuelle de gestion sur WSv1809 et ultérieur
L2Tunnel Azure uniquement Même sous-réseau/multi-sous-réseau : épinglé au commutateur virtuel Hyper-V de l’hôte physique à l’endroit où la stratégie est appliquée Le trafic doit passer par la passerelle de réseau virtuel Azure Même sous-réseau/multi-sous-réseau : épinglé au commutateur virtuel Hyper-V de l’hôte physique à l’endroit où la stratégie est appliquée

IPAM

Les adresses IP sont attribuées et assignées différemment pour chaque pilote réseau. Windows utilise le service HNS (Host Networking Service) pour fournir une IPAM au pilote nat et fonctionne avec le mode Docker Swarm (KVS interne) pour fournir une IPAM de superposition. Tous les autres pilotes réseau utilisent une IPAM externe.

Mode de mise en réseau / pilote IPAM
NAT Allocation et affectation d’adresses IP dynamiques par le service HNS (Host Networking Service) à partir du préfixe de sous-réseau NAT interne
Mode transparent Allocation et affectation d’adresses IP statiques ou dynamiques (à l’aide d’un serveur DHCP externe) à partir d’adresses IP dans le préfixe réseau de l’hôte de conteneur
Overlay Allocation d’adresses IP dynamiques à partir de préfixes managés du mode Swarm du moteur Docker et affectation via HNS
L2Bridge Allocation et affectation d’adresses IP dynamiques par le service HNS (Host Networking Service) à partir du préfixe de sous-réseau fourni
L2Tunnel Azure uniquement - Allocation et affectation d’adresses IP dynamiques à partir du plug-in

Découverte de service

La découverte des services est uniquement prise en charge pour certains pilotes réseau Windows.

Nom du pilote Découverte des services locale Découverte des services globale
nat YES OUI avec Docker EE
superposition YES OUI avec Docker EE ou kube-dns
transparent Non Non
l2bridge OUI avec kube-dns OUI avec kube-dns