Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Réseau Windows ## Présentation du réseau de conteneurs Windows Les conteneurs Windows sont fondamentalement différents des conteneurs Linux. Les conteneurs Linux utilisent des structures Linux telles que les espaces de noms, le système de fichiers union et les groupes de contrôle. Sous Windows, ces constructions sont extraites de containerd par le [ Host Compute Service (HCS). ](https://github.com/microsoft/hcsshim) HCS agit comme une couche d'API située au-dessus de l'implémentation du conteneur sous Windows. Les conteneurs Windows exploitent également le Host Network Service (HNS) qui définit la topologie du réseau sur un nœud. ![mise en réseau Windows](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/windows/windows-networking.png) Du point de vue de la mise en réseau, HCS et HNS font fonctionner les conteneurs Windows comme des machines virtuelles. Par exemple, chaque conteneur possède un adaptateur réseau virtuel (vNIC) connecté à un commutateur Hyper-V virtuel (vSwitch), comme indiqué dans le schéma ci-dessus. ## Gestion des adresses IP Un nœud d'Amazon EKS utilise son interface réseau élastique (ENI) pour se connecter à un réseau AWS VPC. Actuellement, une ** seule ENI par nœud de travail Windows est prise en charge**. La gestion des adresses IP pour les nœuds Windows est effectuée par [ VPC Resource Controller ](https://github.com/aws/amazon-vpc-resource-controller-k8s) qui s'exécute dans le plan de contrôle. Vous trouverez plus de détails sur le flux de travail pour la gestion des adresses IP des nœuds Windows [ ici](https://github.com/aws/amazon-vpc-resource-controller-k8s#windows-ipv4-address-management). Le nombre de pods qu'un nœud de travail Windows peut prendre en charge dépend de la taille du nœud et du nombre d'adresses IPv4 disponibles. Vous pouvez calculer l'adresse IPv4 disponible sur le nœud comme suit : + Par défaut, seules les adresses IPv4 secondaires sont attribuées à l'ENI. Dans un tel cas : ``` Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1 ``` Nous soustrayons un du nombre total car une adresse IPv4 sera utilisée comme adresse principale de l'ENI et ne pourra donc pas être attribuée aux Pods. + Si le cluster a été configuré pour une densité de pods élevée en activant la fonction de délégation de [ préfixes](prefix-mode-win.md), alors : ``` Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16 ``` Ici, au lieu d'allouer des adresses IPv4 secondaires, VPC Resource Controller les allouera `/28 prefixes` et, par conséquent, le nombre total d'adresses IPv4 disponibles sera multiplié par 16. En utilisant la formule ci-dessus, nous pouvons calculer le nombre maximum de pods pour un worker Windows nodé sur la base d'une instance m5.large comme ci-dessous : + Par défaut, lors de l'exécution en mode IP secondaire- ``` 10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses ``` + Lors de l'utilisation `prefix delegation` : ``` (10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses ``` Pour plus d'informations sur le nombre d'adresses IP qu'un type d'instance peut prendre en charge, consultez la section Adresses [ IP par interface réseau et par type d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Le flux du trafic réseau est un autre facteur clé à prendre en compte. Avec Windows, il existe un risque d'épuisement des ports sur les nœuds comportant plus de 100 services. Lorsque cette condition se produit, les nœuds commencent à générer des erreurs avec le message suivant : **« Échec de la création de la politique : CreateLoadBalancer échec de hcn dans Win32 : le port spécifié existe déjà. » ** Pour résoudre ce problème, nous utilisons la fonction Direct Server Return (DSR). Le DSR est une implémentation de la distribution asymétrique de la charge du réseau. En d'autres termes, le trafic de demande et de réponse utilise des chemins réseau différents. Cette fonctionnalité accélère la communication entre les pods et réduit le risque d'épuisement des ports. Nous vous recommandons donc d'activer le DSR sur les nœuds Windows. Le DSR est activé par défaut dans les AMI optimisées SAC EKS de Windows Server. Pour les AMI optimisées pour Windows Server 2019 LTSC EKS, vous devez l'activer lors du provisionnement de l'instance à l'aide du script ci-dessous et en utilisant Windows Server 2019 Full ou Core en tant que famille AMI dans le NodeGroup. `eksctl` Consultez l'AMI personnalisée [ eksctl ](https://eksctl.io/usage/custom-ami-support/) pour plus d'informations. ``` nodeGroups: - name: windows-ng instanceType: c5.xlarge minSize: 1 volumeSize: 50 amiFamily: WindowsServer2019CoreContainer ssh: allow: false ``` Pour utiliser le DSR dans Windows Server 2019 et versions ultérieures, vous devez spécifier les ** [ indicateurs ](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services) ** kube-proxy suivants lors du démarrage de l'instance. Vous pouvez le faire en ajustant le script userdata associé au modèle de lancement des groupes de nœuds [ autogérés. ](https://docs.aws.amazon.com/eks/latest/userguide/launch-windows-workers.html) ``` [string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS" [string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1' [string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName" (Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile & $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://" -Base64ClusterCA "" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1 ``` L'activation du DSR peut être vérifiée en suivant les instructions du blog [ Microsoft Networking ](https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710) et du [ Windows Containers on AWS Lab. ](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module1-eks/lab3-handling-mixed-clusters) ![dsr](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/windows/dsr.png) S'il est crucial de préserver vos adresses IPv4 disponibles et de minimiser le gaspillage pour votre sous-réseau, il est généralement recommandé d'éviter d'utiliser le mode de délégation de préfixe, comme indiqué dans Mode [ préfixe pour Windows - Quand éviter. ](prefix-mode-win.md#windows-prefix-avoid) Si vous souhaitez toujours utiliser la délégation de préfixes, vous pouvez prendre des mesures pour optimiser l'utilisation des adresses IPv4 dans votre sous-réseau. Consultez [ la section Configuration des paramètres pour la délégation de préfixes ](prefix-mode-win.md#windows-network-conserve) pour obtenir des instructions détaillées sur la façon d'affiner le processus de demande et d'allocation d'adresses IPv4. L'ajustement de ces configurations peut vous aider à trouver un équilibre entre la conservation des adresses IPv4 et les avantages de la délégation de préfixes en termes de densité de pods. Lorsque vous utilisez le paramètre par défaut d'attribution d'adresses IPv4 secondaires, aucune configuration n'est actuellement prise en charge pour manipuler la manière dont le contrôleur de ressources VPC demande et alloue les adresses IPv4. Plus précisément, `minimum-ip-target` et ne `warm-ip-target` sont pris en charge que pour le mode de délégation de préfixe. Notez également qu'en mode IP secondaire, en fonction des adresses IP disponibles sur l'interface, le contrôleur de ressources VPC alloue généralement 3 adresses IPv4 inutilisées sur le nœud en votre nom afin de conserver des adresses IP chaudes pour accélérer le démarrage des pods. Si vous souhaitez minimiser le gaspillage d'adresses IP chaudes non utilisées, vous pouvez planifier davantage de modules sur un nœud Windows donné de manière à utiliser autant que possible la capacité d'adresse IP de l'ENI. Plus précisément, vous pouvez éviter d'avoir des adresses IP inutilisées chaudes si toutes les adresses IP de l'ENI sont déjà utilisées par le nœud et les pods en cours d'exécution. Une autre solution pour vous aider à résoudre les contraintes liées à la disponibilité des adresses IP dans vos sous-réseaux consiste à envisager d'[augmenter la taille de vos sous-réseaux ](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html) ou de séparer vos nœuds Windows en leurs propres sous-réseaux dédiés. En outre, il est important de noter qu'IPv6 n'est pas pris en charge sur les nœuds Windows pour le moment. ## Options de l'interface réseau de conteneurs (CNI) L'AWSVPC CNI est le plug-in CNI de facto pour les nœuds de travail Windows et Linux. Bien que l'AWSVPC CNI réponde aux besoins de nombreux clients, il peut arriver que vous deviez envisager des alternatives, comme un réseau superposé pour éviter l'épuisement des adresses IP. Dans ces cas, le CNI Calico peut être utilisé à la place du CNI AWSVPC. [Project Calico ](https://www.projectcalico.org/) est un logiciel open source développé par [https://www.tigera.io/](https://www.tigera.io/) Tigera. Ce logiciel inclut un CNI qui fonctionne avec EKS. Les instructions pour installer Calico CNI dans EKS sont disponibles sur la page d'installation de [ Project Calico EKS. ](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks) ## Politiques du réseau Il est considéré comme une bonne pratique de passer du mode de communication ouverte par défaut entre les pods de votre cluster Kubernetes à une limitation de l'accès en fonction des politiques du réseau. Le [ projet open source Calico ](https://www.tigera.io/tigera-products/calico/) prend fermement en charge les politiques réseau qui fonctionnent à la fois avec les nœuds Linux et Windows. Cette fonctionnalité est distincte et ne dépend pas de l'utilisation du Calico CNI. Nous vous recommandons donc d'installer Calico et de l'utiliser pour la gestion des politiques réseau. Pour obtenir des instructions sur l'installation de Calico sur Amazon EKS, consultez la section [ Installation de Calico sur Amazon EKS ](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks) sur le site Web de Tigera. En outre, les conseils fournis dans le Guide des meilleures pratiques d'[Amazon EKS pour la sécurité - Section Réseau ](https://docs.aws.amazon.com/eks/latest/best-practices/network-security.html) s'appliquent également aux clusters EKS dotés de nœuds de travail Windows. Toutefois, certaines fonctionnalités telles que les « Groupes de sécurité pour les pods » ne sont pas prises en charge par Windows pour le moment.