Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Redes de Windows

Descripción general de las redes de contenedores de Windows

Los contenedores de Windows son fundamentalmente diferentes de los contenedores de Linux. Los contenedores de Linux utilizan construcciones de Linux como los espacios de nombres, el sistema de archivos de unión y los cgroups. En Windows, esas construcciones se extraen de los contenedores del Host Compute Service (HCS). https://github.com/microsoft/hcsshim El HCS actúa como una capa de API que se encuentra por encima de la implementación del contenedor en Windows. Los contenedores de Windows también utilizan el Host Network Service (HNS), que define la topología de red en un nodo.

Desde el punto de vista de las redes, HCS y HNS hacen que los contenedores de Windows funcionen como máquinas virtuales. Por ejemplo, cada contenedor tiene un adaptador de red virtual (vNIC) que está conectado a un conmutador Hyper-V virtual (vSwitch), como se muestra en el diagrama anterior.

Administración de direcciones IP

Un nodo de Amazon EKS usa su Elastic Network Interface (ENI) para conectarse a una red de VPC de AWS. En la actualidad, solo se admite un ENI por nodo de trabajo de Windows. La administración de direcciones IP de los nodos de Windows la realiza el controlador de recursos de VPC, que se ejecuta en el plano de control. Puede encontrar más información sobre el flujo de trabajo para la administración de direcciones IP de los nodos de Windows aquí.

La cantidad de pods que puede admitir un nodo de trabajo de Windows depende del tamaño del nodo y de la cantidad de direcciones IPv4 disponibles. Puede calcular la dirección IPv4 disponible en el nodo de la siguiente manera:

Con la fórmula anterior, podemos calcular el número máximo de pods para un nodo de trabajo de Windows en función de una instancia m5.large de la siguiente manera:

Para obtener más información sobre el número de direcciones IP que puede admitir un tipo de instancia, consulta el artículo Direcciones IP por interfaz de red por tipo de instancia.

Otra consideración clave es el flujo del tráfico de red. Con Windows, existe el riesgo de que se agoten los puertos en los nodos con más de 100 servicios. Cuando se presente esta condición, los nodos comenzarán a generar errores con el siguiente mensaje:

«Fallo al crear la política: hcn CreateLoadBalancer falló en Win32: el puerto especificado ya existe».

Para solucionar este problema, utilizamos Direct Server Return (DSR). El DSR es una implementación de la distribución asimétrica de cargas de red. En otras palabras, el tráfico de solicitud y respuesta utiliza rutas de red diferentes. Esta función acelera la comunicación entre los módulos y reduce el riesgo de que se agoten los puertos. Por lo tanto, recomendamos habilitar el DSR en los nodos de Windows.

El DSR está habilitado de forma predeterminada en las AMI optimizadas para SAC EKS de Windows Server. En el caso de las AMI optimizadas para LTSC EKS de Windows Server 2019, tendrá que habilitarlas durante el aprovisionamiento de instancias mediante el siguiente script y utilizando Windows Server 2019 Full o Core como familia de AMI en el grupo de nodos. eksctl Consulte la AMI personalizada de eksctl para obtener más información.

nodeGroups:
- name: windows-ng
  instanceType: c5.xlarge
  minSize: 1
  volumeSize: 50
  amiFamily: WindowsServer2019CoreContainer
  ssh:
    allow: false

Para utilizar DSR en Windows Server 2019 y versiones posteriores, tendrás que especificar los siguientes indicadores de kube-proxy durante el inicio de la instancia. Para ello, ajusta el script de datos de usuario asociado a la plantilla de lanzamiento de grupos de nodos autogestionados.

<powershell>
[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://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -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
</powershell>

La activación del DSR se puede verificar siguiendo las instrucciones del blog de redes de Microsoft y del laboratorio Windows Containers on AWS.

Si conservar las direcciones IPv4 disponibles y minimizar el desperdicio es crucial para la subred, por lo general se recomienda evitar el uso del modo de delegación de prefijos, tal como se menciona en Modo de prefijos para Windows: cuándo evitarlo. Si aún desea utilizar la delegación de prefijos, puede tomar medidas para optimizar el uso de las direcciones IPv4 en la subred. Consulte Configurar los parámetros para la delegación de prefijos para obtener instrucciones detalladas sobre cómo ajustar con precisión el proceso de solicitud y asignación de direcciones IPv4. Ajustar estas configuraciones puede ayudarlo a lograr un equilibrio entre la conservación de las direcciones IPv4 y las ventajas de la delegación de prefijos en cuanto a densidad de pods.

Cuando se utiliza la configuración predeterminada para asignar direcciones IPv4 secundarias, actualmente no se admiten configuraciones para manipular la forma en que el controlador de recursos de la VPC solicita y asigna las direcciones IPv4. Más específicamente, minimum-ip-target y solo se admiten en el modo de delegación de warm-ip-target prefijos. Tenga en cuenta también que, en el modo IP secundario, en función de las direcciones IP disponibles en la interfaz, el controlador de recursos de la VPC normalmente asignará 3 direcciones IPv4 no utilizadas en el nodo en su nombre para mantener las IP activas y acelerar el inicio del pod. Si quieres minimizar el despilfarro de IP que suponen las direcciones IP activas no utilizadas, puedes programar más pods en un nodo de Windows determinado de forma que puedas utilizar la mayor cantidad posible de direcciones IP del ENI. De forma más explícita, puedes evitar que las IP no utilizadas se calienten si el nodo y los pods en ejecución ya están usando todas las direcciones IP del ENI. Otra solución para ayudarte a resolver las restricciones relacionadas con la disponibilidad de direcciones IP en tus subredes podría ser estudiar la posibilidad de aumentar el tamaño de la subred o separar los nodos de Windows en sus propias subredes dedicadas.

Además, es importante tener en cuenta que, por el momento, IPv6 no es compatible con los nodos de Windows.

Opciones de interfaz de red de contenedores (CNI)

El CNI de AWSVPC es el complemento CNI de facto para los nodos de trabajo de Windows y Linux. Si bien el CNI del AWSVPC satisface las necesidades de muchos clientes, es posible que en ocasiones necesite considerar alternativas, como una red superpuesta, para evitar el agotamiento de la IP. En estos casos, se puede usar el CNI de Calico en lugar del CNI de AWSVPC. Project Calico es un software de código abierto desarrollado por Tigera. https://www.tigera.io/ Ese software incluye un CNI que funciona con EKS. Las instrucciones para instalar Calico CNI en EKS se encuentran en la página de instalación de Project Calico EKS.

Políticas de red

Se considera una práctica recomendada cambiar del modo predeterminado de comunicación abierta entre los pods del clúster de Kubernetes a limitar el acceso en función de las políticas de red. El proyecto Calico, de código abierto, es muy compatible con las políticas de red que funcionan tanto con los nodos de Linux como con los de Windows. Esta función es independiente y no depende del uso del CNI de Calico. Por lo tanto, recomendamos instalar Calico y usarlo para la administración de políticas de red.

Para obtener instrucciones sobre la instalación de Calico en Amazon EKS, consulte Instalación de Calico en Amazon EKS en el sitio web de Tigera.

Además, las recomendaciones que figuran en la sección Red de la Guía de prácticas recomendadas de seguridad de Amazon EKS se aplican igualmente a los clústeres de EKS con nodos de trabajo de Windows; sin embargo, Windows no admite actualmente algunas funciones, como la de los «grupos de seguridad para pods».