As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Rede Windows
## Visão geral do Windows Container Networking
Os contêineres do Windows são fundamentalmente diferentes dos contêineres do Linux. Os contêineres Linux usam construções Linux, como namespaces, o sistema de arquivos de união e cgroups. No Windows, essas construções são abstraídas dos containerd pelo [Host](https://github.com/microsoft/hcsshim) Compute Service (HCS). O HCS atua como uma camada de API que fica acima da implementação do contêiner no Windows. Os contêineres do Windows também utilizam o Host Network Service (HNS), que define a topologia da rede em um nó.
![\[rede windows\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/windows/windows-networking.png)
Do ponto de vista da rede, o HCS e o HNS fazem com que os contêineres do Windows funcionem como máquinas virtuais. Por exemplo, cada contêiner tem um adaptador de rede virtual (vNIC) conectado a um switch virtual Hyper-V (vSwitch), conforme mostrado no diagrama acima.
## Gerenciamento de endereços IP
Um nó no Amazon EKS usa sua interface de rede elástica (ENI) para se conectar a uma rede VPC da AWS. Atualmente, **há suporte para apenas um único ENI por nó de trabalho do Windows**. O gerenciamento de endereços IP para nós do Windows é executado pelo [VPC Resource Controller](https://github.com/aws/amazon-vpc-resource-controller-k8s), que é executado no plano de controle. Mais detalhes sobre o fluxo de trabalho para gerenciamento de endereços IP dos nós do Windows podem ser encontrados [aqui](https://github.com/aws/amazon-vpc-resource-controller-k8s#windows-ipv4-address-management).
O número de pods que um nó de trabalho do Windows pode suportar é determinado pelo tamanho do nó e pelo número de endereços disponíveis IPv4 . Você pode calcular o IPv4 endereço disponível no nó conforme abaixo:
+ Por padrão, somente IPv4 endereços secundários são atribuídos à ENI. Nesse caso:
```
Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1
```
Subtraímos um da contagem total, pois um IPv4 endereço será usado como endereço principal do ENI e, portanto, não poderá ser alocado aos pods.
+ Se o cluster foi configurado para alta densidade de pods ativando o [recurso de delegação de prefixo](prefix-mode-win.md), então-
```
Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16
```
Aqui, em vez de alocar IPv4 endereços secundários, o VPC Resource Controller alocará `/28 prefixes` e, portanto, o número total de IPv4 endereços disponíveis será aumentado 16 vezes.
Usando a fórmula acima, podemos calcular o máximo de pods para um operador do Windows com base em uma instância m5.large, conforme abaixo:
+ Por padrão, quando executado no modo IP secundário-
```
10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses
```
+ Ao usar `prefix delegation` -
```
(10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses
```
Para obter mais informações sobre quantos endereços IP um tipo de instância pode suportar, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI).
Outra consideração importante é o fluxo do tráfego da rede. Com o Windows, existe o risco de esgotamento de portas em nós com mais de 100 serviços. Quando essa condição surgir, os nós começarão a gerar erros com a seguinte mensagem:
**“Falha na criação da política: o hcnCreateLoad balanceador falhou no Win32: a porta especificada já existe.”**
Para resolver esse problema, usamos o Direct Server Return (DSR). O DSR é uma implementação de distribuição de carga de rede assimétrica. Em outras palavras, o tráfego de solicitação e resposta usa caminhos de rede diferentes. Esse recurso acelera a comunicação entre os pods e reduz o risco de esgotamento da porta. Portanto, recomendamos habilitar o DSR nos nós do Windows.
O DSR é habilitado por padrão no Windows Server SAC EKS Optimized. AMIs Para o Windows Server 2019 LTSC EKS Optimized AMIs, você precisará habilitá-lo durante o provisionamento da instância usando o script abaixo e usando o Windows Server 2019 Full ou Core como o AmiFamily no NodeGroup. `eksctl` Consulte a [AMI personalizada eksctl](https://eksctl.io/usage/custom-ami-support/) para obter informações adicionais.
```
nodeGroups:
- name: windows-ng
instanceType: c5.xlarge
minSize: 1
volumeSize: 50
amiFamily: WindowsServer2019CoreContainer
ssh:
allow: false
```
Para utilizar o DSR no Windows Server 2019 e versões posteriores, você precisará especificar os seguintes sinalizadores [https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#load-balancing-and-services) durante a inicialização da instância. Você pode fazer isso ajustando o script de dados do usuário associado ao Launch Template dos [grupos de nós autogerenciados](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
```
A habilitação do DSR pode ser verificada seguindo as instruções no [blog Microsoft Networking](https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710) e nos contêineres do [Windows no AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/1de8014a-d598-4cb5-a119-801576492564/en-US/module1-eks/lab3-handling-mixed-clusters) Lab.
![\[dsr\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/windows/dsr.png)
Se preservar os IPv4 endereços disponíveis e minimizar o desperdício for crucial para sua sub-rede, geralmente é recomendável evitar o uso do modo de delegação de prefixo, conforme mencionado em Modo de [prefixo para](prefix-mode-win.md#windows-prefix-avoid) Windows - Quando evitar. Se o uso da delegação de prefixo ainda for desejado, você poderá tomar medidas para otimizar a utilização do IPv4 endereço em sua sub-rede. Consulte [Configurando parâmetros para delegação de prefixo](prefix-mode-win.md#windows-network-conserve) para obter instruções detalhadas sobre como ajustar a solicitação de IPv4 endereço e o processo de alocação. O ajuste dessas configurações pode ajudá-lo a encontrar um equilíbrio entre a conservação de IPv4 endereços e os benefícios da densidade de pods da delegação de prefixos.
Ao usar a configuração padrão de atribuição de IPv4 endereços secundários, atualmente não há configurações compatíveis para manipular como o VPC Resource Controller solicita e aloca endereços. IPv4 Mais especificamente, `minimum-ip-target` e `warm-ip-target` são compatíveis apenas com o modo de delegação de prefixo. Observe também que, no modo IP secundário, dependendo dos endereços IP disponíveis na interface, o VPC Resource Controller normalmente aloca 3 IPv4 endereços não utilizados no nó em seu nome IPs para mantê-lo aquecido e acelerar a inicialização do pod. Se você quiser minimizar o desperdício de IP de endereços IP quentes não utilizados, você pode programar mais pods em um determinado nó do Windows para usar o máximo possível de capacidade de endereço IP do ENI. Mais explicitamente, você pode evitar que o warm não IPs seja usado se todos os endereços IP na ENI já estiverem sendo usados pelo nó e pelos pods em execução. Outra solução alternativa para ajudá-lo a resolver as restrições com a disponibilidade de endereços IP em suas sub-redes pode ser explorar o [aumento do tamanho da sub-rede ou a separação dos nós do Windows em suas próprias sub-redes](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html) dedicadas.
Além disso, é importante observar que não IPv6 há suporte nos nós do Windows no momento.
## Opções de interface de rede de contêiner (CNI)
O AWSVPC CNI é o plug-in CNI de fato para nós de trabalho do Windows e do Linux. Embora a AWSVPC CNI satisfaça as necessidades de muitos clientes, ainda pode haver momentos em que você precise considerar alternativas, como uma rede de sobreposição, para evitar o esgotamento do IP. Nesses casos, o Calico CNI pode ser usado no lugar do AWSVPC CNI. [O Project Calico](https://www.projectcalico.org/) é um software de código aberto desenvolvido pela [Tigera](https://www.tigera.io/). Esse software inclui uma CNI que funciona com o EKS. As instruções para instalar o Calico CNI no EKS podem ser encontradas na página de instalação do [Projeto Calico EKS](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks).
## Políticas de rede
É considerado uma prática recomendada mudar do modo padrão de comunicação aberta entre pods em seu cluster Kubernetes para limitar o acesso com base nas políticas de rede. O [Project Calico](https://www.tigera.io/tigera-products/calico/) de código aberto tem um forte suporte para políticas de rede que funcionam com nós Linux e Windows. Esse recurso é separado e não depende do uso do Calico CNI. Portanto, recomendamos instalar o Calico e usá-lo para gerenciamento de políticas de rede.
As instruções para instalar o Calico no EKS podem ser encontradas na página [Instalando o Calico no Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/calico.html).
Além disso, as recomendações fornecidas no [Guia de Melhores Práticas de Segurança do Amazon EKS — Seção Rede](https://docs.aws.amazon.com/eks/latest/best-practices/network-security.html) se aplicam igualmente aos clusters EKS com nós de trabalho do Windows. No entanto, alguns recursos como “Grupos de segurança para pods” não são suportados pelo Windows no momento.